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

> 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?

This is trivially fixed. 

Let the auth server include both NS and Delegation Types. No need to omit them on the serving side.

On the resolver side, if the set of Delegation Type RRsets contains no servers for the delegated zones, use NS. 

The mere inclusion of a single server in a single Delegation Type, regardless if it is reachable or not, occludes the set of servers in the delegation point NS RRset. 

Roy

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