Hi Libor, On 14 Jan 2026, at 23:12, Libor Peltan <[email protected]> wrote:
> I don't like that this document only refers (and updates) RFC1034, and > ignores the existence of RFCs for DNSSEC (in particular!), CNAME, DNAME, etc. CNAME processing is described in RFC 1034 and 1035, so I think that is covered. I think DNAME processing is interesting, and we could consider spelling that out (as was mentioned earlier). I am not sure about DNSSEC. The observed problem that we have is that the ordering of RRSets in the answer section seems to matter to several important implementations of stub resolver. The stub resolvers that are observed to be sensitive don't receive RRSIGs in the answer section, since they don't send queries with DO=1. Including additional requirements for DNSSEC seems like it might complicate implementation of DNSSEC-aware nameservers without having an operational benefit. > It can be easily seen that the construction of DNS responses (all of their > sections) vary across DNS implementations, and I don't think this is really a > problem. On the contrary, I think what we have seen is that there are important and widespread assumptions about the ordering of RRSets in the answer section, and not paying attention to those assumptions makes things break in surprising ways. > 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...? The answer section *is* special, not for any philosophical or design reason, but because we know that arbitrary ordering of RRSets there breaks the Internet. Joe _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
