Dear WG, In light of recent comments that future Delegation Types should co-exist with NS.
The current design has a limitation: Delegation Types always require DELEG (*) to be deployed with it, since NS records will be ignored. This is due to these semantics in current design: - With DE=1, authoritative servers omit the NS RRset when Delegation Types are present. - Resolvers ignore any NS RRset if Delegation Types are present. This behaviour is appropriate for DELEG, where falling back to NS defeats the intended security and privacy properties of the delegation. But it also means that all future Delegation Types require DELEG to be present, even if DELEG contains no additional benefits over the NS RRset. As a result, a Delegation Type that could co-exist with NS cannot be deployed on its own. Although DELEXT is intended to be a generic framework for future Delegation Types, it currently makes DELEG a permanent dependency of that framework rather than a user of it. 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. - 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. - If the resolver does not support any of the Delegation Types in the referral, it falls back to the NS RRset. The result is that DELEG continues to replace NS, while future Delegation Types are free to replace or co-exist with NS, rather than inheriting DELEG’s behaviour. Finally, including the NS RRset in a DE=1 referral does not introduce a new attack. An on-path attacker capable of modifying referrals can already inject an NS RRset. The security property comes from what a resolver is specified to do with that NS RRset, not from whether the server includes it. I am acutely aware that this requirement is new, late in the development of the protocol, and requires additional specification and implementation work. This is not intended as an argument against supporting this requirement, just an acknowledgement that it has schedule and implementation costs. Warmly Roy (*) or other NS replacing Delegation Types defined in the future _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
