RFC Errata
Found 4 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
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.
Errata ID: 5174
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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: 6692
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jarle Fredrik Greipsland
Date Reported: 2021-09-22
Section Appendix D says:
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY)
RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
It should say:
------------------------------------------------------------
new DS | pre-publish |
------------------------------------------------------------
Parent:
NS_A NS_A
DS_A DS_B DS_A DS_B
------------------------------------------------------------
Child at A: Child at A: Child at B:
SOA_A0 SOA_A1 SOA_B0
RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA)
NS_A NS_A NS_B
RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS)
RRSIG_Z_A(NS)
DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A
DNSKEY_Z_B DNSKEY_Z_B
DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B
RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY)
------------------------------------------------------------
Notes:
Figure 15 in Appendix D is depicting the phases of a double DS KSK rollover operator change. One rationale for applying this approach is to avoid the exchange of signatures (RRSIGs) between operators, and limit exchanges to the public parts of the ZSKs in use. In the pre-publish phase in the figure, it is shown that Child A publishes a signature over the DNSKEY RRset generated by Child B's KSK, and that Child B publishes a signature over the DNSKEY RRset generated by Child A's KSK. This is contrary to the rationale given for this method, and also not required, since the pre-published double DS RRs at the parent zone should enable a validator to validate the signature generated by any of the two KSKs in use, thus one RRSIG RR for the DNSKEY RRset is sufficient at each child. Therefore, the RRSIG_K_B(DNSKEY) RR should be removed from Child A, and the RRSIG_K_A(DNSKEY) should be removed from Child B.
Status: Held for Document Update (1)
RFC 6781, "DNSSEC Operational Practices, Version 2", December 2012
Source of RFC: dnsop (ops)
Errata ID: 5276
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthijs Mekking
Date Reported: 2018-03-06
Held for Document Update by: Warren Kumari (Ops AD)
Date Held: 2018-10-02
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.