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, RFC 9824
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, RFC 9824
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,