RFC Errata
Found 5 records.
Status: Verified (3)
RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008
Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276
Source of RFC: dnsext (int)
Errata ID: 3544
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Newton
Date Reported: 2013-03-10
Verifier Name: Ralph Droms
Date Verified: 2013-03-12
Section 3.3 says:
o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32 digits, without whitespace.
It should say:
o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32hex digits, without whitespace.
Notes:
RFC 4648 Section 7 says: 'This encoding may be referred to as "base32hex". This encoding should not be regarded as the same as the "base32" encoding and should not be referred to as only "base32".'
There are many spots in RFC 5155 that use the term base32 where base32hex is the appropriate term. Section 3.3 above is the most important, but Section 1.1 uses the term as well Section 3 paragraph 4 and Section 3.2 paragraph 8.
Errata ID: 3441
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2012-12-31
Verifier Name: Ralph Droms
Date Verified: 2013-03-10
Section 7.2.3 & 8.5 says:
7.2.3 (contents) 8.5 (contents)
It should say:
7.2.3. No Data Responses, QTYPE is not DS If the No Data Response is a result of an empty non-terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. In all other cases, the server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field. =============================================== 8.5. Validating No Data Responses, QTYPE is not DS If there is an NSEC3 RR that matches QNAME present, the validator must check that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field. If there is no NSEC3 RR present that matches QNAME, then the validator MUST verify a closest provable encloser proof for the QNAME. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. This test covers the case where the response is due to an Empty Non-Terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR.
Notes:
The corrections were derived from a private email from an editor of RFC 5155. Note that the ordering of the paragraphs in the proposed 8.5 fix has been changed. No other change is intentional.
From Roy Arends:
We missed documenting the case of what a server and a validator should do in case of an opted-out, multi-label delegation. We did make it clear in signing (7.1).
This is also not part of the demo zone, included in RFC5155.
As suggested text for an errata, may I offer:
7.2.3. No Data Responses, QTYPE is not DS
If the No Data Response is a result of an empty non-terminal derived
from an insecure delegation covered by an Opt-Out NSEC3 RR, the
closest provable encloser proof MUST be included in the response.
The included NSEC3 RR that covers the "next closer" name for the
delegation MUST have the Opt-Out flag set to one.
In all other cases, the server MUST include the NSEC3 RR that matches
QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either
the QTYPE or CNAME set in its Type Bit Maps field.
8.5. Validating No Data Responses, QTYPE is not DS
If there is no NSEC3 RR present that matches QNAME, then the validator
MUST verify a closest provable encloser proof for the QNAME. The
validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that
covers the "next closer" name to the delegation name. This test covers
the case where the response is due to an Empty Non-Terminal derived
from an insecure delegation covered by an Opt-Out NSEC3 RR.
If there is an NSEC3 RR that matches QNAME present, the validator must
check that both the QTYPE and the CNAME type are not set in its Type
Bit Maps field.
Note that this test also covers the case where the NSEC3 RR exists
because it corresponds to an empty non-terminal, in which case the
NSEC3 RR will have an empty Type Bit Maps field.
The following message is the singularly most important one in the errata submission, from David Blacka, commenting on the order of the paragraphs:
http://www.ietf.org/mail-archive/web/dnsext/current/msg12835.html
The heads of the threads to review:
http://www.ietf.org/mail-archive/web/dnsext/current/msg12819.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12821.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12830.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12832.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12839.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg12854.html
and
http://www.ietf.org/mail-archive/web/dnsext/current/msg12864.html
Errata ID: 4622
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Robert Edmonds
Date Reported: 2016-02-18
Verifier Name: Brian Haberman
Date Verified: 2016-02-19
Section 7.2.8 says:
7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist.
It should say:
7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: o the QNAME equals the owner name of an existing NSEC3 RR, and o no RR types exist at the QNAME besides NSEC3, nor at any descendant of QNAME, then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act as if the owner name of the NSEC3 RR did not exist.
Notes:
If the QNAME is equal to the owner name of an existing NSEC3 RR, then the NSEC3 RR type itself will exist at the QNAME, and the second condition will always be false.
Status: Reported (1)
RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008
Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276
Source of RFC: dnsext (int)
Errata ID: 4993
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Dick Franks
Date Reported: 2017-04-13
Section Appendix A says:
; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv - ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example) - ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) NS ns1.example. NS ns2.example. MX 1 xx.example. DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU ( sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h TY4hHn9npWFRw5BYubE= ) DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ ( j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9 AbsUdblMFin8CVF3n4s= ) NSEC3PARAM 1 0 12 aabbccdd:1 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) ! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 ! NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) a.example. NS ns1.a.example. NS ns2.a.example. DS 58470 5 1 ( 3079F1593EBAD6DC121E202A8B766A6A4837206C ) ns1.a.example. A 192.0.2.5 ns2.a.example. A 192.0.2.6 ai.example. A 192.0.2.9 HINFO "KLH-10" "ITS" AAAA 2001:db8:0:0:0:0:f00:baa9 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) c.example. NS ns1.c.example. NS ns2.c.example. ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( ! kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) ! kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( ! q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) ns1.example. A 192.0.2.1 ns2.example. A 192.0.2.2 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG ) *.w.example. MX 1 ai.example. x.w.example. MX 1 xx.example. x.y.w.example. MX 1 xx.example. xx.example. A 192.0.2.10 HINFO "KLH-10" "TOPS-20" AAAA 2001:db8:0:0:0:0:f00:baaa
It should say:
; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) NS ns1.example. NS ns2.example. MX 1 xx.example. DNSKEY 256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU ( sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h TY4hHn9npWFRw5BYubE= ) DNSKEY 257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ ( j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9 AbsUdblMFin8CVF3n4s= ) NSEC3PARAM 1 0 12 aabbccdd:1 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) ! 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) a.example. NS ns1.a.example. NS ns2.a.example. DS 58470 5 1 ( 3079F1593EBAD6DC121E202A8B766A6A4837206C ) ns1.a.example. A 192.0.2.5 ns2.a.example. A 192.0.2.6 ai.example. A 192.0.2.9 HINFO "KLH-10" "ITS" AAAA 2001:db8:0:0:0:0:f00:baa9 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) c.example. NS ns1.c.example. NS ns2.c.example. ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( ! q04jkcevqvmu85r014c7dkba38o0ji5r ) ns1.example. A 192.0.2.1 ns2.example. A 192.0.2.2 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG ) *.w.example. MX 1 ai.example. x.w.example. MX 1 xx.example. x.y.w.example. MX 1 xx.example. xx.example. A 192.0.2.10 HINFO "KLH-10" "TOPS-20" AAAA 2001:db8:0:0:0:0:f00:baaa
Notes:
The obligatory RRSIG records have been omitted for clarity.
The zone prior to NSEC3 signing seems to have contained an unexpected
2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
which was then lovingly included in the NSEC3 chain.
The error is readily detectable from the list of hashes of the original owner names. The source zone prior to signing can never contain a hashed name.
For completeness, B5 also needs a corresponding amendment, although this does not invalidate the proof presented therein.
Status: Rejected (1)
RFC 5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008
Note: This RFC has been updated by RFC 6840, RFC 6944, RFC 9077, RFC 9157, RFC 9276
Source of RFC: dnsext (int)
Errata ID: 3479
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Newton
Date Reported: 2013-02-07
Rejected by: Ralph Droms
Date Rejected: 2013-03-10
Appendix A
The example in Appendix A has an NSEC3 next hashed owner name field with the non-base 32 characters 9, 0, and 1.
It should say:
The example should be changed so that the field in question is valid base 32.
Notes:
--VERIFIER NOTES--
The example actually uses base32hex (see RFC 4648) and is, therefore, valid.