Answering a pair of messages in one reply:
On 1/23/20, 5:25 AM, "dns-operations on behalf of Paul Vixie"
<dns-operations-boun...@dns-oarc.net on behalf of p...@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.
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
