On Wed, Jan 14, 2026 at 6:31 PM John Levine <[email protected]> wrote:
> It appears that Libor Peltan <[email protected]> said: > >Anyway, shouldn't we rather go the opposite way of declaring that any > >section of DNS response is unordered (why should the answer section be > >special?) and the receiver MUST be able to find all the wanted info > >regardless -- even in ridiculous cases when the CNAME target is put > >first and the CNAME itself afterwards...? > > It seems to me that if we are going to say anything, we should both say > that > caches and forwarders have to emit the records in chain order so that badly > written stubs won't break, and stubs have to accept records in any order so > badly written caches won't break them. > 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. @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]. Thanks, Manu [0] https://sourceware.org/bugzilla/buglist.cgi?component=nss&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&product=glibc&query_format=advanced&resolution=--- > > This is one of the few situtations I can think of where Postel's principle > really applies, since the spec is unclear. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
