> On 4 Aug 2026, at 15:53, Philip Homburg <[email protected]> wrote: > >> Both primary and secondary servers do not need to know anything >> about Delegation Types, other than to serve those when DE=1. Zone >> Transfers are unaffected. > > Correct me if I'm wrong but it seems that your current solution always > includes the NS RRset in a delegation reply (if it exists).
Ack. In my proposal, NS/Glue are present independent of DE flag. DE=1 means that Delegation Types are added to a referral. > With a split range, the NS RRset would be left out if any delegation types > are present. So split range idea leads to smaller replies for the DELEG > use-case. That is correct, but see below. > For example, in your proposal the following would be part of a delegation > to .com in addition to any DELEG records. If we add DS and RRSIG records then > current delegation is already 1163 octets. I wonder what effect that will > have on glue. For .com, glue is in theory optional. .net has the same > delegation where glue is not optional. > $ dig @a.root-servers.net com. a I note that .com is an extreme case rather than the common case. Only three delegations in the root zone have 13 name server names. As a rough estimate, a single NS record adds about 22 octets, depending on the target name and the available compression pointers. An A record adds 16 octets, and an AAAA record adds 28 octets. This gives approximately: 38 octets for an NS/A combination and 66 octets for an NS/A/AAAA combination. A quick histogram of today’s .com zone (roughly 165 million delegations) gives the following distribution of name server counts per delegation: NS count. Delegation 1 34939 2 128486053 3 10046108 4 22644556 5 1702108 6 539256 7 203418 8 1433091 9 3591 10 7488 11 838 12 14183 13 595 The largest group is therefore roughly 128 million delegations, or 78%, with two name servers. For those delegations, retaining NS records and any required IPv4 glue would add about 76 octets, or about 132 octets where both IPv4 and IPv6 glue are present for each name server. The next-largest group is roughly 22 million delegations, or 13%, with four name servers. The corresponding increase would be about 152 octets with IPv4 glue, or about 264 octets with both IPv4 and IPv6 glue. I’m not convinced that omitting NS and glue when DE=1 is a worthwhile optimisation. It does not appear to provide a clear benefit to the resolver, the operator, or the domain holder, while it introduces different referral behaviour depending on whether DE is set. The size benefit is also short-lived. Under the current proposal, any future Delegation Type requires a DELEG RRset to be present. That RRset carries an additional RRSIG, eliminating the referral-size savings from omitting NS and glue. Under the split range proposal, “informational” Delegation Types already allow NS and glue records. Given that, I’m not convinced the added complexity of prohibiting NS and glue elsewhere is justified by the relatively modest savings in referral size. If a referral occasionally exceeds the commonly used 1232-byte UDP payload limit, DNS has a well-defined mechanism for handling that case: TCP. TCP is a fundamental part of DNS and I don’t think occasional use of TCP should drive the protocol design. Roy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
