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

Olafur Gudmundsson <> Fri, 07 February 2014 18:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9703B1ACCE9 for <>; Fri, 7 Feb 2014 10:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9a7AttGesKz6 for <>; Fri, 7 Feb 2014 10:26:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AB8C51ACCDE for <>; Fri, 7 Feb 2014 10:26:53 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (SMTP Server) with ESMTP id 6A5411B80B0; Fri, 7 Feb 2014 13:26:53 -0500 (EST)
X-Virus-Scanned: OK
Received: by (Authenticated sender: with ESMTPSA id C5EDF1B8083; Fri, 7 Feb 2014 13:26:52 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Fri, 7 Feb 2014 13:26:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <>
X-Mailer: Apple Mail (2.1510)
Cc: dnsop <>
Subject: Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2014 18:26:55 -0000

On Feb 7, 2014, at 12:18 PM, 神明達哉 <> wrote:

> At Thu, 6 Feb 2014 14:13:05 -0500,
> Warren Kumari <> 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:
>> 300  IN DS 31589 8 1 123456......
>> 300  IN DS 31589 8 1 789ABC......
>> Child:
>> 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:
>> 300  IN DS 31589 8 1 789ABC......
>> Child:
>> 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. 

> 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

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.