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]