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

Tony Finch <> Thu, 06 February 2014 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D9EDD1A0454 for <>; Thu, 6 Feb 2014 11:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sIKqJsJRrHrV for <>; Thu, 6 Feb 2014 11:26:19 -0800 (PST)
Received: from ( [IPv6:2001:630:212:8::e:f33]) by (Postfix) with ESMTP id 887061A0415 for <>; Thu, 6 Feb 2014 11:26:19 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:59236) by ( []:25) with esmtpa (EXTERNAL:fanf2) id 1WBUaW-0006kJ-iC (Exim 4.82_3-c0e5623) (return-path <>); Thu, 06 Feb 2014 19:26:16 +0000
Received: from fanf2 by ( with local id 1WBUaW-0007AV-L8 (Exim 4.72) (return-path <>); Thu, 06 Feb 2014 19:26:16 +0000
Date: Thu, 6 Feb 2014 19:26:16 +0000
From: Tony Finch <>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-1962937549-1391714776=:15645"
Sender: Tony Finch <>
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: Thu, 06 Feb 2014 19:26:22 -0000

神明達哉 <> wrote:

> I have one quick question about CDS/CDNSKEY: what's the (or "an")
> expected operation for the parent to remove a DS RR of a child that
> was obsolete and is now removed from the child zone?
> This point is not clear to me on a quick rescan of
> draft-ietf-dnsop-delegation-trust-maintainance-02.
> According to 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; [...]
> it could read the child would remove the CDS or CDSKEY for the
> now-removed DNSKEY, but it may contradict Section 4.1:
>    Absence of CDS / CDNSKEY in child signals "No change" to the current
>    DS set.
> (BTW: this sentence is a bit ambiguous to me.  Does this mean there's
> no CDS/CDNSKEY RR for the apex name, or the absence of CDS/CDNSKEY for
> a specific DNSKEY?)

I think this second quote from the draft is supposed to mean: absence of
any CDS or CDNSKEY RRsets signals no change.

If there is a CDS or CDNSKEY RRset then the DS RRset should be changed to
match (provided the other acceptance rules are satisfied).

I believe the intent of the draft is that this mechanism cannot be used to
go insecure - though I cannot immediately find text which explicitly says
that. So for a CDS or CDNSKEY RRset to have any effect, it must exist,
which implies there must be at least one DS in the parent zone, which
implies you cannot go insecure.

> and also Section 5:
>    When the Parent DS is "in-sync" with the CDS, the Child DNS Operator
>    MAY delete the CDS RRset.
> i.e., if the child may delete a CDS for a new DNSKEY after
> synchronization, clearly it cannot use the removal of CDS as an
> indication of the removal of DNSKEY.

This quote from the draft talks about removing the entire RRset, so it is
consistent with my explanation above.

To indicate the removal of a DNSKEY, the child uses a CDS RRset which
does not include a record matching the removed DNSKEY, but does include
the other DNSKEYs that are still present.

f.anthony.n.finch  <>
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.