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

From: RFC Errata System <[email-masked]>
Date: Wed, 26 Oct 2016 01:59:39 -0700 (PDT)

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 <[email-masked]>

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

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 26 Oct 2016 12:40:30 +0200

All,

The new text looks good to me.

Best regards,
   Matthijs

On 26-10-16 10:59, RFC Errata System wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>