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

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

#71

Post by t0mas88 » Mon, Jan 19, 2026, 9:37 PM UTC

mdavid626 wrote: post #45

I would expect, that dns servers like 1.1.1.1 at this scale have integration tests running real resolvers, like the one in glibc. How come this issue was discovered only in production?

This case would only happen if a CNAME chain first expired from the cache in the wrong order and then subsequently was queried via glibc. Theirs tests may test both that glibc resolving works and that re-querying expired records works, but not the combination of the two.

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

#72

Post by t0mas88 » Mon, Jan 19, 2026, 9:37 PM UTC

wolttam wrote: post #69

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

Is the property of an answer being ordered in the order that resolutions were performed to construct it /that/ fragile? Randomization within the final answer RRSet is fine (and maybe even preferred in a lot of cases)

Well cisco had their switches get into a boot loop, that sounds very broken...

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

#73

Post by SAI_Peregrinus » Mon, Jan 19, 2026, 9:39 PM UTC

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?

Probably Alpine containers, so musl's version instead of glibc's.

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

#74

Post by immibis » Mon, Jan 19, 2026, 9:42 PM UTC

silverwind wrote: post #26

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.

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

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

#75

Post by immibis » Mon, Jan 19, 2026, 9:43 PM UTC

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…

Your code runs slower on mobile devices, since (as a rule of thumb) mobile networks are ipv6-only and ipv4 traffic has to pass through a few layers of tunneling.

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

#76

Post by urbandw311er » Mon, Jan 19, 2026, 9:56 PM UTC

I feel like they fucked it up then, when writing the post-mortem, went hunting for facts to retrospectively justify their previous decisions.

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

#77

Post by bwblabs » Mon, Jan 19, 2026, 10:00 PM UTC

I will hijack this post to point out CloudFlare really doesn't understand RFC1034, their DNS authoritative interface only blocks A and AAAA if there is a CNAME defined, e.g. see this:

  $ echo "A AAAA CAA CNAME DS HTTPS LOC MX NS TXT" | sed -r 's/ /\n/g' | sed -r 's/^/rfc1034.wlbd.nl /g' | xargs dig +norec +noall +question +answer +authority @coco.ns.cloudflare.com
  ;rfc1034.wlbd.nl.  IN A
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN AAAA
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN CAA
  rfc1034.wlbd.nl. 300 IN CAA 0 issue "really"
  ;rfc1034.wlbd.nl.  IN CNAME
  rfc1034.wlbd.nl. 300 IN CNAME www.example.org.
  ;rfc1034.wlbd.nl.  IN DS
  rfc1034.wlbd.nl. 300 IN DS 0 13 2 21A21D53B97D44AD49676B9476F312BA3CEDB11DDC3EC8D9C7AC6BAC A84271AE
  ;rfc1034.wlbd.nl.  IN HTTPS
  rfc1034.wlbd.nl. 300 IN HTTPS 1 . alpn="h3"
  ;rfc1034.wlbd.nl.  IN LOC
  rfc1034.wlbd.nl. 300 IN LOC 0 0 0.000 N 0 0 0.000 E 0.00m 0.00m 0.00m 0.00m
  ;rfc1034.wlbd.nl.  IN MX
  rfc1034.wlbd.nl. 300 IN MX 0 .
  ;rfc1034.wlbd.nl.  IN NS
  rfc1034.wlbd.nl. 300 IN NS rfc1034.wlbd.nl.
  ;rfc1034.wlbd.nl.  IN TXT
  rfc1034.wlbd.nl. 300 IN TXT "Check my cool label serving TXT and a CNAME, in violation with RFC1034"

The result is DNS resolvers (including CloudFlare Public DNS) will have a cache dependent result if you query e.g. a TXT record (depending if it has the CNAME cached). At internet.nl (https://github.com/internetstandards/) we found out because some people claimed to have some TXT DMARC record, while also CNAMEing this record (which results in cache dependent results, and since internet.nl uses RFC 9156 QName Minimisation, if first resolves A, and therefor caches the CNAME and will never see the TXT). People configure things similar to https://mxtoolbox.com/dmarc/dmarc-setup-cname instructions (which I find in conflict with RFC1034).

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

#78

Post by urbandw311er » Mon, Jan 19, 2026, 10:00 PM UTC

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…

The whole world knows this except Cloudflare who actually did know it but are now trying to pretend that they didn’t.

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

#79

Post by urbandw311er » Mon, Jan 19, 2026, 10:02 PM UTC

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 — hot take — to find out that you made some silly misinterpretation of the RFC that you then felt the need to retrospectively justify.

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

#80

Post by Gigachad » Mon, Jan 19, 2026, 10:08 PM UTC

n2d4 wrote: post #18

mmastrac wrote: post #13

Earlier quoted context omitted.

Postel's law is considered more and more harmful as the industry evolved.

Very much so. A better law would be conservative in both sending and accepting, as it turns out that if you are liberal in what you accept, senders will choose to disobey Postel's law and be liberal in what they send, too.

The modern view seems to be you should just immediately abort if the spec isn't being complied with since it's possibly someone trying to exploit the system with malformed data.