[DNSOP] [Technical Errata Reported] RFC6781 (4844)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 26 October 2016 08:59 UTC

To: olaf@nlnetlabs.nl, matthijs@nlnetlabs.nl, miek.gieben@sidn.nl, bclaise@cisco.com, joelja@bogus.com, suzworldwide@gmail.com, tjw.ietf@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20161026085939.97B28B80166@rfc-editor.org>
Date: Wed, 26 Oct 2016 01:59:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1NZ7XzFvHXlVCZ6DyZ4qUWwLMuc>
Cc: dnsop@ietf.org, rfc-editor@rfc-editor.org
Subject: [DNSOP] [Technical Errata Reported] RFC6781 (4844)
Precedence: list

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Marcos Sanz <sanz@denic.de>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
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] [Technical Errata Reported] RFC6781 (4844) RFC Errata System
Re: [DNSOP] [Technical Errata Reported] RFC6781 (… Matthijs Mekking