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

Tony Finch <dot@dotat.at> Thu, 06 February 2014 19:26 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDD1A0454 for <dnsop@ietfa.amsl.com>; Thu, 6 Feb 2014 11:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIKqJsJRrHrV for <dnsop@ietfa.amsl.com>; Thu, 6 Feb 2014 11:26:19 -0800 (PST)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 887061A0415 for <dnsop@ietf.org>; Thu, 6 Feb 2014 11:26:19 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59236) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1WBUaW-0006kJ-iC (Exim 4.82_3-c0e5623) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 06 Feb 2014 19:26:16 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WBUaW-0007AV-L8 (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 06 Feb 2014 19:26:16 +0000
Date: Thu, 6 Feb 2014 19:26:16 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
In-Reply-To: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com>
Message-ID: <alpine.LSU.2.00.1402061913260.15645@hermes-1.csi.cam.ac.uk>
References: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com>
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 <fanf2@hermes.cam.ac.uk>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2014 19:26:22 -0000

神明達哉 <jinmei@wide.ad.jp>; 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.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
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.