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

151–160 of 170 posts

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

#151

Post by skywhopper »

hdjrudni wrote: post #37
supriyo-biswas wrote: post #9

Earlier quoted context omitted.

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.

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.

That would be silly to stick that tightly to a 40 year old standard. They can easily observe the behavior of every other public DNS resolver (they are Cloudflare, so gathering data on such a scale should be easy) and see how they return results.

Honestly, though, I’d be surprised if they actually even considered it. Everything about the article says to me that the engineer(s) who caused this problem are desperately trying to deflect blame for not having a comprehensive test suite. Sorry, but you don’t go tweaking order of results for such a long-standing, high volume, and crucial protocol just because the 40 year old spec isn’t clear about it.

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

#153

Post by alt227 »

skywhopper wrote: post #146
Gigachad wrote: post #81

Earlier quoted context omitted.

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.

Cloudflare broke clients all over the world. What the 40 year old RFC says is not the de facto “specification” at this point.

Cloudflare broke 'Cisco' clients all over the world. Not CFs problem that the biggest router vendor in the world programmed their routers wrongly.

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

#154

Post by alt227 »

teddyh wrote: post #89

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.

This really depends on what side of the fence you are on.

As a website host/maintainer, I am happy that the DNS 'ANY' query has been deprecated.

I am sure if you are a network engineer or ISP, then it propbably annoys you no end.

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

#155

Post by mdavid626 »

t0mas88 wrote: post #71
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.

I’d test such scenarios as well. Run many real glibc resolvers for a while. Sooner or later caching issue would surface.

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

#156

Post by 1vuio0pswjnm7 »

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…

Sometimes software written by others provides compile-time options to disable getaddrinfo or IPv6. Sometimes the software onllly uses gethostbyname

For example,

tinydns (only uses gethostbyname)

nsd (--disable-ipv6)

I compile static binaries with musl. I do not use glibc

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

#157

Post by tcdent »

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?

Agreed. Seems like a pretty risky optimization that fundamentally changed behavior; like it or not the ordering of vectors is often part of the data structure.

Could have just used a prepend to preserve behavior instead pf going down the rabbit hole of re-interpreting the RFC (which is a cop out IMO; it worked before, a change broke it).

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

#158

Post by bigstrat2003 »

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…

My initial reading was "you can place them wherever you want". And given that multiple parties are naturally interpreting the wording in different ways, that means the wording is ambiguous by definition.

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

#159

Post by 1vuio0pswjnm7 »

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…

It appears that some people prefer IPv4 and do not need IPv6

For example, from another story (about IP addresses) on today's HN front page:

https://news.ycombinator.com/item?id=46693867

https://news.ycombinator.com/item?id=46695198

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

#160

Post by fweimer »

Dylan16807 wrote: post #128
fweimer wrote: post #90

Earlier quoted context omitted.

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

Doesn't it need to go through the CNAME chain no matter what? If it's doing that, isn't filtering at most tracking all the records that matched? That requires a trivial data structure. Parsing the answer section in a single pass requires more finesse, but does it need fancier data structures than a string to string map? And failing that you can loop upon CNAME. I wouldn't call a depth limit like 20 "a rather low limi…

I don't know if the 20 limit is large enough in practice. People do weird things (after migrating from non-DNS naming services, for example). Then there is label compression, so you can have theoretically have several thousand RRs in a single 64 KiB response. These numbers are large enough that a simple multi-pass approach is probably not a good idea.

And practically speaking, none of this CNAME-chain chasing adds any functionality because recursive servers are expected to produce ready-to-use answers.

Post reply on HN