RFC Errata
Found 6 records.
Status: Verified (4)
RFC 4641, "DNSSEC Operational Practices", September 2006
Note: This RFC has been obsoleted by RFC 6781
Source of RFC: dnsop (ops)
Errata ID: 35
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01
Section 4.2.1.1 says:
Pre-publish key rollover involves four stages as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
It should say:
Pre-publish key rollover involves four stages as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
| DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover
Notes:
The mis-alignment of the indicated line breaks the intended
presentation of the procedure; cf. subsequent RFC text.
from pending
Errata ID: 790
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Verifier Name: Olaf Kolkman
Date Verified: 2006-12-01
Section 4.2.1.2 says:
Double signature ZSK rollover involves three stages as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
It should say:
Double signature ZSK rollover involves three stages as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
| RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
| DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
| RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
Notes:
The mis-alignment of the indicated 3 lines breaks the
intended presentation of the procedure; cf. subsequent RFC text.
The initial report was corrected by Yue Luo 2007-11-16 so that "RRSIG11" in the last row is in "New DNSKEY" stage instead of "initial" stage.
Errata ID: 791
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Section 3.5 says:
As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger then the others.
It should say:
As the chain of trust really is "a chain", there is not much sense in making one of the keys in the chain several times larger than the others.
Notes:
then -> than
from pending
Errata ID: 792
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Section 4.2.1.2 says:
Making sure that the "new DNSKEY" phase lasts until the signature expiration time of the data in initial version of the zone is recommended.
It should say:
Making sure that the "new DNSKEY" phase lasts until the signature | expiration time of the data in the initial version of the zone is recommended.
Notes:
missing article
from pending
Status: Held for Document Update (2)
RFC 4641, "DNSSEC Operational Practices", September 2006
Note: This RFC has been obsoleted by RFC 6781
Source of RFC: dnsop (ops)
Errata ID: 814
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-13
Held for Document Update by: Ron Bonica
Section 7.1 says:
[3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
Flag", RFC 3757, May 2004.
It should say:
[should be omitted.]
Notes:
RFC 3757 has been formally obsoleted by (and incorporated into)
the new DNSSEC RFCs, RFC 4033..4035.
Therefore, RFC 3757 should not appear as a Normative Reference
in new RFCs any more.
The two instances where [3] is cited in the text,
- page 6, Section 3.1, first paragraph, and
- page 24, Section 4.1.1, second paragraph
should have been changed to refer to [5], RFC 4034, instead.
from pending
Errata ID: 2391
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Finch
Date Reported: 2010-07-23
Held for Document Update by: Ron Bonica
Section Appendix C says:
Notes:
There are some NSEC-related errors in the example zone. The NSEC record is missing from the zone apex (though its RRSIG is present). The TTL on the NSEC and RRSIG NSEC records for a.example.net should be the same as the zone's SOA minimum TTL, i.e. 28800 not 86400.