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.

▲

pixl97 11 hours ago | parent | next [-]

I think it's more of a server side ordering, in which there were not that many DNS servers out there, and the ones that didn't keep it in order quickly changed the behavior because of interop.

CNAMES are a huge pain in the ass (as noted by DJB https://cr.yp.to/djbdns/notes.html)

▲

silverwind 11 hours ago | parent | prev | next [-]

It's more likely because the internet runs on a very small number of authorative server implementations which all implement this ordering quirk.

▲

immibis 8 hours ago | parent [-]

This is a recursive resolver quirk

	▲	zinekeller 6 hours ago \| parent [-]
		... that was perpetuated by BIND. (Yes, there are other recursive resolver implementations, but they look at BIND as the reference implementation and absent any contravention to the RFC or intentional design-level decisions, they would follow BIND's mechanism.)

▲

fweimer 7 hours ago | parent | prev [-]

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.