Re: [dnsext] CDS RRTYPE review - Comments period end Mar 29th

[Olafur Gudmundsson <[e-mail]>]

<hat="RFC3658-editor">

On 09/03/2011 8:30 AM, Scott Schmit wrote:
> On Tue, Mar 08, 2011 at 08:32:05PM +0000, Tony Finch wrote dnsext:
>> On Tue, 8 Mar 2011, Roy Arends wrote:
>>>
>>>     D.    Motivation for the new RRTYPE application?
>>>
>>>           To allow a copy of the DS RRset [RFC4034] to be published
>>>           in the child zone, which is used to update the parent DS RRset.
>>>           It is expected that this will allow the rollover of a key signing
>>>           key to be automated.
>>
>> Why not just use the child zone's SEP DNSKEY RRs for this purpose?
>
> I'm inclined to agree with this, but even if it's decided that the
> DNSKEY RRs aren't sufficient, why not just use DS on the client side? I
> see that RFC 3658 forbids it, but I'm not sure I understand why.  We
> don't have CNS in addition to NS, so why should DS be different? I can
> understand that DS must be ignored by a client unless it's signed by the
> parent, but if that check doesn't already exist, we're already in
> trouble.

Using SEP bits in DNSKEY records does not work when a zone wants to 
retire an algorithm, the DS MUST be removed before the corresponding 
DNSKEY record is removed.

>
> So, maybe they didn't think of the use case this draft is trying to
> address and forbade it to keep the software implementations simpler? But
> that could have been accomplished simply by saying that a DS on the
> child side is ignored for validation purposes (it now becomes pointless
> (but harmless) to include it, except as a way to securely send DS
> records from the child to the parent).

RFC3658 specified for the first time a record that can only live at the 
parent and this required major changes to resolution algorithm 
implementations.
If there is anything we have learned in the last 25+ years of DNS is 
this: "If the same information can appear in two places it will not be 
the same and you have no idea which version resolvers will use"
Just look at what different resolvers do when the parent and child NS 
records differ.


> I can understand the motivation of introducing a new RRTYPE to avoid
> needing to alter existing MUST NOTs, but CDS just seems unnecessary.
>
> Maybe there's another reason to forbid DS on the child side that I've
> overlooked?
>

see above, and new types a cheap, and this gives the child full control
over the changes in the DS in parent. Similarly this can be used to 
update trust anchors for an Island of security.

<disclaimer>
I encouraged George to submit this, as I had the same idea about the 
same time as he did, in the context of automating DNS operator 
change/transfer.
</disclaimer>
This record does not change the DNS control plane (resolvers) it is only 
published for information purposes and to be used by zone content 
management tools.

	Olafur

PS: I think that original DNS had NS RRset in two places was the biggest 
design mistake and we have spent lots of time and effort to overcome 
that. This choice was done for expediency and/or optimization reasons. s