RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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".

Report New Errata



Advanced Search