Re: [dd] [Ext] Desired extensions to today's DNS delegation?

[Paul Wouters <[e-mail]>]

On Thu, 8 Feb 2024, Paul Hoffman wrote:

>> It's not clear to what extent this is related to DNS delegations at all (see draft-sullivan-dbound-problem-statement-02 Section 2) -- but perhaps it may be worth thinking about it for a little (even if only to declare it out of scope).
>
> That's a good addition to the list. Note that this informal list is just possibilities, not definitive. Personally, I'd be happy if people here investigated DBOUND and PSL ideas to see if they might apply.

I generalized this a bit in my draft email yesterday:

- signed statements of child zone policies or properties mapped into parent record (think dnskey flags).

You also had in your list:

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

I think you mean "signed delegation pointer to delegation material". Eg
I don't think you mean actually signing the current NS/glue at the
parent by the parent?

Other items I have:

- A usuable method to kickstart and/or update the alias method purely in
   DNS (think CDS/CSYNC like), avoiding RRR-model issues and delays.

- A controversial one, that might be impossible, but would be cool to have
   so would like the WG to think about it. If we could see multiple DNS hosters
   for the child (each with NS/DS like records), and if one DNS hoster gives
   a non-existent result, to try the other DNS hoster. This would help
   people that feed (eg via REST API) zone updates to multiple DNS
   hosters, in case one of them fails in various different ways.

- Another accidental feature or bug is if the parent contains enough
   information that looking up the child isn't even neccessary anymore.
   eg this is almost like serving without a zone cut. (eg if you have
   A/AAAA/MX of apex, perhaps you don't need anything else from a real child
   zone). Similar to the .de deployment options.

Paul