RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 4035, "Protocol Modifications for the DNS Security Extensions", March 2005

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

Source of RFC: dnsext (int)

Errata ID: 3044
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 update 3007

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

Reported By: Peter van Dijk
Date Reported: 2018-01-04
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03

Section 3.1.4.1 says:

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.

It should say:

   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for any zone above the
      child's apex.

   o  The name server does not offer recursion.

Notes:

The original text is ambiguous in the face of an authoritative server having zones C.B.A. and A. but not B.A., and could cause DS queries for C to return a NODATA at C's apex, instead of the desired referral to B. which would allow resolution to continue correctly.

Status: Held for Document Update (1)

RFC 4035, "Protocol Modifications for the DNS Security Extensions", March 2005

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

Source of RFC: dnsext (int)

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

Reported By: Elias Heftrig
Date Reported: 2024-07-18
Held for Document Update by: Eric Vyncke
Date Held: 2024-08-07

Section 5.3.1. says:

   [...] the validator cannot predetermine which DNSKEY
   RR to use to authenticate the signature, and it MUST try each
   matching DNSKEY RR until either the signature is validated or the
   validator has run out of matching public keys to try.

It should say:

   [...] the validator cannot predetermine which DNSKEY
   RR to use to authenticate the signature, and it SHOULD try each
   matching DNSKEY RR until either the signature is validated or the
   validator has run out of matching public keys to try.

Notes:

The original text requires validators to invest an unreasonable amount of work to validate a given signature in case there are many such DNSKEY RRs. The issue was exploited in the construction of CPU resource exhaustion attacks (CVE-2023-50387). For more details see our publication with ACM CCS'24 on the KeyTrap denial of service vulnerabilities.

-- verifier note --
While the concern is valid, this erratum does not represent the DNSEXT WG consensus at the time of writing, i.e., it cannot be "verified"

Status: Rejected (1)

RFC 4035, "Protocol Modifications for the DNS Security Extensions", March 2005

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

Source of RFC: dnsext (int)

Errata ID: 7972
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nate Choe
Date Reported: 2024-06-06
Rejected by: Eric Vyncke
Date Rejected: 2024-06-07

Section 4.2 says:

   Security-aware resolvers MAY query for missing security RRs in an
   attempt to perform validation; implementations that choose to do so
   must be aware that the answers received may not be sufficient to
   validate the original response.  For example, a zone update may have
   changed (or deleted) the desired information between the original and
   follow-up queries.

It should say:

   Security-aware resolvers MAY query for missing security RRs in an
   attempt to perform validation; implementations that choose to do so
   MUST be aware that the answers received may not be sufficient to
   validate the original response.  For example, a zone update may have
   changed (or deleted) the desired information between the original and
   follow-up queries.

Notes:

"MUST" is a key word according to RFC 2119/BCP 14 and should be capitalized.
--VERIFIER NOTES--
As it appears to the original authors, remaining members of dnsext mailing list, and myself as INT AD, the "must" here is not normative and should be kept in lowercase.

See also:
https://mailarchive.ietf.org/arch/msg/dnsext/1PZ58ajXFj_RodKgHzus6d6UB-U/

Report New Errata



Advanced Search