RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (4)

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 1062
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: 4552
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ben Laurie
Date Reported: 2015-12-04
Verifier Name: Brian Haberman
Date Verified: 2015-12-14

Section Appendix B says:

These groups are then added together, ignoring any carry bits.

It should say:

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. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes:

Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part of the corrected text is from 2681.

Its worth pointing this out because a naive analysis says in fact the keytag is exactly the same as reduction modulo 65535, and this has already wasted a fair amount of time.

It is also worth pointing out, perhaps, that this is a poor choice of algorithm for this particular application as it interacts badly with the properties of keys.

Errata ID: 193
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

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)

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 2681
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

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)

RFC 4034, "Resource Records for the DNS Security Extensions", March 2005

Note: This RFC has been updated by RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077

Source of RFC: dnsext (int)

Errata ID: 2824
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

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



Advanced Search