RFC Errata
Found 5 records.
Status: Verified (3)
RFC 6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)", February 2013
Note: This RFC has been updated by RFC 8749
Source of RFC: dnsext (int)
Errata ID: 4924
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Andrews
Date Reported: 2017-02-07
Verifier Name: Terry Manderson
Date Verified: 2017-03-01
Section IANA Conside says:
This document specifies no IANA Actions.
It should say:
Add this document as an additional reference for AD in the DNS Parameters - DNS Header Flags registry.
Notes:
RFC6840 introduces new behaviour for AD in requests. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.
Errata ID: 4927
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2017-02-08
Verifier Name: Terry Manderson
Date Verified: 2017-03-01
Section IANA Conside says:
(This document specifies no IANA Actions.)
It should say:
(Add following text:) This document adds an additional reference for CD bit in the DNS Parameters - DNS Header Flags registry.
Notes:
RFC6840 introduces new requirements for validating resolvers. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.
Errata ID: 4928
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Špaček
Date Reported: 2017-02-08
Verifier Name: Terry Manderson
Date Verified: 2017-03-01
Section IANA Conside says:
(This document specifies no IANA Actions.)
It should say:
(Add following text:) This document adds an additional reference for DO bit in the DNS Parameters - DNS Header Flags registry.
Notes:
RFC6840 introduces new behaviour for DO bit in replies. This should be reflected in the DNS Header Flags registry otherwise it is likely DNS Implementors will overlook the new behaviour.
Status: Held for Document Update (1)
RFC 6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)", February 2013
Note: This RFC has been updated by RFC 8749
Source of RFC: dnsext (int)
Errata ID: 8038
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 4.2. says:
When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS MUST be validated. If any of those RRsets fail validation, the answer is considered Bogus.
It should say:
When validating a response to QTYPE=*, all received RRsets that match QNAME and QCLASS SHOULD be validated. If any of those RRsets fail validation, the answer is considered Bogus.
Notes:
The original text requires validators to invest an unreasonable amount of work to validate the signatures over the RRsets in case there are many such RRsets. 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 (and has been addressed by more recent RFC), this erratum does not represent the DNSEXT WG consensus at the time of writing, i.e., it cannot be "verified".
Note that further elaboration is required to clarify the implications of not following the recommendation. We suggest to also update the second sentence along the lines of:
> If any of those RRsets fail validation or the response contains more such RRsets than the validator is willing to process, the answer is considered Bogus.
Status: Rejected (1)
RFC 6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)", February 2013
Note: This RFC has been updated by RFC 8749
Source of RFC: dnsext (int)
Errata ID: 4191
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Edward Lewis
Date Reported: 2014-12-02
Rejected by: Brian Haberman
Date Rejected: 2015-01-12
Section 5.11 says:
...
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. The
zone MUST also be signed with each algorithm (though not each key)
present in the DNSKEY RRset.
It should say:
A signed zone MUST include a DNSKEY for each algorithm present in
the zone's DS RRset and expected trust anchors for the zone. Each
authoritative RRset in the zone MUST be signed with each
algorithm (though not each key) present in the DNSKEY RRset.
Notes:
Zones aren't signed (per se), the data sets within them are. But not cut point (NS) and glue.
--VERIFIER NOTES--
This erratum is being rejected as the nomenclature being updated is understood within the community and is used in other DNSSEC specifications.