[dns-operations] [Ext] Re: any registries require DNSKEY not DS?

[Edward Lewis]

Answering a pair of messages in one reply:

On 1/23/20, 5:25 AM, "dns-operations on behalf of Paul Vixie" <dns-operations-bounces at dns-oarc.net on behalf of paul at redbarn.org> wrote:

>On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
>> ...
>> 
>> If the parent makes the DS for me from my DNSKEY, well, then the DS
>> suddenly "feels" like it belongs more to the parent than the child,

The semantic meaning of the DS resource record is this - it's a statement by the parent(zone administration) about the child (zone administration).  The presence or absence of the DS record is the parent's signal, even if the contents are determined by the child or from data submitted by the child.

The same "parent for the existence, child for the contents" rule applies to the NS set.  That's probably where the idea came to life.
    
(Pauls'):
>as you see, the DS RRset is authoritative in the parent, in spite of its name 
>being the delegation point, which is otherwise authoritative only in the 
>child. so, DS really is "owned by" the delegating zone, unlike, say, NS.

Yep - Existence of the NS belongs to the parent, that's why it is in the parent's NSEC/NSEC3 chain.  But the targets belong to the child, that's why the parent doesn't sign it.

IMHO - I wish we had something like NSparent (cut/hints) and NSchild (apex/auth).
   
>historians please note: we should have put the DS RRset at $child._dnssec.
>$parent, so that there was no exception to the rule whereby the delegation 
>point belongs to the child. this was an unforced error; we were just careless. 
>so, example._dnssec.com rather than example.com.
    
I'm don't recall the decision process and "Delegation Signer (DS) Resource Record (RR)" (RFC 3658) doesn't discuss why the DS is at the same name.  Underscore names were not yet a concept, although there were earlier thoughts of using different labels in DNSSEC or aggregating DNSSEC information (I have a failing recollection of Ohta's alternative).

Using the underscore idea would eliminate the precedent of a name with authoritative data in two zones but it might have set precedents in the assembly and parsing of referrals (to pick one item).  Meaning - I'm not certain we made a bad choice.  Any approach has it's positives and negatives, eminating from the original choice of placing the (same RR type) NS being at both parent and child.