errata logo graphic

Found 3 records.

Status: Verified (2)

RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008

Source of RFC: dnsext (int)

Errata ID: 3544

Status: Verified
Type: Technical

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

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


Status: Rejected (1)

RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", March 2008

Source of RFC: dnsext (int)

Errata ID: 3479

Status: Rejected
Type: Technical

Reported By: Andy Newton
Date Reported: 2013-02-07
Rejected by: Ralph Droms
Date Rejected: 2013-03-10

Section Apendix A says:

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:

The example actually uses base32hex (see RFC 4648) and is, therefore, valid.
--VERIFIER NOTES--
The example actually uses base32hex (see RFC 4648) and is, therefore, valid.


Report New Errata