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

神明達哉 <jinmei@wide.ad.jp> Thu, 06 February 2014 18:29 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 61BCB1A020F for <dnsop@ietfa.amsl.com>; Thu, 6 Feb 2014 10:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 uWl-eTo6Etx2 for <dnsop@ietfa.amsl.com>; Thu, 6 Feb 2014 10:29:52 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B1C721A01B6 for <dnsop@ietf.org>; Thu, 6 Feb 2014 10:29:51 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id t61so1570446wes.22 for <dnsop@ietf.org>; Thu, 06 Feb 2014 10:29:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ywLsx+yI6mAi0xEo7iyv+6tMxPylpe3M3PAIIIkFF4w=; b=aUPZWf82A6qVbBTArZ1RHem0MOqnCHEvHntC0skjOqvIwlp1Ff3cMJ9+1eperZgKvC Qhl20O2rNZOE2AAe2VlwNq9tYj6bRLcOBeE6+d3E14SfuV1cYziGsmDa7adUuN40nKIH 2hKDhaRyVSf0gMsS2DEX3EEcyCOSKcxYYZeYe9nVf8LrbJUyT7oCVXAP2KT5md70+8gU AOGQsoG4X5/vM9h3krG+73AEAWmKExHoZihNfIE/4dPJA4g6UO3oB3+F8oD5JWWF90XN 4EHZcX3iXyUo33ESpFogsMUzinU36etmJLZmn9pchFAgzTZ2Z5MOw3eOpCsPSPDWLZ6a ZJcA==
MIME-Version: 1.0
X-Received: by 10.194.58.180 with SMTP id s20mr2783789wjq.54.1391711390203; Thu, 06 Feb 2014 10:29:50 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Thu, 6 Feb 2014 10:29:50 -0800 (PST)
Date: Thu, 6 Feb 2014 10:29:50 -0800
X-Google-Sender-Auth: tYnBLzehiC3vzNDHIso4eGkKXnk
Message-ID: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
To: dnsop@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [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 18:29:53 -0000

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?)

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.

Am I missing some part of the draft that answers my question, or is
this actually out of scope of CDS/CDNSKEY?

p.s. apologize in advance this was already discussed; I don't remember
all previous discussions of the proposal.

--
JINMEI, Tatuya