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.
What came first: the CNAME or the A record?
141–150 of 170 posts
Re: What came first: the CNAME or the A record?
#142Re: What came first: the CNAME or the A record?
#143Earlier 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…
Re: What came first: the CNAME or the A record?
#144It'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.
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…
Re: What came first: the CNAME or the A record?
#146My 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?
#147Re: What came first: the CNAME or the A record?
#148Re: What came first: the CNAME or the A record?
#149Earlier 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.
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?
#150Earlier 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.
> "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?