RFC Errata
Found 6 records.
Status: Verified (2)
RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998
Note: This RFC has been updated by RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020, RFC 8499, RFC 9499, RFC 9520
Source of RFC: dnsind (int)
Errata ID: 461
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Hideshi Enokihara
Date Reported: 2006-02-01
Verifier Name: Brian Haberman
Date Verified: 2012-05-01
Section 7.2 says:
7.2 Dead / Unreachable Server (OPTIONAL)
Dead / Unreachable servers are servers that fail to respond in any
way to a query or where the transport layer has provided an
indication that the server does not exist or is unreachable. A
server may be deemed to be dead or unreachable if it has not
responded to an outstanding query within 120 seconds.
Examples of transport layer indications are:
ICMP error messages indicating host, net or port unreachable.
TCP resets
IP stack error messages providing similar indications to those above.
A server MAY cache a dead server indication. If it does so it MUST
NOT be deemed dead for longer than five (5) minutes. The indication
MUST be stored against query tuple <query name, type, class, server
IP address> unless there was a transport layer indication that the
server does not exist, in which case it applies to all queries to
that specific IP address.
It should say:
7.2 Dead / Unreachable Server (OPTIONAL)
Dead / Unreachable servers are servers that fail to respond in any
way to a query or where the transport layer has provided an
indication that the server does not exist or is unreachable. A
server may be deemed to be dead or unreachable if it has not
responded to an outstanding query within 120 seconds.
Examples of transport layer indications are:
ICMP error messages indicating host, net or port unreachable.
TCP resets
IP stack error messages providing similar indications to those above.
A resolver MAY cache a dead server indication. If it does so it MUST
NOT be deemed dead for longer than five (5) minutes. The indication
MUST be stored against query tuple <query name, type, class, server
IP address> unless there was a transport layer indication that the
server does not exist, in which case it applies to all queries to
that specific IP address.
Notes:
Last sentence says, "A server MAY cache a dead server indication.".
But, this "server" is typo, I think.
This "server" should be "resolver" because section 7.1's last sentence uses "resolver".
Errata ID: 4489
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wes Hardaker
Date Reported: 2015-09-29
Verifier Name: Brian Haberman
Date Verified: 2015-10-14
In the References
It should say:
ADD:
[RFC2136] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
-------
OR: define SERVFAIL inside of the terminology section (section 1):
"SERVFAIL" - a name for the "Server failure" (2) RCODE described in
[RFC1035 Section 4.1.1].
Notes:
Section 2.1.1 uses the term SERVFAIL to reference DNS RCODE 2, but this term isn't defined in the document nor in the referenced documents. It's first defined in 2136 and thus the two options available are to either add a reference to 2136 or to add a definition of SERVFAIL to the document in the terminology section.
Status: Held for Document Update (4)
RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998
Note: This RFC has been updated by RFC 4035, RFC 4033, RFC 4034, RFC 6604, RFC 8020, RFC 8499, RFC 9499, RFC 9520
Source of RFC: dnsind (int)
Errata ID: 4627
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-26
Held for Document Update by: Brian Haberman
Date Held: 2016-03-01
Section 9 says:
The history of the early CHIVES work (Section 9.1) was supplied by Rob Austein <sra@epilogue.com> and is reproduced here in the form in which he supplied it [MPA]. Sometime around the spring of 1985, I mentioned to Paul Mockapetris that our experience with his JEEVES DNS resolver had pointed out the need for some kind of negative caching scheme. Paul suggested that we simply cache authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. I'm pretty sure that this conversation took place before RFC-973 was written, but it was never clear to me whether this idea was something that Paul came up with on the spot in response to my question or something he'd already been planning to put into the document that became RFC-973. In any case, neither of us was entirely sure that the SOA MINIMUM value was really the right metric to use, but it was available and was under the control of the administrator of the target zone, both of which seemed to us at the time to be important feature.
It should say:
The history of the early CHIVES work (Section 9.1) was supplied by Rob Austein <sra@epilogue.com> and is reproduced here in the form in which he supplied it [MPA]. 9.1 CHIVES Sometime around the spring of 1985, I mentioned to Paul Mockapetris that our experience with his JEEVES DNS resolver had pointed out the need for some kind of negative caching scheme. Paul suggested that we simply cache authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. I'm pretty sure that this conversation took place before RFC-973 was written, but it was never clear to me whether this idea was something that Paul came up with on the spot in response to my question or something he'd already been planning to put into the document that became RFC-973. In any case, neither of us was entirely sure that the SOA MINIMUM value was really the right metric to use, but it was available and was under the control of the administrator of the target zone, both of which seemed to us at the time to be important feature.
Notes:
Section name are referenced but absent.
Errata ID: 4628
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-02-26
Held for Document Update by: Brian Haberman
Date Held: 2016-03-01
Section References says:
It should say:
[MPA] ???
Notes:
Section 9 says
The history of the early CHIVES work (Section 9.1) was supplied by
Rob Austein <sra@epilogue.com> and is reproduced here in the form in
which he supplied it [MPA].
But [MPA] reference not included into Reference section.
I can't find original publication (Rob Austein) referenced by [MPA]
Errata ID: 4632
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2016-03-02
Held for Document Update by: Brian Haberman
Date Held: 2016-03-02
Section 11 says:
For such an attack to be successful, the NXDOMAIN indiction must be injected into a parent server (or a busy caching resolver). One way this might be done by the use of a CNAME which results in the parent server querying an attackers server. Resolvers that wish to prevent such attacks can query again the final QNAME ignoring any NS data in the query responses it has received for this query.
It should say:
For such an attack to be successful, the NXDOMAIN indication must be injected into a parent server (or a busy caching resolver). One way this might be done by the use of a CNAME which results in the parent server querying an attackers server. Resolvers that wish to prevent such attacks can query again the final QNAME ignoring any NS data in the query responses it has received for this query.
Notes:
A typo in the word "indication".
Errata ID: 4983
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Stéphane Bortzmeyer
Date Reported: 2017-03-28
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12
Section 1 says:
"QNAME" - the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME.
It should say:
"QNAME" - the name in the query section (RFC 1034, section 3.7.1).
Notes:
RFC 2308 is the only RFC that defines QNAME this way. Original definition in RFC 1034 is clear, and is used by all other RFC since. (This point was raised during the development of RFC 8020, and is now discussed in the context of draft-ietf-dnsop-terminology-bis)
-- verifier note --
RFC 8499 (replacing draft-ietf-dnsop-terminology-bis) notes that there are indeed several definitions of "QNAME".