Hi Manu, On 15 Jan 2026, at 07:26, Manu Bretelle <[email protected]> wrote:
> Agreed, it seems the spec should rather specify that clients should be > prepared to > receive records in any order. > An operational document may indicate on the other hand that a public resolver > may > need to sort the rrsets in order to have all shades of clients in the wild > internet be able to > understand the response, but this should probably not prescribe resolvers > within the > confines of a private network from not caring about order. I'm a bit confused about this concept of "operational document". I have never seen DNS software where operators have a configuration option to control the order in which RRSets are included in an answer section, or the policy for accepting them when receiving a DNS response. The way we try to ensure interoperabiity between implementations is with protocol standards. If the protocol standard says "do what you want, it should all be fine" but in practice particular choices lead to global outages, I don't see how that favours interoperability. > @Joe, it seems Cisco was made aware of the issue, but the blog post also > mention glic > being affected (to a lesser order given it is not segfaulting). Did you folks > communicate with > them, file a bug? I did not see anything in their bugzilla [0]. I am not the authority on what the team has done (perhaps Sebastiaan can comment) but I think the general assumption has been that even if a bug was filed and glibc was updated, there is likely to be enough deployed software in the world linked to unpatched libc that will never be updated that it will never be safe to imagine that 1.1.1.1 should do that again. Similarly, I note that there's an awful lot of network hardware in the world from old, established vendors that will never be patched and will never see a support contract. Really, I think updating the standard to require particular ordering in the answer section is the best, most pragmatic answer even if it seems inelegant or theoretically undesirable. I don't see a practical objection to doing so, to be honest -- it's what substantially all implementations do anyway. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
