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

So, the question is: do we want delext to make it possible to define

new parent-side types that work with NS?

Yes.

tim


On Wed, Jul 22, 2026 at 1:54 PM Blacka, David <davidb=
[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?
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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