[dd] Listing of mentioned potential desired extensions to today's DNS delegation

[Paul Hoffman <[e-mail]>]

Greetings again. Thanks for your earlier comments on the beginnings of the list of possible desired extensions for DNS delegation. This will help us as we formulate a proposed charter for the future WG.

The following is a fuller list of desired extensions mentioned in the mailing list, along with an initial list of how those desired extensions might be implemented in later protocols. Again, these are just preliminary lists, mostly to help people think more about how to form a charter. It is likely that only a subset of the list will be considered.  Other ideas will also likely come up in the eventual WG chartering discussion.  Most importantly, many of these might be significantly out of scope from a likely initial charter but are listed here for sake of completeness.


- Aliasing: A single-step mechanism that says "all of the delegation material for the child can be found on that server over there"

- Signed NS and glue records: Greater assurance for validating resolvers of information they receive currently

- Other DNS transports: Know what non-port-53 transports the given name servers can use

- Child specific centricity: only use parental information to bootstrap gathering full information from the child

- DBOUND/PSL: Declare that this is a policy boundary (maybe is not related to delegation), potentially with historical information

- Split delegation: Parent delegates, but also is authoritative for some RRtypes for the child

- DS pinning for particular nameservers: The resolver will only expect specified signing algorithms to be used by specified name servers.  This is specifically needed for improved multi-signer DNSSEC situations.

- Error reporting destination: Specify where error reports can be sent to when the delegated name servers behave unexpectedly

- Denial support: A mechanism to allow a nameserver to deny that it serves that zone

- Auto delegation updates: Auto-signaling of changes in delegation information, with increased usability over existing choices (CDS/CSYNC)

- Child zone policies and properties: Signed statements of child zone policies or properties mapped into the parent (akin to DNSKEY flags)

- Multi-hosting failure detectiong: Better detection for moving between multi-hosting environments when one is failing

- Do not contect: Indication from the parent that contacting the child is not necessary after this response


How they might be implemented 

Specifying delegation extensions
 Single new RRtype, extensible, in Authority section
 Multiple new RRtypes, each specific to an extension, in Authority section
   Reserve a range of RRtypes at IANA to indicate "resolve at parent"
 Overload DS records (requires changing DS display format)
 Allow aliasing of DS records in DS (requires changing DS display format)
 EDNS0

Aliasing
 Target has a SVCB record IP addresses of delegated servers
 If one alias among multiple gives a bad result, try another

Signed NS and glue records
 Put in a new RR, sign that
 Add signatures for NS and glue in reply

Child centricity
 Parent and child both have delegation records, use child's unless parent's is signed and child's isn't
 DBOUND/PSL in child can point one level up