RFC Errata
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: Reported (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: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Elias Heftrig
Date Reported: 2024-07-18
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.
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/