INTERNET DRAFT M. Ohta
draft-ietf-dnsind-ixfr-01.txt Tokyo Institute of Technology
February 1995
Incremental Transfer in DNS
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
This document proposes extensions to the DNS protocols to provide an
incremental zone transfer (IXFR) procedure.
1. Introduction
For the quick propagation of changes to the DNS database [STD13], it
is necessary to shorten the latency by actively notifying the change,
which is accomplished by NOTIFY extension of DNS [NOTIFY].
At the same time, to propagate a small amount of changes in a large
zone, existing zone transfer mechanism to transfer all the data of
the zone is quite inefficient and time consuming.
Incremental transfer (IXFR) is a zone transfer mechanism to transfer
only the changed portion of the zone,
In this document, a secondary name server who request IXFR is called
IXFR client and a primary or secondary name server who responses the
request is called IXFR server.
2. Brief Description of the Protocol.
M. Ohta Expires on Aug 25, 1995 [Page 1]
INTERNET DRAFT Incremental Transfer in DNS February 1995
An IXFR client keeps record of an older version of a zone. If the
IXFR client think it needs updated information of the zone (typically
through SOA refresh timeout or NOTIFY mechanism), it sends an IXFR
message along with the SOA serial number information of the older
zone.
An IXFR server should keep record of the newest version of the zone
and the differences to several older versions. If IXFR request with
memorized older version number is received, the IXFR server MAY send
only the difference to that version. Otherwise, the entire zone is
transferred just as normal zone transfer. IXFR queries conceptually
matches SOA RRS. Thus, if an IXFR query with the same or newer
version number than the server is made, it is replied with a single
SOA record of the newest version.
Transport of query may either be UDP or TCP. If an IXFR query is by
UDP, IXFR server MAY attempt to reply if the entire response can be
contained in a single DNS packet. Otherwise, the query is replied
with a single SOA record of the server.
Thus, clients attempting the IXFR should first make IXFR query by
UDP. If query type is not recognized by the server, AXFR should be
tried preceded with a UDP SOA query. If the query is replied with a
single packet with all the information on the newest zone or if the
server dose not have the newer version than the client, everything is
done. Otherwise, TCP IXFR query should be attempted.
Query type value of IXFR assigned by IANA is 251.
3. Query Format
The IXFR query packet format is same as that of the normal DNS query
with query type of IXFR, except that the authority section is non-
empty and contains a single SOA record of client's version of the
zone.
4. Response Format
If the incremental zone transfer is not available, the entire zone
information is returned. The first and the last RR of the response is
the SOA record of the zone. The behavior is same as AXFR response
except that the query type is IXFR.
If the incremental zone transfer is available, sequence of
differential information is returned. The entire response is
sandwiched by the newest SOA.
Each differential information consists of deleted RRs and added RRs.
M. Ohta Expires on Aug 25, 1995 [Page 2]
INTERNET DRAFT Incremental Transfer in DNS February 1995
The first RR of the deleted RRs is the older SOA RR and the first RR
of the added RRs is the newer SOA RR.
Modification of a RR is performed first by removing the original RR
and then adding a modified one.
The sequence of the differential information is ordered older one
first newer one last. Thus, the sequence of the differential
information give the history of changes made from the version of IXFR
client up to the newest version.
RRs in the incremental transfer messages may be partial. That is, if
a single RR of multiple RRs with the same RR type changes, only the
information on changed RR needs to be transferred.
By an IXFR client, the newer version should be replaced with the
older version atomically only after all the differences are
successfully processed.
The incremental response begins with two SOA RRs and distinguishable
from non-incremental ones.
5. Purging Strategy
The IXFR server can not hold information on older versions forever.
Information on older versions should be purged, if total length of
IXFR messages is longer than that of an AXFR message. Considering
that the purpose of IXFR is to reduce AXFR overhead, this strategy is
quite reasonable. It also assures that the amount of storage is at
most twice as large as that of the current zone information.
Information older than SOA expire period may also be purged.
6. Example
With the following three generations of data with the up-to-date
serial 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. (
M. Ohta Expires on Aug 25, 1995 [Page 3]
INTERNET DRAFT Incremental Transfer in DNS February 1995
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
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 query
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
may be replied 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 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following incremental message:
M. Ohta Expires on Aug 25, 1995 [Page 4]
INTERNET DRAFT Incremental Transfer in DNS February 1995
+---------------------------------------------------+
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 | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following message, if UDP packet overflow occurs:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
7. Acknowledgements
The original idea of IXFR is conceived by Anant Kumar, Steve Hotz and
Jon Postel.
For the refinement of the protocol and documentation, many people
including, but not limited to, Anant Kumar, Robert Austein, Paul
Vixie, Randy Bush and the members of the IETF DNSIND working group
have contributed.
8. References
M. Ohta Expires on Aug 25, 1995 [Page 5]
INTERNET DRAFT Incremental Transfer in DNS February 1995
[NOTIFY]
[STD13]
8. Security Considerations
Though DNS is related to several security problems, no attempt is
made to fix them in this document.
This document is believed to introduce no additional security
problems to the existing DNS protocol.
9. Author's Address
Masataka Ohta
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku,
Tokyo 152, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3415
EMail: mohta@necom830.cc.titech.ac.jp
M. Ohta Expires on Aug 25, 1995 [Page 6]