One document matched: draft-ietf-dnsind-ixfr-00.txt
INTERNET DRAFT M. Ohta
draft-ietf-dnsind-ixfr-00.txt Tokyo Institute of Technology
November 1994
Expires in six months
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 memo 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, 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 memo, 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 May 25, 1995 [Page 1]
INTERNET DRAFT Incremental Transfer in DNS November 1994
An IXFR client keeps record of older version of a zone. If the IXFR
client think it needs updated information of the zone (typically
through SOA refresh or NOTIFY mechanism), it sends an IXFR message
along with the SOA serial number information of the older zone. If
the client receives "Not implemented" response, it should try AXFR.
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.
All communication is done through TCP channel.
Query type value of IXFR is <to be assigned by IANA>.
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 containing the version number
of the older zone information.
4. Response Format
If the incremental zone transfer is not available, the same message
as AXFR (except that the query type is IXFR) is returned.
If the incremental zone transfer is available, several pairs of
messages with RCODE = IRESPONSE <value to be assigned by IANA> will
be returned. Each message is, as usual with TCP transport, prefixed
by two byte length fields. To indicate the end of transfer, two
bytes of 0 is attached after the last message.
Messages are always paired. Within the pair, the answer section of
the former message contains information on removed RRs form the
previous version and the latter message on added RRs. Modification of
RR is performed first by removing the orginal and then adding the
modified one. In the authority section, each message contains SOA of
the version of the modified result
Thus, the pairs give the history of changes made from the version
IXFR client had up to the newest version.
RRs in the incremental transfer messages may be partial. That is, if
a single RR of multiple RRs of a node changes, only the information
on changed RR needs to be transferred.
M. Ohta Expires on May 25, 1995 [Page 2]
INTERNET DRAFT Incremental Transfer in DNS November 1994
By an IXFR client, the messages should be processed sequentially and
replaced with the older version atomically only after all the
messages are successfully processed.
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 is 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.1
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.5
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
+---------------------------------------------------+
M. Ohta Expires on May 25, 1995 [Page 3]
INTERNET DRAFT Incremental Transfer in DNS November 1994
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
will be replied 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 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. |
| NEZU.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 four messages:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, RCODE=IRESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | NEZU.JAIN.AD.JP. IN A 133.69.136.1 |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=2 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, RCODE=IRESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
M. Ohta Expires on May 25, 1995 [Page 4]
INTERNET DRAFT Incremental Transfer in DNS November 1994
Answer | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.5 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=2 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, RCODE=IRESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.5 |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE, RCODE=IRESPONSE |
+---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 |
+---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=3 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
7. Possible Discussions
Should partial RR modification allowed?
Should AXFR is mandated periodically to protect the zone data from
accumulated errors (theoretically there can be no error).
What if default TTL changes? Should almost all RRs be retransmitted
or special treatment is desired?
Shouldn't transport mechanism over TCP modified to allow 4 bytes of
message length field?
8. Acknowledgements
The original idea of IXFR is conceived by Anant Kumar, Steve Hotz and
M. Ohta Expires on May 25, 1995 [Page 5]
INTERNET DRAFT Incremental Transfer in DNS November 1994
Jon Postel.
The simplified mechanism described in this memo is the product of the
several hours of discussion between Anant Kumar and the Author.
9. Security Considerations
Though DNS is related to several security problems, no attempt is
made to fix them in this memo.
This memo is believed to introduce no additional security problems to
the existing DNS protocol.
10. 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 May 25, 1995 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 06:52:46 |