[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, 06 Feb 2014 10:29:50 -0800
X-Google-Sender-Auth: tYnBLzehiC3vzNDHIso4eGkKXnk
Message-ID: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com>
From: 神明達哉 <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
- [DNSOP] how to delete obsolete DS for obsolete DN… 神明達哉
- Re: [DNSOP] how to delete obsolete DS for obsolet… Warren Kumari
- Re: [DNSOP] how to delete obsolete DS for obsolet… Tony Finch
- Re: [DNSOP] how to delete obsolete DS for obsolet… 神明達哉
- Re: [DNSOP] how to delete obsolete DS for obsolet… Doug Barton
- Re: [DNSOP] how to delete obsolete DS for obsolet… Warren Kumari
- Re: [DNSOP] how to delete obsolete DS for obsolet… Doug Barton
- Re: [DNSOP] how to delete obsolete DS for obsolet… Olafur Gudmundsson
- [DNSOP] DNSKEY Flags vs. CDS/CDNSKEY Mukund Sivaraman
- Re: [DNSOP] how to delete obsolete DS for obsolet… Warren Kumari
- Re: [DNSOP] DNSKEY Flags vs. CDS/CDNSKEY Joe Abley
- Re: [DNSOP] how to delete obsolete DS for obsolet… Joe Abley
- Re: [DNSOP] how to delete obsolete DS for obsolet… Warren Kumari
- Re: [DNSOP] how to delete obsolete DS for obsolet… Joe Abley
- Re: [DNSOP] DNSKEY Flags vs. CDS/CDNSKEY Paul Wouters
- Re: [DNSOP] DNSKEY Flags vs. CDS/CDNSKEY Olafur Gudmundsson
- Re: [DNSOP] how to delete obsolete DS for obsolet… JINMEI Tatuya / 神明達哉
- Re: [DNSOP] how to delete obsolete DS for obsolet… JINMEI Tatuya / 神明達哉