On Thu, Jan 15, 2026 at 12:40 AM Joe Abley <[email protected]> wrote:
> 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. What I’m trying to convey is that we should explicitly specify that clients must accept unordered records. I recognize that resolvers will likely be constrained for the next 10+ years to return ordered RRSets to accommodate implementations that don’t support unordered sets, but I hope this requirement can be relaxed over the long term. By “operational document,” I mean that regardless of what a (possibly future) specification states, in practice a resolver is better off returning an ordered list to maximize the likelihood that its responses are correctly understood. > > > > @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. > Sure, I don't think this is a silver bullet, but it is probably a good follow-up to let glibc know. Thinking back about it, given that it was not a crash on their side, whether it is a bug or not is likely going to be based on the outcome of your proposed document. > > 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. > I’m not sure how I feel about indefinite support for legacy devices. While I understand the motivation, such devices are often riddled with security vulnerabilities and are more likely to become botnet participants than to provide meaningful long-term value. I would love for interoperability to have a bounded timeframe, so we’re not forced to carry technical debt and past mistakes indefinitely. Easier said than done. > 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. I don't entirely disagree. Manu > > > Joe
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
