On 10 Jul 2024, at 11:22, Ray Bellis <r...@bellis.me.uk> wrote: > On 09/07/2024 11:06, Kazunori Fujiwara wrote: >> Dear DNSOP, >> I submitted new draft that proposes to consider "Upper limit value >> for DNS". If you are interested, please read and comment it. > > I disagree with the rationale for 13 name servers. > > The root (and .com) have that because it was what would fit into packets > of a particular size given their naming scheme and that scheme's > efficient compressibility.
More than that, 13 nameservers was the maximum number you could fit in a priming response's additional section without EDNS(0) and assuming a maximally-compressible naming scheme and v4-only nameservers. The same limit is different when all nameserver glue has AAAA+A. It's a number that is historically interesting and it seems to be empirically reasonable given that priming in 2024 seems to work but it's no longer very special for hard, prescriptive reasons. Priming responses are special because the QNAME has a fixed size. This is not generally true for referral responses. So it's even less suitable as a limit there. > IIRC, Vixie et al wrote a draft on this, but it didn't reach RFC status. > > Ah, there it is: > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-respsize-15.txt Yes, I like that draft. From memory it doesn't impose hard limits, it anticipates partial glue in referral responses and gives indicative guidance about the potential for failure instead, which I think is a better approach. I seem to recall it contains code written in Perl which I might argue has not aged well. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
