RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998

Source of RFC: dnsind (int)

Errata ID: 461

Status: Verified
Type: Editorial

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

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 (3)

RFC 2308, "Negative Caching of DNS Queries (DNS NCACHE)", March 1998

Source of RFC: dnsind (int)

Errata ID: 4627

Status: Held for Document Update
Type: Editorial

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

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

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

Report New Errata



Search RFCs
Advanced Search
×