Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What came first: the CNAME or the A record?

blog.cloudflare.com

Post reply on HN
Print view View original

91–100 of 170 posts

Re: What came first: the CNAME or the A record?

#91

Post by sweetjuly »

tuetuopay wrote: post #59
CodesInChaos wrote: post #35

Earlier quoted context omitted.

That depends on how Postel's law is interpreted. What's reasonable is: "Set reserved fields to 0 when writing and ignore them when reading." (I heard that was the original example). Or "Ignore unknown JSON keys" as a modern equivalent. What's harmful is: Accept an ill defined superset of the valid syntax and interpret it in undocumented ways.

Funny I never read the original example. And in my book, it is harmful, and even worse in JSON, since it's the best way to have a typo somewhere go unnoticed for a long time.

The original example is very common in ISAs at least. Both ARMv8 and RISC-V (likely others too but I don't have as much experience with them) have the idea of requiring software to treat reserved bits as if they were zero for both reading and writing. ARMv8 calls this RES0 and an hardware implementation is constrained to either being write ignore for the field (eg read is hardwired to zero) or returning the last successful write.

This is useful as it allows the ISA to remain compatible with code which is unaware of future extensions which define new functionality for these bits so long as the zero value means "keep the old behavior". For example, a system register may have an EnableNewFeature bit, and older software will end up just writing zero to that field (which preserves the old functionality). This avoids needing to define a new system register for every new feature.

Re: What came first: the CNAME or the A record?

#92

Post by jrochkind1 »

mrmattyboy wrote: post #50
steve1977 wrote: post #14

I don't find the wording in the RFC to be that ambiguous actually. > The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. The "possibly preface" (sic!) to me is obviously to be understood as "if there are any CNAME RRs, the answer to the query is to be prefaced by those CNAME RRs" and not "you can preface the query with the CNAME RRs or you can p…

I agree this doens't seem too ambiguous - it's "you may do this.." and they said "or we may do the reverse". If I say you're could prefix something.. the alternative isn't that you can suffix it. But also.. the programmers working on the software running one of the most important (end-user) DNS servers in the world: 1. Changes logic in how CNAME responses are formed 2. I assume some tests at least broke that meant th…

> I assume some tests at least broke that meant they needed to be "fixed up"

OP said:

"However, we did not have any tests asserting the behavior remains consistent due to the ambiguous language in the RFC."

One could guess it's something like -- back when we wrote the tests, years ago, whoever did it missed that this was required, not helped by the fact that the spec proceeded RFC 2119 standardizing the all-caps "MUST" "SHOULD" etc language, which would have helped us translsate specs to tests more completely.

Re: What came first: the CNAME or the A record?

#93

Post by torstenvl »

EDIT: Why the drive-by downvotes? If someone thinks I'm wrong, I'm happy to hear why.

> One such implementation that broke is the getaddrinfo function in glibc, which is commonly used on Linux for DNS resolution.

> Most DNS clients don’t have this issue.

The most widespread implementation on the most widespread server operating system has the issue. I'm skeptical of what the author means by "Most DNS clients."

Also, what is the point of deploying to test if you aren't going to test against extremely common scenarios (like getaddrinfo)?

> To prevent any future incidents or confusion, we have written a proposal in the form of an Internet-Draft to be discussed at the IETF. If consensus is reached...

Pretty sure both Hyrum's Law and Postel's Law have reached the point of consensus.

Being conservative in what you emit means following the spec's most conservative interpretation, even if you think the way it's worded gives you some wiggle room. And the fact that your previous implementation did it that way for a decade means people have come to rely on it.

Re: What came first: the CNAME or the A record?

#94

Post by black3r »

mrmattyboy wrote: post #50
steve1977 wrote: post #14

I don't find the wording in the RFC to be that ambiguous actually. > The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. The "possibly preface" (sic!) to me is obviously to be understood as "if there are any CNAME RRs, the answer to the query is to be prefaced by those CNAME RRs" and not "you can preface the query with the CNAME RRs or you can p…

I agree this doens't seem too ambiguous - it's "you may do this.." and they said "or we may do the reverse". If I say you're could prefix something.. the alternative isn't that you can suffix it. But also.. the programmers working on the software running one of the most important (end-user) DNS servers in the world: 1. Changes logic in how CNAME responses are formed 2. I assume some tests at least broke that meant th…

> 4. Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken

"Testing environment" sounds to me like a real network real user devices are used with (like the network used inside CloudFlare offices). That's what I would do if I was developing a DNS server anyway, other than unit tests (which obviously wouldn't catch this unless they were explicitly written for this case) and maybe integration/end-to-end tests, which might be running in Alpine Linux containers and as such using musl. If that's indeed the case, I can easily imagine how noone noticed anything was broken. First look at this line:

> Most DNS clients don’t have this issue. For example, systemd-resolved first parses the records into an ordered set:

Now think about what real end user devices are using: Windows/macOS/iOS obviously aren't using glibc and Android also has its own C library even though it's Linux-based, and they all probably fall under the "Most DNS clients don't have this issue.".

