RFC relevance of standards

As per Relevance of the word standards, we have this rfc below:

Network Working Group M.
Request for Comments: 1995 Tokyo Institute of
Updates: 1035 August 1996
Category: Standards

Incremental Zone Transfer in

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

This document proposes extensions to the DNS protocols to provide
incremental zone transfer (IXFR) mechanism

1.

For rapid propagation of changes to a DNS database [STD13], it
necessary to reduce latency by actively notifying servers of
change. This is accomplished by the NOTIFY extension of the
[NOTIFY].

The current full zone transfer mechanism (AXFR) is not an
means to propagate changes to a small part of a zone, as it
the entire zone file

Incremental transfer (IXFR) as proposed is a more
mechanism, as it transfers only the changed portion(s) of a zone

In this document, a secondary name server which requests IXFR
called an IXFR client and a primary or secondary name server
responds to the request is called an IXFR server

2. Brief Description of the

If an IXFR client, which likely has an older version of a zone
thinks it needs new information about the zone (typically through
refresh timeout or the NOTIFY mechanism), it sends an IXFR
containing the SOA serial number of its, presumably outdated, copy
the zone

Ohta Standards Track [Page 1]

RFC 1995 Incremental Zone Transfer in DNS August 1996

An IXFR server should keep record of the newest version of the
and the differences between that copy and several older versions
When an IXFR request with an older version number is received,
IXFR server needs to send only the differences required to make
version current. Alternatively, the server may choose to
the entire zone just as in a normal full zone transfer

When a zone has been updated, it should be saved in stable
before the new version is used to respond to IXFR (or AXFR) queries
Otherwise, if the server crashes, data which is no longer
may have been distributed to secondary servers, which can
persistent database inconsistencies

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

Transport of a query may be by either UDP or TCP. If an IXFR
is via UDP, the IXFR server may attempt to reply using UDP if
entire response can be contained in a single DNS packet. If the
reply does not fit, the query is responded to with a single
record of the server's current version to inform the client that
TCP query should be initiated

Thus, a client should first make an IXFR query using UDP. If
query type is not recognized by the server, an AXFR (preceded by
UDP SOA query) should be tried, ensuring backward compatibility.
the query response is a single packet with the entire new zone, or
the server does not have a newer version than the client,
is done. Otherwise, a TCP IXFR query should be tried

To ensure integrity, servers should use UDP checksums for all
responses. A cautious client which receives a UDP packet with
checksum value of zero should ignore the result and try a TCP
instead

The query type value of IXFR assigned by IANA is 251.

3. Query

The IXFR query packet format is the same as that of a normal
query, but with the query type being IXFR and the authority
containing the SOA record of client's version of the zone

Ohta Standards Track [Page 2]

RFC 1995 Incremental Zone Transfer in DNS August 1996

4. Response

If incremental zone transfer is not available, the entire zone
returned. The first and the last RR of the response is the
record of the zone. I.e. the behavior is the same as an
response except the query type is IXFR

If incremental zone transfer is available, one or more
sequences is returned. The list of difference sequences is
and followed by a copy of the server's current version of the SOA

Each difference sequence represents one update to the zone (one
serial change) consisting of deleted RRs and added RRs. The first
of the deleted RRs is the older SOA RR and the first RR of the
RRs is the newer SOA RR

Modification of an RR is performed first by removing the original
and then adding the modified one

The sequences of differential information are ordered oldest
newest last. Thus, the differential sequences are the history
changes made since the version known by the IXFR client up to
server's current version

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

An IXFR client, should only replace an older version with a
version after all the differences have been successfully processed

An incremental response is different from that of a non-
response in that it begins with two SOA RRs, the server's current
followed by the SOA of the client's version which is about to
replaced

5. Purging

An IXFR server can not be required to hold all previous
forever and may delete them anytime. In general, there is a trade-
between the size of storage space and the possibility of using IXFR

Information about older versions should be purged if the total
of an IXFR response would be longer than that of an AXFR response
Given that the purpose of IXFR is to reduce AXFR overhead,
strategy is quite reasonable. The strategy assures that the
of storage required is at most twice that of the current
information

Ohta Standards Track [Page 3]

RFC 1995 Incremental Zone Transfer in DNS August 1996

Information older than the SOA expire period may also be purged

6. Optional Condensation of Multiple

An IXFR server may optionally condense multiple difference
into a single difference sequence, thus, dropping information
intermediate versions

This may be beneficial if a lot of versions, not all of which
useful, are generated. For example, if multiple ftp servers share
single DNS name and the IP address associated with the name
changed once a minute to balance load between the ftp servers, it
not so important to keep track of all the history of changes

But, this feature may not be so useful if an IXFR client has
to two IXFR servers: A and B, with inconsistent condensation results
The current version of the IXFR client, received from server A,
be unknown to server B. In such a case, server B can not
incremental data from the unknown version and a full zone transfer
necessary

Condensation is completely optional. Clients can't detect from
response whether the server has condensed the reply or not

For interoperability, IXFR servers, including those without
condensation feature, should not flag an error even if it receives
client's IXFR request with a unknown version number and should
instead, attempt to perform a full zone transfer

7.

Given the following three generations of data with the current
number of 3,

JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5

NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added

jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4
IN A 192.41.197.2

Ohta Standards Track [Page 4]

RFC 1995 Incremental Zone Transfer in DNS August 1996

One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed

JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP
NS.JAIN.AD.JP. IN A 133.69.136.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3
IN A 192.41.197.2

The following IXFR

+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+

could be replied to with the following full zone transfer message

+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
| NS.JAIN.AD.JP. IN A 133.69.136.1 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+

Ohta Standards Track [Page 5]

RFC 1995 Incremental Zone Transfer in DNS August 1996

or with the following incremental message

+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+

or with the following condensed incremental message

+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN.AD.JP. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
| JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+

Ohta Standards Track [Page 6]

RFC 1995 Incremental Zone Transfer in DNS August 1996

or, if UDP packet overflow occurs, with the following message

+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | |
+---------------------------------------------------+
Additional | |
+---------------------------------------------------+

8.

The original idea of IXFR was conceived by Anant Kumar, Steve
and Jon Postel

For the refinement of the protocol and documentation, many
have contributed including, but not limited to, Anant Kumar,
Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and
members of the IETF DNSIND working group

9.

[NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for
Notification of Zone Changes", RFC 1996, August 1996.

[STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034
RFC 1035), November 1987.

10. Security

Though DNS is related to several security problems, no attempt
made to fix them in this document

This document is believed to introduce no additional
problems to the current DNS protocol

Ohta Standards Track [Page 7]

RFC 1995 Incremental Zone Transfer in DNS August 1996

11. Author's

Masataka
Computer
Tokyo Institute of
2-12-1, O-okayama, Meguro-ku, Tokyo 152,

Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.

Ohta Standards Track [Page 8]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX