Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

[Olafur Gudmundsson <[e-mail]>]

On Feb 7, 2014, at 12:18 PM, 神明達哉 <[e-mail]> wrote:

> At Thu, 6 Feb 2014 14:13:05 -0500,
> Warren Kumari <[e-mail]> wrote:
> 
>> At time T+3 the child sees that the parent has published the new key
>> information ( and the standard keyroll stuff has all happened (records
>> are signed with new key, waited for old TTLs to expire, etc)) and so
>> wants to remove the old key.
>> ** This is, as far as I understand, what you were  asking about)
> 
> Yes, and...
> 
>> The child now publishes just the new key info. They stop publishing the old one.
>> Parent:
>>  example.com. 300  IN DS 31589 8 1 123456......
>>  example.com. 300  IN DS 31589 8 1 789ABC......
>> Child:
>>  example.com. 300  IN CDS 31589 8 1 789ABC......
>> [ Child is only publishing new record / they stop publishing the old one ]
>> 
>> At time T+4 the parent checks agin (it polls, the human clicks the
>> button on the web page, some other trigger happens, etc):
>> It sees that what the child has published does not match what the
>> parent currently has, and so it copies the contents from the child.
>> Parent:
>>  example.com. 300  IN DS 31589 8 1 789ABC......
>> Child:
>>  example.com. 300  IN CDS 31589 8 1 789ABC......
>> [ The child and parent are back in sync. The old key (123456...) is no
>> longer in use anywhere. ]
> 
> ...this makes sense, and actually matches what I first thought was the
> intent of the draft.  With this clarification I guess my confusion
> mainly came from the first sentence of Section 4.1:
> 
>   Absence of CDS / CDNSKEY in child signals "No change" to the current
>   DS set.
> 
> Now I understand this is intended to mean "absence of CDS / CDNSKEY
> *RRset*", i.e., absence of any CDS / CDNSKEY.  But it was not super
> clear when I first read it and it could also mean the absence
> (removal) of this CDS at time T+4
> 

Jinmei thanks for pointing this out 
yes you are absolutely right and I have added the word "RRset" into this sentence. 
I'm reading the rest of the document to make sure we are clear in all places 
like this one. 


>  example.com. 300  IN CDS 31589 8 1 123456......
> 
> maybe I was the only person who was confused about this, but it
> wouldn't do any harm to clarify the wording.
> 
> My original question is now resolved, but I have now another about the
> "absence of CDS / CDNSKEY"...
> 
>> This means that you can use this to update / replace / remove existing
>> DS records (if you have keys A, B, C and D and want to stop using C,
>> you simply publish A, B, D), but you cannot remove *all* DS records /
>> go unsigned.
> 
> This is fine, but technically doesn't it contradict Section 3?
> 
>   The CDS / CDNSKEY record is published in the child zone and gives the
>   child control of what is published for it in the parental zone.  The
>   CDS / CDNSKEY RRset expresses what the child would like the DS RRset
>   to look like after the change;
> 
> In that, technically, an empty CDS / CDNSKEY RRset should mean the DS
> RRset at the parent should be empty.  I have no problem with treating
> an empty set as an exception, but I think it would help if the draft
> explains that more explicitly.
> 

Semantics semantics,  
No we are defining the semantics to be "IF C* is published parent DS should mirror that,
if no C* in child --> parent has no action to perform" 

> I'd also note that "absence of CDS" (or CDNSKEY) cannot happen once
> one such RR is published, and it should mean something erroneous (most
> likely an operation error at the child or a bug in its tool).  I think
> it's worth noting in Section 4.1

Why?
Here is a perfectly fine time line
<At start parent DS reflects key A and child uses A to sign DNSKEY RRset> 

Child publishes CDS with A and B 
Parent updates DS to reflect A and B 
Child deletes CDS   

<child performs key roll over from A to B> 

Child publishes CDNSKEY reflecting B 
Parent changes DS to reflect only B 
Child deletes CDNSKEY 


Do you think it is helpful to add an appendix with some examples of use of C* records ? 

> .
> 
> Finally, I'd suggest explicitly clarifying that CDS / CDNSKEY cannot
> be used for a child from signed to unsigned (since it would have to
> remove all CDS / CDNSKEY records to do so).  And, I suspect this is a
> "MUST NOT", unlike the case of initial enrollment described in Section
> 9, because this would break interoperability.
> 

In theory we can use C* to perform the Going-Unsigned operation, and earlier version of this
document proposed that, but people objected and we removed that text. 
We explicitly outlaw going from Unsigned --> Signed w/o some out-of-band validation. 

	Olafur