errata logo graphic

Found 5 records.

Status: Verified (3)

RFC4034, "Resource Records for the DNS Security Extensions", March 2005

Source of RFC: dnsext (int)

Errata ID: 1062

Status: Verified
Type: Technical

Reported By: Peter Koch
Date Reported: 2005-09-13
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 6.2 says:

   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;

It should say:

[not supplied]

Notes:

Compare with RFC 3597 (section 7):

"As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6."

Almost exactly the same list. One HINFO too much is no issue,
but if this actually should be TXT it's a real typo.

neither TXT nor HINFO contain domain names in RDATA, so it's a bug in both
RFC 3597 and 4034, although one that doesn't hurt. One could also argue that the list lacks NSAP-PTR, but then that's as obsolete as MD ans MF.


Errata ID: 3045

Status: Verified
Type: Technical

Reported By: Mark Andrews
Date Reported: 2011-12-07
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section Updates says:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign

It should say:

Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign

Notes:

4033, 4034 and 4035 all list 3007 as being updated but none do so.


Errata ID: 193

Status: Verified
Type: Editorial

Reported By: Donald E. Eastlake III
Date Reported: 2005-06-21

In Appendix B.1, it says:

                                                              For a
   DNSKEY RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 4th to last and 3rd to last octets
   of the public key modulus).

It should say:

                                                              For a
   DNSKEY RR with algorithm 1, the key tag is defined to be the most
   significant 16 bits of the least significant 24 bits in the public
   key modulus (in other words, the 3rd to last and 2nd to last octets
   of the public key modulus).


Status: Held for Document Update (1)

RFC4034, "Resource Records for the DNS Security Extensions", March 2005

Source of RFC: dnsext (int)

Errata ID: 2681

Status: Held for Document Update
Type: Technical

Reported By: Guillaume Bailey
Date Reported: 2011-01-05
Held for Document Update by: Brian Haberman

Section B says:

   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).  The key tag algorithm is the sum of the wire
   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
   RDATA (in wire format) is treated as a series of 2 octet groups.
   These groups are then added together, ignoring any carry bits.

It should say:

   The key tag is the same for all DNSKEY algorithm types except
   algorithm 1 (please see Appendix B.1 for the definition of the key
   tag for algorithm 1).  The key tag algorithm is the sum of the wire
   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
   RDATA (in wire format) is treated as a series of 2 octet groups.
   These groups are then added together with at least 32-bit precision,
   retaining any carry bits. The carry bits are then added to the result,
   and finally, only the lower 16 bits of the result are used as the key 
   tag.


Notes:

This change comes from the example implementation. The accumulator, ac, is required ("assumed") to be 32-bits or larger, and the carry bits are added to the accumulator before returning:

ac += (ac >> 16) & 0xFFFF;


Status: Rejected (1)

RFC4034, "Resource Records for the DNS Security Extensions", March 2005

Source of RFC: dnsext (int)

Errata ID: 2824

Status: Rejected
Type: Editorial

Reported By: Edward Lewis
Date Reported: 2011-06-06
Rejected by: Brian Haberman
Date Rejected: 2012-04-30

Section 3.1.3 says:

   The value of the Labels field MUST NOT count either the null (root)
   label that terminates the owner name or the wildcard label (if
   present).

It should say:

   The value of the Labels field MUST NOT count either the null (root)
   label that terminates the owner name or the leftmost label if
   it is a wildcard.

Notes:

In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.)

The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations.
--VERIFIER NOTES--
All wildcard labels start with * in the leftmost label. No other kind of wildcard label exists.

From RFC 1034:

4.3.3. Wildcards

In the previous algorithm, special treatment was given to RRs with owner
names starting with the label "*".


Report New Errata