[DNSOP] Re: draft-ietf-dnsop-delext and non-useful parent-si de types

> On 22 Jul 2026, at 22:04, Roy Arends <[email protected]> wrote:
> 
> 
> 
>> On 22 Jul 2026, at 19:53, Blacka, David <[email protected]> wrote:
>> 
>> In a long conversation with Petr about how the DelegationTypes work,
>> we came to the realization that as written, delext prevents the
>> definition of new delegation types that work with NS.
>> Imagine defining a new successor to the "DS" type, "DS2". It provides
>> information about a delegation, but doesn't provide any useful
>> information for *following* the delegation.  Instead, it contains other
>> information about the child zone.  We want this record to live at the
>> parent side of a delegation, so we assign its type from the
>> DelegationType range. But since it is just some info about the child
>> zone, you might expect it to work both with DELEG and with only NS.
>> However, delext prevents that (for good reason.)  For example, it
>> says in Section 4.1:
>>      When the DE flag is set to 1, the server includes Delegation Type
>>     RRsets in referrals and omits the NS RRset. When there are no
>>     Delegation Type RRsets for a referral, it includes the NS RRset. For
>>     DNSSEC-signed zones, the response MUST include DNSSEC proof of the
>>     presence or absence of Delegation Types for the delegated name
>> The goal of delext is to allow us to define new "parent-only" types
>> without having to change every component of the DNS ecosystem every
>> time.  This doesn't work unless every DelegationType "forms a
>> delegation", even if it can't usefully do that by itself.
>> If we want parent-only-but-not-delegation-forming types that could be
>> used with NS, I think we would need *two* ranges: one for
>> delegation-forming parent-side records (which would have the currently
>> described behavior), and another one for non-delegation-forming
>> parent-side records.  This second range would have some different
>> rules -- i.e., would not trigger the above rule, would not be usable
>> in the set of types used in RFC 6840 section 4.1.
>> With the current delext range and rules, if you published our
>> imaginary DS2 record at a delegation with only NS records, this would
>> form a resolution dead end for DE=1 aware resolvers.
>> This doesn't seem to be an insurmountable problem, though.  It is
>> fairly trivial to synthesize a DELEG record from an NS RRset.
>> So, the question is: do we want delext to make it possible to define
>> new parent-side types that work with NS? or are we ok that all new
>> delegation types either need to be DELEG successors or be served
>> with DELEG?

Reply to myself:

> This is trivially fixed. 

NO IT ISNT

(Note to self, get some sleep!)

Roy

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]