[DNSOP] [Errata Verified] RFC6781 (4844)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 29 March 2017 17:19 UTC

To: sanz@denic.de, olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl, miek.gieben@sidn.nl
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: joelja@bogus.com, iesg@ietf.org, dnsop@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20170329171853.3C7D2B8011A@rfc-editor.org>
Date: Wed, 29 Mar 2017 10:18:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z25ZjjUZ_ZfvasBsLa0n85P7c9A>
Subject: [DNSOP] [Errata Verified] RFC6781 (4844)
Precedence: list

The following errata report has been verified for RFC6781,
"DNSSEC Operational Practices, Version 2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6781&eid=4844

--------------------------------------
Status: Verified
Type: Technical

Reported by: Marcos Sanz <sanz@denic.de>
Date Reported: 2016-10-26
Verified by: Joel Jaeggli (IESG)

Section: 4.1.2

Original Text
-------------
initial: Initial version of the zone. The parental DS points to
DNSKEY_K_1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
it is needed during the rollover, and we refer to the value as
TTL_DS.

new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY_K_2. The key is provided to the
parent, and the child will have to wait until a new DS RR has been
generated that points to DNSKEY_K_2. After that DS RR has been
published on all servers authoritative for the parent's zone, the
zone administrator has to wait at least TTL_DS to make sure that
the old DS RR has expired from caches.

DS change: The parent replaces DS_K_1 with DS_K_2.

Corrected Text
--------------
initial: Initial version of the zone. The parental DS points to
DNSKEY_K_1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
it is needed during the rollover, and we refer to the value as
TTL_DS. Also, we refer to the TTL value of the DNSKEY_K_1 RR as
TTL_DNSKEY.

new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY_K_2. The new DNSKEY RRSet that
includes DNSKEY_K_2 is published at the child. After waiting at
least TTL_DNSKEY, DNSKEY_K_2 (or the DS RR generated from it, that
is DS_K_2) is provided to the parent.

DS change: The parent replaces DS_K_1 with DS_K_2. After that DS RR
has been published on all servers authoritative for the parent's
zone, the zone administrator has to wait at least TTL_DS to make
sure that the old DS RR has expired from caches.

Notes
-----
I just corrected what is fundamentally flawed. RFC 7583 section 3.3.1 provides a much detailed explanation of the process.

--------------------------------------
RFC6781 (draft-ietf-dnsop-rfc4641bis-13)
--------------------------------------
Title : DNSSEC Operational Practices, Version 2
Publication Date : December 2012
Author(s) : O. Kolkman, W. Mekking, R. Gieben
Category : INFORMATIONAL
Source : Domain Name System Operations
Area : Operations and Management
Stream : IETF
Verifying Party : IESG

[DNSOP] [Errata Verified] RFC6781 (4844) RFC Errata System