Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY
神明達哉 <jinmei@wide.ad.jp> Fri, 07 February 2014 17:18 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 0510A1ACCE3 for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 09:18:23 -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 YP7vo2lFFaaM for <dnsop@ietfa.amsl.com>; Fri, 7 Feb 2014 09:18:21 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11A1ACC87 for <dnsop@ietf.org>; Fri, 7 Feb 2014 09:18:21 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id e4so1055005wiv.17 for <dnsop@ietf.org>; Fri, 07 Feb 2014 09:18:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yuXj4KFnibguE6fjytCg4wlUgkqG+eoo4nlICOlQ86g=; b=pST9LKLI6tdrei5We1U5eDSzlqQ6iGO/A0BE1H218FPto0AYAA6PZtrQGMKbf8JncT DLc4msP1QjThPT2bVftGbJG8WInBFYX/lMba4TOZPL00qtObKio+1PHna4V2txhHsRSr gMRSOqFJkdXqFzlzVeMafqPnyE1EHfA6U2pmwcj/8N3cYJYqv4zKd59Iq/3wOR4N/K73 BUtP/Tqac3UpsUphl3PXmhhVeBGEaNz0pTpqH6VjuecmS4Yj9/GDk51uGXUyfyvP3Lll KfazbLnLq1SX+Lbk4f11CzM6B33nd2FSEDKZuFM3wqXyRDAMZ4Jjj9zeel5Y04o7uSwo q7lg==
MIME-Version: 1.0
X-Received: by 10.180.72.239 with SMTP id g15mr637511wiv.45.1391793500595; Fri, 07 Feb 2014 09:18:20 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Fri, 7 Feb 2014 09:18:20 -0800 (PST)
In-Reply-To: <CAHw9_i+Jt4Ok+CddheGT_nA=e4srgbUSQy98GeQ9qGn_Cncjag@mail.gmail.com>
References: <CAJE_bqe95pn8rHvK3UffPDn+_rGYiq2G5sfdgqisH4JG7gFjBA@mail.gmail.com> <CAHw9_i+Jt4Ok+CddheGT_nA=e4srgbUSQy98GeQ9qGn_Cncjag@mail.gmail.com>
Date: Fri, 07 Feb 2014 09:18:20 -0800
X-Google-Sender-Auth: GjGUBxeXAnnwdOEUmK7HmlE7dRY
Message-ID: <CAJE_bqc5gpEEx-OkkXv0dtsTQ6pwYb9kkEzELfvszz30+tvCPg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: dnsop <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: Fri, 07 Feb 2014 17:18:23 -0000
At Thu, 6 Feb 2014 14:13:05 -0500, Warren Kumari <warren@kumari.net> 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: > example.com. 300 IN DS 31589 8 1 123456...... > example.com. 300 IN DS 31589 8 1 789ABC...... > Child: > example.com. 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: > example.com. 300 IN DS 31589 8 1 789ABC...... > Child: > example.com. 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 example.com. 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. 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. 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. -- 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 / 神明達哉