RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 1995, "Incremental Zone Transfer in DNS", August 1996

Source of RFC: dnsind (int)

Errata ID: 3197

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2012-04-18
Verifier Name: Brian Haberman
Date Verified: 2012-05-01

Section 4, pg.3 says:

|  RRs in the incremental transfer messages may be partial.  That is, if
   a single RR of multiple RRs of the same RR type changes, only the
   changed RR is transferred.

It should say:

|  RRsets in the incremental transfer messages may be partial.  That is,
|  if a single RR out of multiple RRs of the same RR type at the same
|  owner name and CLASS changes, only the changed RR is transferred.

Notes:

Rationale:
DNS resource records (RRs) are always transferred as integral
entities in the DNS protocol, and IXFR is no exception for this
rule. So there never are partial RRs in any IXFR response packets.
However, as indicated more precisely in the adjusted text above,
it is intended that partial _RRsets_ are carried in IXFR responses;
unchanged RRs are not sent inside incremental response messages.
Historical Note:
The above issue has been identified by the submitter in 2008,
but no Errata have been filed so far. However, it already had
been observed in 1999 by Andreas Gustafsson, who, in the context of
the work on RFC 1995bis, recently has provided the DNSEXT WG access
to a privately archived DNSIND mailing list thread on RFC 1995,
in which such issues have been discussed in November 1999.
For the record, the technical issues in RFC 1995 that can be
addressed by Errata Notes are now being submitted this way.

Status: Held for Document Update (1)

RFC 1995, "Incremental Zone Transfer in DNS", August 1996

Source of RFC: dnsind (int)

Errata ID: 3196

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2012-04-18
Held for Document Update by: Brian Haberman

Section 2, pg.2 says:

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
|  the server's current version, just as in AXFR.
                               ^^^^^^^^^^^^^^^^^^
   [...]

   Thus, a client should first make an IXFR query using UDP.  If the
   query type is not recognized by the server, an AXFR (preceded by a
|  UDP SOA query) should be tried, ensuring backward compatibility.  [...]
   ^^^^

It should say:

   If an IXFR query with the same or newer version number than that of
   the server is received, it is replied to with a single SOA record of
|  the server's current version.

   [...]

   Thus, a client should first make an IXFR query using UDP.  If the
|  query type is not recognized by the server, an AXFR (preceded by an
|  SOA query) should be tried, ensuring backward compatibility.  [...]

Notes:

Rationale:
a) The behavior of the IXFR protocol described in the first paragraph
quoted above has been attributed falsely to AXFR; AXFR doesn't
behave like that (cf. the clarified AXFR specification in RFC 5936).
b) The SOA query may be performed over TCP as well, e.g., if there
already is an open TCP connection from the client to the server.

Historical Note:
The above issues have been identified by the submitter in 2008,
but no Errata have been filed so far. However, these already had
been observed in 1999 by Andreas Gustafsson, who, in the context of
the work on RFC 1995bis, recently has provided the DNSEXT WG access
to a privately archived DNSIND mailing list thread on RFC 1995,
in which these issues have been discussed in November 1999.
For the record, the technical issues in RFC 1995 that can be
addressed by Errata Notes are now being submitted this way.

Report New Errata



Search RFCs
Advanced Search
×