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]