IETF Logo Mail Archive

Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01

Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp> Fri, 07 September 2012 07:52 UTC

Return-Path: <yoshiro.yoneya@jprs.co.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2A21F8554 for <dnsop@ietfa.amsl.com>; Fri, 7 Sep 2012 00:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyo-lYipPy7H for <dnsop@ietfa.amsl.com>; Fri, 7 Sep 2012 00:52:48 -0700 (PDT)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 6206B21F8552 for <dnsop@ietf.org>; Fri, 7 Sep 2012 00:52:48 -0700 (PDT)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q877qlNC009074 for <dnsop@ietf.org>; Fri, 7 Sep 2012 16:52:47 +0900
X-AuditID: ac120820-b7fe56d000000cec-dd-5049a7cf5928
Received: from NOTE550 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 5D.44.03308.FC7A9405; Fri, 7 Sep 2012 16:52:47 +0900 (JST)
Date: Fri, 07 Sep 2012 16:52:43 +0900
From: Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>
To: dnsop@ietf.org
Message-Id: <20120907165243.ec0354552cda46c5ff6b119b@jprs.co.jp>
In-Reply-To: <20120906090839.GF83242@macbook.bluepipe.net>
References: <504789CA.6040703@nthpermutation.com> <20120906173616.f83c7580ca0c4e1439092747@jprs.co.jp> <20120906090839.GF83242@macbook.bluepipe.net>
X-Mailer: Sylpheed 3.2.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsWyRoiFT/f8cs8Ag9vP+SzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBkbLQrecVQ8276KtYGxhb2LkZNDQsBEomPfHGYIW0ziwr31 bCC2kMBxRomfjZwgNouAisTPNXtYQWw2AQOJX8t+M4HYIgJCEl9vHgGLCwtYSfz5+ROsl1fA QWL5q5tg8zmB4l9efAKq5wKaOYNRYs66U2wQyywk/t79DpTgAGoQlPi7QxgkzCygJfHw1y0W CFteYvvbOcwTGPlmIVTNQlI1C0nVAkbmVYwy+WlpusWpeSnFuekGhnollfl6WQVFxXrJIHoT Izi0OBR2MM44ZXCIUYCDUYmHd8ZdjwAh1sSy4srcQ4ySHExKorz/lnoGCPEl5adUZiQWZ8QX leakFh9ilOBgVhLhDZkJlONNSaysSi3Kh0lJc7AoifMeP7vDT0ggPbEkNTs1tSC1CCYrw8Gh JMH7ZhlQo2BRanpqRVpmTglCmomDE2Q4D9DwkyA1vMUFibnFmekQ+VOMklLivE9AEgIgiYzS PLjeV4ziQC8I854AyfIA0wRc1yuggUxAA0WeeYAMLElESEk1MLYHzN6m3Pzu1zruujX1bk9a n1rMXJ7UfWeHawhzskjnj7S14uZT/j24NUuvOlc1pftmRtpEPssYnpgLc+T55WL7Nhsox+Sd KEpKdNu2sN3tSLJwpX1owJrKnBNie//PkDVaeHza4fx7jya/9IzOL2cvunEq+jlD6oT6hwaO GS2f7Pfe+bTKUomlOCPRUIu5qDgRACMvJejQAgAA
Subject: Re: [DNSOP] draft-yoneya-dnssec-kskro-failure-recovery-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
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 Sep 2012 07:52:49 -0000

Hi,

On Thu, 6 Sep 2012 11:08:39 +0200 Phil Regnauld <regnauld@nsrc.org> wrote:

> 	There are indeed many ways to facilitate recovery, not all of them
> 	practical or realistic.

Yes, currently there are some cases listed in the document, but I'd 
like to narrow down the list and remain 1 or 2 as a best practice in 
the succeeding document.

> 	Case 6: always have a backup (fallback) DS, published alongside the
> 	existing (production) DS record or records (during rollover) currently
> 	associated with the currently active (production) KSK.

This is yet another preventive countermeasure.  Child zone administrator 
who take this practice should use short TTL for DNSKEY.  I'll take into 
consideration your suggestion.

> 	The problem with the ID may be that there are so many different ways
> 	of doing this (hinted at by the phrase "Registration system (or zone
> 	generation system) of parent zone will be complicated.")...

As mentioned above, I'd like to compare each cases based on experiences 
and select 1 or 2 as best practice.

Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>

v2.23.0 | Report a Bug | By Email