[dd] A generalised delegation extension mechanism

[Roy Arends <[e-mail]>]

The following is based on [1] by Petr Spacek and Peter van Dijk and conversations with Paul Wouters and Ben Schwartz (This namedropping should not be seen as endorsements for the following, but merely credit where credit is due).

To make delegations truly extensible, the extension mechanism (the changes to the DNS protocol) to allow DELEG to work, and DELEG (the record, and what it facilitates) should be separate and the extension mechanism should be generalised..

The “generalised” delegation extension mechanism states what to include in a delegation response and how to signal to the validator that it must expect this information. It would contain an IANA request to mark a range of RRTYPEs as “parent side only”. (See [1]). An authoritative server must include these in a delegation when they are present in a zone (such as DS records), including the authenticated denial record (this “always include NSEC/NSEC3” is an idea from Ben Schwartz)

Why?

Future "parent side only” record types should not require a new signalling mechanism. (Paul Wouters insight, and I agree)
Authoritative (secondary) servers that know to include records from a range in a delegation do not need to understand these records. They can be an opaque blob. 

Roy Arends

[1] see https://www.ietf.org/archive/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt