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

131–140 of 170 posts

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

#131

Post by afiori »

kiwijamo wrote: post #87
paulddraper wrote: post #19

> RFC 1034, published in 1987, defines much of the behavior of the DNS protocol, and should give us an answer on whether the order of CNAME records matters. Section 4.3.1 contains the following text: > If recursive service is requested and available, the recursive response to a query will be one of the following: > - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered o…

Some people (myself included) read that as "would ideally come first, but it is not neccessary that it comes first". The language is not clear IMHO and could be worded better.

In my native language the literal translation of possibly has a distinct preferably meaning but I feel that in English it does not.

It might be a victim of polite/ironic/sarcastic influences to language that turns innocuous words into contronyms

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

#132

Post by [deleted] »

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…

[deleted]

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

#133

Post by account42 »

black3r wrote: post #94
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…

> 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 cat…

> other than unit tests (which obviously wouldn't catch this unless they were explicitly written for this case)

They absolutely should have unit tests that detect any change in output and manually review those changes for an operation of this size.

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

#134

Post by account42 »

jrochkind1 wrote: post #92
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…

> 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 "MUS…

You'd think that something this widely used would have golden tests that detect any output change to trigger manual review but apparently they don't.

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

#135

Post by jeroenhd »

NelsonMinar wrote: post #22

It's remarkable that the ordinary DNS lookup function in glibc doesn't work if the records aren't in the right order. It's amazing to me we went 20+ years without that causing more problems. My guess is most people publishing DNS records just sort of knew that the order mattered in practice, maybe figuring it out in early testing.

People probably ran into this all the time, but no single party large enough to have it gain attention produced the failure state.

If a small business or cloud app can't resolve a domain because the domain is doing something different, it's much easier to blame DNS, use another DNS server, and move on. Or maybe just go "some Linuxes can't reach my website, oh well, sucks for the 1-3%".

Cloudflare is large enough that they caused issues for millions of devices all at once, so they had to investigate.

What's unclear to me is if they bothered to send patches to broken open-source DNS resolvers to fix this issue in the future.

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

#136

Post by jeroenhd »

stackskipton wrote: post #11
renewiltord wrote: post #7

Nice analysis. Boy I can’t imagine having to work at Cloudflare on this stuff. A month to get your “small in code” change out only to find some bums somewhere have written code that will make it not work.

Or when working on massive infrastructure like this, you write plenty of tests that would have saved you a month worth of work. They write reordering, push it and glibc tester fires, fails and you quickly discover "Crap, tests are failing and dependency (glibc) doesn't work way I thought it would."

With glibc falling over but systemd-resolved working as intended, I suspect their Linux tests may have accidentally passed. Most desktop Linux installs and a whole lot of cloud Linux installs would've accidentally been saved from glibc's bug by systemd-resolved.

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

#137

Post by iainmerrick »

jeroenhd wrote: post #135
NelsonMinar wrote: post #22

It's remarkable that the ordinary DNS lookup function in glibc doesn't work if the records aren't in the right order. It's amazing to me we went 20+ years without that causing more problems. My guess is most people publishing DNS records just sort of knew that the order mattered in practice, maybe figuring it out in early testing.

People probably ran into this all the time, but no single party large enough to have it gain attention produced the failure state. If a small business or cloud app can't resolve a domain because the domain is doing something different, it's much easier to blame DNS, use another DNS server, and move on. Or maybe just go "some Linuxes can't reach my website, oh well, sucks for the 1-3%". Cloudflare is large enough that…

No, because they're not really broken. I think this is fairly clear:

Based on what we have learned during this incident, we have reverted the CNAME re-ordering and do not intend to change the order in the future.

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.

That is, explicitly documenting the "broken" behaviour as permitted.

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

#138

Post by ibejoeb »

jrochkind1 wrote: post #92
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…

> 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 "MUS…

Even if there weren't tests for the return order, I would have bet that there were tests of backbone resolvers like getaddrinfo. Is it really possible that the first time anyone noticed that that crashed, or that ciscos bootlooped, was on a live query?

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

#139

Post by kunley »

albert_e wrote: post #117

The kind of "optimization" that Cloudflare is attempting to do here ... doesnt that transfer the burden of more expensive parsing downstream to all the DNS clients instead? Sounds low key selfish / inconsiderate to me ... to push such a change without adequate thought or informed buy in by consumers of that service.

Yeah, but you know, they needed to save extra bytes in the Rust implementation of their services, so wherever Rust pops up it apparently justifies any such action. ;)

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

#140

Post by account42 »

zinekeller wrote: post #99
immibis wrote: post #74

Earlier quoted context omitted.

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.)

It's also the most natural way to structure the answer:

Hey, where can I find A.

Answer: A is actually B

Answer: Also B can be found at 42

Post reply on HN