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

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

#81

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

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.

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

#82

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

bwblabs wrote: post #77

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

> People configure things similar to https://mxtoolbox.com/dmarc/dmarc-setup-cname instructions (which I find in conflict with RFC1034).

I don't think they're advising anyone create both a CNAME and TXT at the same label - but it certainly looks like that from the weird screenshot at step 5 (which doesn't match the text).

I think it's mistakenly a mish-mash of two different guides, one for 'how to use a CNAME to point to a third party DMARC service entirely' and one for 'how to host the DMARC record yourself' (irrespective of where the RUA goes).

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

#83

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

ZoneZealot wrote: post #82

bwblabs wrote: post #77

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

> People configure things similar to https://mxtoolbox.com/dmarc/dmarc-setup-cname instructions (which I find in conflict with RFC1034). I don't think they're advising anyone create both a CNAME and TXT at the same label - but it certainly looks like that from the weird screenshot at step 5 (which doesn't match the text). I think it's mistakenly a mish-mash of two different guides, one for 'how to use a CNAME to poin…

I'm not sure, but we're seeing this specifically with _dmarc CNAMEing to '.hosted.dmarc-report.com' together with a TXT record type, also see this discussion users asking for this at deSEC: https://talk.desec.io/t/cannot-create-cname-and-txt-record-f...

My main point was however that it's really not okay that CloudFlare allows setting up other record types (e.g. TXT, but basically any) next to a CNAME.

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

#84

Post by linsomniac » Mon, Jan 19, 2026, 10:36 PM UTC

>While in our interpretation the RFCs do not require CNAMEs to appear in any particular order

That seems like some doubling-down BS to me, since they earlier say "It's ambiguous because it doesn't use MUST or SHOULD, which was introduced a decade after the DNS RFC." The RFC says:

>The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.

How do you get to interpreting that, in the face of "MUST" being defined a decade later, as "I guess I can append the CNAME to the answer?

Holding onto "we still think the RFC allows it" is a problem. The world is a lot better if you can just admit to your mistakes and move on. I try to model this at home and at work, because trying to "language lawyer" your way out of being wrong makes the world a worse place.

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

#85

Post by fweimer » Mon, Jan 19, 2026, 10:48 PM UTC

ShroudedNight wrote: post #10

I'm not an IETF process expert. Would this be worth filing errata against the original RFC in addition to their new proposed update? Also, what's the right mental framework behind deciding when to release a patch RFC vs obsoleting the old standard for a comprehensive update?

There already is an I-D on this topic (based on previous work): https://datatracker.ietf.org/doc/draft-jabley-dnsop-ordered-...

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

#86

Post by fweimer » Mon, Jan 19, 2026, 10:53 PM UTC

danepowell wrote: post #47

Doesn't the precipitating change optimize memory on the DNS server at the expense of additional memory usage across millions of clients that now need to parse an unordered response?

For most client interfaces, it's possible to just grab the addresses and ignore the CNAMEs altogether because the names do not matter, or only the name on the address record.

Of course, if the server sends unrelated address records in the answer section, that will result in incorrect data. (A simple counter can detect the end of the answer section, so it's not necessary to chase CNAMEs for section separation.)

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

#87

Post by kiwijamo » Mon, Jan 19, 2026, 10:59 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…

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.

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

#88

Post by SahAssar » Mon, Jan 19, 2026, 11:01 PM UTC

Melonai wrote: post #56

diarrhea wrote: post #49

Earlier quoted context omitted.

Randomly fail or (increasingly) delay a random subset of all requests.

That sounds awful and will send administrators on a wild goose chase throughout their stack to find the issue without many clues except this thing is failing at seemingly random times. (I myself would suspect something related to network connectivity, maybe requests are timing out? This idea would lead me in the completely wrong direction.) It also does not give any way to actually see a warning message, where would…

So we arrive at the logical conclusion: You send errors in morse code, encoded as seconds/minutes of failures/successes. Any reasonable person would be able to recognize morse when seeing the patterns on a observability graph.

Start with milliseconds, move on to seconds and so on as the unwanted behavior continues.

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

#89

Post by teddyh » Mon, Jan 19, 2026, 11:15 PM UTC

Cloudflare is well known for breaking DNS standards, and also then writing a new RFC to justify their broken behavior, and getting IETF to approve it. (The existence of RFC 8482 is a disgrace to everyone involved.)

> 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

Of course.

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

#90

Post by fweimer » Mon, Jan 19, 2026, 11:16 PM UTC

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.

The last time this came up, people said that it was important to filter out unrelated address records in the answer section (with names to which the CNAME chain starting at the question name does not lead). Without the ordering constraint (or a rather low limit on the number of CNAMEs in a response), this needs a robust data structure for looking up DNS names. Most in-process stub resolvers (including the glibc one) do not implement a DNS cache, so they presently do not have a need to implement such a data structure. This is why eliminating the ordering constraint while preserving record filtering is not a simple code change.