> On 4 Aug 2026, at 13:42, Philip Homburg <[email protected]> wrote: > >> I think my proposal keeps DELEXT itself simpler. Rather than >> having the generic protocol decide, based on a type range, >> whether NS is replaced, each Delegation Type defines its own >> interaction with NS. Existing implementations automatically >> have a well-defined compatibility behaviour for future Delegation >> Types that they do not yet implement. > > Maybe I misunderstand your proposal. It seems that what you are saying is > the following: > > Suppose we have a secondary DNS server. It knows about DELEG but not > anything else. It gets a zone transfer and the zone has a delegation > type record that the server doesn't know about. Now the secondary cannot > serve the zone because it doesn't know the interaction with NS.
No, the (Delegation-Extension-aware) authoritative server does not need to know the specifics of any Delegation Type. When DE=1, it serves all available Delegation Types, DS and NS records for the delegation point. When DE=0, it doesn’t serve the Delegation types at all. 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. The logic related to understanding the Delegation Types solely resides in the resolver. The resolver ignores delegation types it doesn’t understand. It uses delegation types it does understand, if the type states “do not fall back to NS records” (like DELEG), it doesn’t use the NS records. If a delegation type does not state that (assume that the fictional DS2 is such a record), it may use the NS records. Roy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
