Hi Roy, I like your proposal. Indeed I believe it is simpler, not more complex, than the 2-range proposal, and it is also functionally cleaner than the previous one.
One point below. On 7/28/26 12:59, Roy Arends wrote:
To account for future Delegation Types to be DELEG independent, I’d like to propose the following: - When DE=1, the authoritative server includes all Delegation Type RRsets present at the delegation point, together with the NS RRset (if one exists). In the current design, a server omitting an NS RRset is an optimisation, not a security feature. - Delegation Type specifications define their interaction with the NS RRset. For example, DELEG specifies that it replaces the NS RRset, and resolvers implementing DELEG MUST ignore the NS RRset when processing a DELEG RRset. Other Delegation Types default to working with NS, unless specified otherwise. This allows unknown and private Delegation types to work without DELEG.
I note (for below) an asymmetry: Each Delegation Type specification defines the interaction with the NS RRset on the resolver side, but authoritative servers always serve the NS RRset if present, without allowing the type specification to define an exception to omit in, in correspondence with / anticipating resolver-side processing.
- If the resolver supports the Delegation Types present in the referral, it processes them according to their specifications. If at least one of those Delegation Types specifies that the NS RRset must not be used (such as DELEG), the resolver MUST ignore the NS RRset. Otherwise, the resolver uses the NS RRset.
More explicitly: It's conceivable for a resolver to implement DelExt with this adjustment, but not support the DELEG type. Such a resolver would send DE=1, but still use NS for delegation. The possibility of situations like this is probably the reason for the above asymmetry: The Delegation Type specification cannot define, in analogy to resolver-side handling, that authoritative servers may omit the NS RRset when serving that type, even when DE=1 is present -- because you don't know that the resolver supports the type (including DELEG). It could still need the NS RRset. This wasn't obvious to me; at first I thought symmetric treatment may be fine for size optimization, and it only became clear to me once I tried writing it up to propose it. Perhaps it would be instructive to document this rationale in the spec. (Let me know if you'd like text from me! Else I'll assume you know your way around the document better/quicker ...) Best, Peter _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
