What came first: the CNAME or the A record?

Posted by linolevan 1/19/2026

What came first: the CNAME or the A record?(blog.cloudflare.com)

189 points | 74 commentspage 2

sebastianmestre 1/19/2026|

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

tuetuopay 1/19/2026||

Many rightfully interpret the RFC as "CNAME have to be before A", but the issue persists inbetween CNAMEs in the chain as noted in the article. If a record in the middle of the chain expires, glibc would still fail if the "middle" record was to be inserted between CNAMEs and A records.

It’s always DNS.

danepowell 1/19/2026||

Doesn't this 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?

Dylan16807 1/19/2026|

The memory involved is a kilobyte. The optimization isn't important anywhere. The fragility is what's important.

Also no, the client doesn't need more memory to parse the out-of-order response, it can take multiple passes through the kilobyte.

runningmike 1/19/2026||

The end of this blog is …. “ To learn more about our mission to help build a better Internet,”

Reminds me of https://news.ycombinator.com/item?id=37962674 or see https://tech.tiq.cc/2016/01/why-you-shouldnt-use-cloudflare/

urbandw311er 1/19/2026||

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

ShroudedNight 1/19/2026||

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?

hdjrudni 1/19/2026|

I don't know the official process, but as a human that sometimes reads and implements IETF RFCs, I'd appreciate updates to the original doc rather than replacing it with something brand new. Probably with some dated version history.

Otherwise I might go to consult my favorite RFC and not even know its been superseded. And if it has been superseded with a brand new doc, now I have to start from scratch again instead of reading the diff or patch notes to figure out what needs updating.

And if we must supersede, I humbly request a warning be put at the top, linking the new standard.

ShroudedNight 1/19/2026||

At one point I could have sworn they were sticking obsoletion notices in the header, but now I can only find them in the right side-bar:

https://datatracker.ietf.org/doc/html/rfc5245

I agree, that it would be much more helpful if made obvious in the document itself.

It's not obvious that "updated by" notices are treated in any more of a helpful manner than "obsoletes"

paulddraper 1/19/2026||

> 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 on the way to an answer.

> While "possibly preface" can be interpreted as a requirement for CNAME records to appear before everything else, it does not use normative key words, such as MUST and SHOULD that modern RFCs use to express requirements. This isn’t a flaw in RFC 1034, but simply a result of its age. RFC 2119, which standardized these key words, was published in 1997, 10 years after RFC 1034.

It's pretty clear that CNAME is at the beginning.

The "possibly" does not refer to the order but rather to the presence.

If they are present, they are are first.

urbandw311er 1/19/2026|

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

kayson 1/19/2026|

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

Maybe I'm being overly-cynical but I have a hard time believing that they deliberately omitted a test specifically because they reviewed the RFC and found the ambiguous language. I would've expected to see some dialog with IETF beforehand if that were the case. Or some review of the behavior of common DNS clients.

It seems like an oversight, and that's totally fine.

bombcar 1/19/2026||

I took it as being "we wrote the tests to the standard" and then built the code, and whoever was writing the tests didn't read that line as a testable aspect.

kayson 1/19/2026||

Fair enough.

supriyo-biswas 1/19/2026||

My reading of that statement is their test, assuming they had one, looked something like this:

    rrs = resolver.resolve('www.example.test')
    assert Record("cname1.example.test", type="CNAME") in rrs
    assert Record("192.168.0.1", type="A") in rrs

Which wouldn't have caught the ordering problem.

hdjrudni 1/19/2026||

It's implied that they intentionally tested it that way, without any assertions on the order. Not by oversight of incompetence, but because they didn't want to bake the requirement in due to uncertainty.

More comments...