> On 15. 1. 2026, at 12:41, Joe Abley <[email protected]> > wrote: > >> I think that you are motivated by the scale how the broken clients are >> wide-spread, and how crippled upgrade policies prevent upgrading them in >> reasonable time. However, writing and publishing an RFC also doesn't happen >> in a short time. > > Yes, that's totally the motivation. > > I think of this as an investment in the future; if we can avoid future > disasters (even small ones) by making a decision now, I think the return on > investment is reasonable.
The last time we used the "scale" as a motivation, we got serve-stale, a DNS protocol breaking bandaid, and we all still suffer from that. > On 15. 1. 2026, at 3:29, 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. If anything, I would say that the language should be: - caches and forwarders SHOULD emit the records in chain order so that badly written stubs won't break - stubs resolvers MUST accept records in any order so badly written caches won't break them Ondrej -- Ondřej Surý (He/Him) [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
