> Assume that, in the future, a new Delegation Type supersedes > DELEG. Existing resolvers understand DELEG and NS, but not the > new type. > > With the current DELEXT semantics (or with a split where > "delegation types" suppress NS), the referral would contain the > new Delegation Type but no NS RRset. Since the resolver doesn't > implement the new Delegation Type, it cannot use it, and because > there is no NS RRset, it cannot fall back to the legacy delegation > either. The delegation therefore becomes unusable for those > resolvers.
This assumes that operators will add delegations for the new delegation type, leave out DELEG but keep NS when they know that many resolvers don't support the new type. That seems rather odd behavior of operators. > My suggestion is slightly different. If a resolver does not > implement any of the Delegation Types in the referral, but the > referral validates correctly, it falls back to the NS RRset. > Therefore the NS RRset needs to be included in the referral. To me it seems weird to always include the NS RRset in a DELEG delegation (potentially leading to a truncated reply) only because in the future we may introduce a new delegation type and don't want to require operators to have a DELEG delegation. In the future we could also allocate a new EDNS(0) option to allow more precise signalling of what the client supports. Note that a new delegation type without corresponding DELEG RRset is quite similar to what is already discussed, a DELEG RRset without NS RRset. We can defined that to result in NODATA/NXDOMAIN. The same would happen with a new delegation type and no fallback to either NS or DELEG. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
