Live data from Hacker News

What came first: the CNAME or the A record?

blog.cloudflare.com

141–150 of 170 posts

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

#141

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 approach only makes sense if tests are immutable though. If you are unsure if the order matters you should still test for it so you get a reminder to re-check your assumptions when the order changes.

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

#142
This all reads like an embarrassed engineer who can’t admit they neglected to have a comprehensive to-the-byte test suite for their second-most-important-on-the-Internet DNS server, overcompensating by blaming a 40-year-old standard that (1) they probably hadn’t consulted, and (2) no one else seems to have issues with; and proposing to update core Internet standards, rather than just accept that they made a mistake when they assumed they could just append to what any regular user of DNS expects to be a meaningfully-ordered list.

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

#143
post #94

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…

> 4. 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 "Testing environment" sounds to me like a real network real user devices are used with (like the network used inside CloudFlare offices). That's what I would do if I was developing a DNS server anyway, other than unit tests (which obviously wouldn't cat…

For the output of Cloudflare’s DNS server, which serves a huge chunk of the Internet, they absolutely should have a comprehensive byte-by-byte test suite, especially for one of the most common query/result patterns.

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

#144

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 not remarkable, because it’s the way all DNS servers work. Order is important in DNS results. It’s why results with multiple A records are returned in shuffled orders: because that impacts how the client interprets the results. Anyone who works with DNS regularly beyond just reading the RFCs ought to recognize this intuitively.

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

#145

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

The RFC is also 39 years old! At this point, DNS is what existing software expects it to be, not what someone proposed in the mid-eighties. The fact that they did not have any testing to match exact byte-by-byte responses with existing behavior and other DNS resolvers for this layer of service is massively irresponsible.

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

#146
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.

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

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

#149
post #23

Earlier quoted context omitted.

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

I think it is okay to accept liberally as long as you combine it with warnings for a while to give offenders a chance to fix it.

Warnings only work if the person receiving them is either capable of and motivated to do something about it, or capable of motivating the person/people capable of doing something about it.

A weak warning that's just an entry in a scrolling console means nothing to end users and can be ignored by devs. A strong warning that comes out as a modal dialog can still be ignored by devs and then just annoys users. See the early era of Windows UAC for possibly the most widespread example of a strong warning added after the fact.

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

#150

Earlier quoted context omitted.

> I assume some tests at least broke that meant they needed to be "fixed up" OP said: "However, we did not have any tests asserting the behavior remains consistent due to the ambiguous language in the RFC." One could guess it's something like -- back when we wrote the tests, years ago, whoever did it missed that this was required, not helped by the fact that the spec proceeded RFC 2119 standardizing the all-caps "MUS…

You'd think that something this widely used would have golden tests that detect any output change to trigger manual review but apparently they don't.

Oh, they explain, if I understand right, they did the output change intentionally, for performance reasons. Based on the inaccurate assumption that order did not matter in DNS responses -- becuase there are OTHER aspects of DNS responses in which, by spec, order does not matter, and because there were no tests saying order mattered for this component.

> "The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS." [from RFC]

> However, RFC 1034 doesn’t clearly specify how message sections relate to RRsets.

The developer(s) was assuming order didn't matter in general, cause the RFC said it didn't for one aspect, and intentionally made a change to order for performance reasons. But it turned out that change did matter.

Mistakes of this kind seem unavoidable, this one doesn't necessary say to me the developers made a mistake i never could or something.

I think the real conclusion is they probably need tests using actual live network stacks with common components, and why didn't they have those? Not just unit tests or with mocks, but tests that would have actually used real getaddrinfo function in glibc and shown it failing?

Post reply on HN