RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

RFC 4034, "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: 4552
Status: Verified
Type: Technical

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

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).

Report New Errata