RFC 6781, "DNSSEC Operational Practices, Version 2", December 2012

Errata ID: 4844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Marcos Sanz
Date Reported: 2016-10-26
Verifier Name: Joel Jaeggli
Date Verified: 2017-03-29

Section 4.1.2 says:

   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.

It should say:

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.

Report New Errata