[DNSOP] draft-ietf-dnsop-delext and non-useful parent-side typ es

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]