What came first: the CNAME or the A record? • Hacker News Board

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

#101

Post by PunchyHamster » Tue, Jan 20, 2026, 12:48 AM UTC

inopinatus wrote: post #42

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…

The article makes it very clear that the ambiguity arises in another phrase: “difference in ordering of the RRs in the answer section is not significant”, which is applied to an example; the problem with examples being that they are illustrative, viz. generalisable, and thus may permit reordering everywhere, and in any case, whether they should or shouldn’t becomes a matter of pragmatic context. Which goes to show, o…

it wouldn't be a problem if they tested it properly... especially WHEN stuff is ambigous

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

#102

Post by mintflow » Tue, Jan 20, 2026, 12:57 AM UTC

After reading the article, I am wondering is that is there no test case to coverage the behavior that modify the CNAME order in the response? I think it should be simple to run a fleet of various OS/DNS client combinations to test the behavior.

And I also being shocked that Cisco Switch goes to reboot loop with this DNS order issue.

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

#103

Post by colmmacc » Tue, Jan 20, 2026, 1:12 AM UTC

I am very petty about this one bug and have a very old axe to grind that this reminded me of! Way back in 2011 CloudFlare launched an incredibly poorly researched feature to just return CNAME records at a domain apex ... RFCs be damned.

https://blog.cloudflare.com/zone-apex-naked-domain-root-doma... , and I quote directly ... "Never one to let a RFC stand in the way of a solution to a real problem, we're happy to announce that CloudFlare allows you to set your zone apex to a CNAME."

The problem? CNAMEs are name level aliases, not record level, so this "feature" would break the caching of NS, MX, and SOA records that exist at domain apexes. Many of us warned them at the time that this would result in a non-deterministic issue. At EC2 and Route 53 we weren't supporting this just to be mean! If a user's DNS resolver got an MX query before an A query, things might work ... but the other way around, they might not. An absolute nightmare to deal with. But move fast and break things, so hey :)

In earnest though ... it's great to see how now CloudFare are handling CNAME chains and A record ordering issues in this kind of detail. I never would have thought of this implicit contract they've discovered, and it makes sense!

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

#104

Post by alexey-salmin » Tue, Jan 20, 2026, 1:32 AM UTC

Gigachad wrote: post #81

wolttam wrote: post #67

My take is quite cynical on this.. This post reads to me like a post-justification of some strange newly introduced behaviour. Please order the answer in the order the resolutions were performed to arrive at the final answer (regardless of cache timings). Anything else makes little sense, especially not in the name of some micro-optimization (which could likely be approached in other ways that don’t alter behaviour).

The DNS specification should be updated to say CNAMES _must_ be ordered at the top rather than "possibly". Cloudflare was complying with the specification. Cisco was relying on unspecified behavior that happened to be common.

The only reasonable interpretation of "possibly prefaced" is that the CNAMEs either come first or not at all (hence "possibly"). Nowhere the RFC suggests that they may come in the middle.

Something is broken in Cloudflare since a couple of years. It takes a very specific engineering culture to run the internet and it's just not there anymore.

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

#105

Post by inkyoto » Tue, Jan 20, 2026, 1:51 AM UTC

This could be a great fit for Prolog, in fact, as it excels at the search.

Each resolved record would be asserted as a fact, and a tiny search implementation would run after all assertions have been made to resolve the IP address irrespective of the order in which the RRsets have arrived.

A micro Prolog implementation could be rolled into glibc's resolver (or a DNS resolver in general) to solve the problem once and for all.

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

#106

Post by stevefan1999 » Tue, Jan 20, 2026, 1:55 AM UTC

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 means you did a leaky abstraction indirectly but it is on the people level

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

#107

Post by 0xbadcafebee » Tue, Jan 20, 2026, 2:21 AM UTC

It's kind of weird that they didn't expect this. DNS resolvers are famously inconsistent, with changes sometimes working or not working, breaking or not breaking. Virtually any change you make to what DNS serves or how will cause inconsistent behavior somewhere. (DNS encompasses hundreds of RFCs)

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

#108

Post by 0xbadcafebee » Tue, Jan 20, 2026, 2:29 AM UTC

sebastianmestre wrote: post #17

I kind of wish they start sending records in randomized order to take out all the broken implementations that depend on such a fragile property

That won't cause implementations to be fixed. The implementations in question are in devices that are old (DNS is over 40 years old) and will never be upgraded. Affected users will just choose a different DNS resolver. Pretty soon word will get around that "if you don't want a broken device, don't use CloudFlare for DNS". It's less hassle for CloudFlare to just maintain the existing de-facto standard.

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

#109

Post by bashook » Tue, Jan 20, 2026, 2:34 AM UTC

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 was even more surprised to see that the RFC draft had original text from the author dating back to 2015. https://github.com/ableyjoe/draft-jabley-dnsop-ordered-answe...

We used to say at work that the best way to get promoted was to be the programmer that introduced the bug into production and then fix it. Crazy if true here...

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

#110

Post by laixintao » Tue, Jan 20, 2026, 2:41 AM UTC

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…

Yes, at least they should test the glibc case.