That leaves GNU/Linux, where we could reasonably expect most software to use glibc for resolving queries, so presumably anyone using Linux on their laptop would catch this right? Except most distributions started using systemd-resolved (most notable exception is Debian, but not many people use that on desktops/laptops), which is a locally-cached recursive DNS server, and as such acts as a middleman between glibc software and the network configured DNS server, so it would resolve 1.1.1.1 queries correctly, and then return the results from its cache ordered by its own ordering algorithm.

Re: What came first: the CNAME or the A record?

#95

Post by VoodooJuJu »

steve1977 wrote: post #14

I don't find the wording in the RFC to be that ambiguous actually. > The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. The "possibly preface" (sic!) to me is obviously to be understood as "if there are any CNAME RRs, the answer to the query is to be prefaced by those CNAME RRs" and not "you can preface the query with the CNAME RRs or you can p…

[dead]

Re: What came first: the CNAME or the A record?

#96

Post by black3r »

ajross wrote: post #44
patrickmay wrote: post #3

A great example of Hyrum's Law: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." combined with failure to follow Postel's Law: "Be conservative in what you send, be liberal in what you accept."

That's true, but sort of misses the spirit of Hyrum's law (which is that the world is filled with obscure edge cases). In this case the broken resolver was the one in the GNU C Library , hardly an obscure situation! The news here is sort of buried in the story. Basically Cloudflare just didn't test this. Literally every datacenter in the world was going to fail on this change, probably including their own.

> Literally every datacenter in the world was going to fail on this change

I would expect most datacenters to use their own local recursive caching DNS servers instead of relying on 1.1.1.1 to minimize latency.

Re: What came first: the CNAME or the A record?

#97

Post by zinekeller »

bpt3 wrote: post #60
mrmattyboy wrote: post #50

Earlier quoted context omitted.

I agree this doens't seem too ambiguous - it's "you may do this.." and they said "or we may do the reverse". If I say you're could prefix something.. the alternative isn't that you can suffix it. But also.. the programmers working on the software running one of the most important (end-user) DNS servers in the world: 1. Changes logic in how CNAME responses are formed 2. I assume some tests at least broke that meant th…

> Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken This is the part that is shocking to me. How is getaddrinfo not called in any unit or system tests?

As black3r mentioned (https://news.ycombinator.com/item?id=46686096), it is likely rearranged by systemd, therefore only non-systemd glibc distributions are affected.

I would hazard a guess that their test environment have both the systemd variant and the Unbound variants (Unbound technically does not arrange them, but instead reconstructs it according to RFC "CNAME restart" logic because it is a recursive resolver in itself), but not just plain directly-piped resolv.conf (Presumably because who would run that in this day and age. This is sadly just a half-joke, because only a few people would fall on this category.)

Re: What came first: the CNAME or the A record?

#98

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #63

"One such implementation that broke is the getaddrinfo function in glibc, which is commonly used on Linux for DNS resolution. When looking at its getanswer_r implementation, we can indeed see it expects to find the CNAME records before any answers:" Wherever possible I compile with gethostbyname instead of getaddrinfo. I use musl instead of glibc Nothing against IPv6 but I do not use it on the computers and networks…

NB. This is not code that belongs to me

When compiling software written by others, sometimes there are compile-time options that allow not using getaddrinfo or IPv6

For example,

links (--without-getaddrinfo)

haproxy (USE_GETADDRINFO="")

tnftp (--disable-ipv6)

elinks (--disable-ipv6)

wolfssl (ipv6 disabled by default)

stunnel (--disable-ipv6)

socat (--disable-ipv6)

and many more

Together with localhost TLS forward proxy I also use lots of older software that only used gethostbyname, e.g., original netcat, ucspi-tcp, libwww, original links, etc.

Generally I avoid mobile OS (corporate OS for data collection, surveillance and ad services)

Mobile data is disabled. I almost never use cellular networks for internet

Mobile sucks for internet IMHO; I have zero expectation re: speed and I cannot control what ISPs choose to do

For me, non-corporate UNIX-like OS are smaller, faster, easier to control, more interesting

Re: What came first: the CNAME or the A record?

#99

Post by zinekeller »

immibis wrote: post #74
silverwind wrote: post #26

Earlier quoted context omitted.

It's more likely because the internet runs on a very small number of authorative server implementations which all implement this ordering quirk.

This is a recursive resolver quirk

... that was perpetuated by BIND.

(Yes, there are other recursive resolver implementations, but they look at BIND as the reference implementation and absent any contravention to the RFC or intentional design-level decisions, they would follow BIND's mechanism.)

Re: What came first: the CNAME or the A record?

#100

Post by PunchyHamster »

TL;DR everyone implemented RFC properly (if missing some defensive coding), cloudflare decided it's optional and then learned that everyone did implement RFC properly, just some also did some additional work to make sure servers made wrong still were supported
Post reply on HN