> The DE flag was introduced as a capability negotiation mechanism, > indicating that the resolver understands DELEG. Omitting the NS > RRset was a natural optimisation of the protocol semantics adopted > for DELEG (why send NS it if it is not used), but not the purpose > of the DE flag itself.
For unsigned zones, there is no need for a capability negotiation. Just putting both NS and DELEG records in the Authority section is fine. If I remember correctly, somebody tested whether this would cause any problems. So originally, DE was just an optimization. Later it was found that sending DELEG records to legacy resolvers could cause DNSSEC validation errors. So DE became required, but that does not change the original purpose of DE. > > do we want the extra > > complexity for this optimization or not. What does it mean operationally, > > when delegation replies get bigger due to inclusion of NS records. > > The Response size gets larger when all Delegation Types and NS > records are included, compared to solely Delegation Types. That is > indeed a consequence of my proposed modification. However, new > Delegation Types do not necessarily need to have a DELEG RRset, so > the cost of larger responses now should be offset against even > larger responses in the future, if we dont make the change. One option is to split the range of new parent types into delegation types and informational types. That makes it possible to keep the optimization while allowing new types that can be combined with NS. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
