RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

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

Source of RFC: dnsop (ops)

Errata ID: 4844
Status: Verified
Type: Technical

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.

Errata ID: 5174
Status: Verified
Type: Technical

Reported By: Andreas Cudok
Date Reported: 2017-10-29
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2017-10-30

Section Appendix B. says:

   is reduced to the following representation:

            SOA_2005092303
            RRSIG_Z_14(SOA_2005092303)
            DNSKEY_K_14
            DNSKEY_Z_15
            RRSIG_K_14(DNSKEY)
            RRSIG_Z_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_14.

It should say:

   is reduced to the following representation:

            SOA_2005092303
            RRSIG_Z_14(SOA_2005092303)
            DNSKEY_Z_14
            DNSKEY_K_15
            RRSIG_Z_14(DNSKEY)
            RRSIG_K_15(DNSKEY)

The rest of the zone data has the same signature as the SOA record,
   i.e., an RRSIG created with DNSKEY_K_15.

Notes:

Note: K and Z were swapped.

Status: Reported (1)

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

Source of RFC: dnsop (ops)

Errata ID: 5276
Status: Reported
Type: Technical

Reported By: Matthijs Mekking
Date Reported: 2018-03-06

Section 4.1.4 says:

   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

   Child:
    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_Z_10(SOA)
    -------------------> RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    ------------------->
    -------------------> DNSKEY_K_2           DNSKEY_K_2
    ------------------->
    -------------------> DNSKEY_Z_11          DNSKEY_Z_11
    ------------------->
    -------------------> RRSIG_K_2(DNSKEY)    RRSIG_K_2(DNSKEY)
   ----------------------------------------------------------------

        Figure 8: Stages of Deployment during an Algorithm Rollover

It should say:

   ----------------------------------------------------------------
    new DS               DNSKEY removal       RRSIGs removal
   ----------------------------------------------------------------
   Parent:
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

   Child:
    -------------------> SOA_3                SOA_4
    -------------------> RRSIG_Z_10(SOA)
    -------------------> RRSIG_Z_11(SOA)      RRSIG_Z_11(SOA)

    ------------------->
    -------------------> DNSKEY_K_2           DNSKEY_K_2
    ------------------->
    -------------------> DNSKEY_Z_11          DNSKEY_Z_11
    -------------------> RRSIG_K_1(DNSKEY)
    -------------------> RRSIG_K_2(DNSKEY)    RRSIG_K_2(DNSKEY)
   ----------------------------------------------------------------

        Figure 8: Stages of Deployment during an Algorithm Rollover

Notes:

This is about Figure 8 on page 30.

The figure should have the signature of the old KSK, called RRSIG_K_1(DNSKEY) in the "DNSKEY removal" step.

Because a conservative validator may have the DNSKEY RRset cached that includes DNSKEY_K_1, DNSKEY_K_2, DNSKEY_Z_1, and DNSKEY_Z_2.

Report New Errata