RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search