From e002cd6b63ef6367a352aa7104cdf33b59dc6e92 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 3 Apr 2000 17:52:41 +0000 Subject: [PATCH] added --- doc/draft/draft-ietf-dnsext-ixfr-00.txt | 557 ++++++++++++++++++++++++ 1 file changed, 557 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsext-ixfr-00.txt diff --git a/doc/draft/draft-ietf-dnsext-ixfr-00.txt b/doc/draft/draft-ietf-dnsext-ixfr-00.txt new file mode 100644 index 0000000000..f81b55210b --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ixfr-00.txt @@ -0,0 +1,557 @@ +INTERNET DRAFT M. Ohta +draft-ietf-dnsext-ixfr-00.txt Tokyo Institute of Technology + March 2000 + + Incremental Zone Transfer in DNS + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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 + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Copyright (C) The Internet Society (March/5/2000). All Rights + Reserved. + +Abstract + + This document proposes extensions to the DNS protocols to provide an + incremental zone transfer (IXFR) mechanism. + +1. Introduction + + For rapid propagation of changes to a DNS database [STD13], it is + necessary to reduce latency by actively notifying servers of the + change. This is accomplished by the NOTIFY extension of the DNS + [NOTIFY]. + + The current full zone transfer mechanism (AXFR) is not an efficient + means to propagate changes to a small part of a zone, as it transfers + the entire zone file. + + Incremental transfer (IXFR) as proposed is a more efficient + mechanism, as it transfers only the changed portion(s) of a zone. + + + +M. Ohta Expires on September 5, 2000 [Page 1] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + In this document, a secondary name server which requests IXFR is + called an IXFR client and a primary or secondary name server which + responds to the request is called an IXFR server. + + The AXFR specification is very terse, and in practice it does not + contain sufficient information to construct interoperable + implementations. [XFRCLARIFY] gives the clarification on the AXFR + specification based on existing practice, which is, unless otherwise + noted, also applicable to IXFR. + +2. Brief Description of the Protocol + + If an IXFR client, which likely has an older version of a zone, + thinks it needs new information about the zone (typically through SOA + refresh timeout or the NOTIFY mechanism), it sends an IXFR message + containing the SOA serial number of its, presumably outdated, copy of + the zone. + + An IXFR server should keep record of the newest version of the zone + and the differences between that copy and several older versions. + When an IXFR request with an older version number is received, the + IXFR server needs to send only the differences required to make that + version current. Alternatively, the server may choose to transfer + the entire zone just as in a normal full zone transfer. + + When a zone has been updated, it should be saved in stable storage + before the new version is used to respond to IXFR (or AXFR) queries. + Otherwise, if the server crashes, data which is no longer available + may have been distributed to secondary servers, which can cause + persistent database inconsistencies. + + If an IXFR query with the same or newer version number than that of + the server is received, it is replied to with a single SOA record of + the server's current version, just as a SOA query before TCP AXFR. + + Transport of a query may be by either UDP or TCP. If an IXFR query + is via UDP, the IXFR server may attempt to reply using UDP if the + entire response can be contained in a single UDP packet. If the UDP + reply does not fit, the query is responded to with a single SOA + record of the server's current version to inform the client that a + TCP query should be initiated. + + Thus, a client should first make an IXFR query using UDP. If the + query type or other part of the query is not recognized by the + server, an AXFR (preceded by a UDP SOA query) should be tried, + ensuring backward compatibility. If the query response is a single + packet with the entire new zone, or if the server does not have a + newer version than the client, everything is done. Otherwise, a TCP + + + +M. Ohta Expires on September 5, 2000 [Page 2] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + IXFR query should be tried. + + To ensure integrity, servers should use UDP checksums for all UDP + responses. A cautious client which receives a UDP packet with a + checksum value of zero should ignore the result and try a TCP IXFR + instead. + + The query type value of IXFR assigned by IANA is 251. + +3. Query Format + + The IXFR query packet format is the same as that of a normal DNS + query, but with the query type being IXFR and the authority section + containing the SOA record of client's version of the zone. + +4. Response Format + + If incremental zone transfer is not available, the entire zone is + returned. The first and the last RR of the response is the SOA + record of the zone. I.e. the behavior is the same as an AXFR + response except the query type is IXFR. + + If incremental zone transfer is available, one or more difference + sequences is returned. The list of difference sequences is preceded + and followed by a copy of the server's current version of the SOA. + + Each difference sequence represents one update to the zone (one SOA + serial change) consisting of deleted RRs and added RRs. 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 an RR is performed first by removing the original RR + and then adding the modified one. + + A difference sequence which indicates the removal of a non-existent + RR is an indication of an error that the IXFR client is out-of-sync + with the IXFR server. The IXFR SHOULD be aborted, and an AXFR + requested from the same server. A difference sequence which + indicates the addition of a seemingly duplicate (through a node may + have multiple TXT RRs of the duplicated content) or conflicting RR + may just be a result of malformed zone ando should be treated just as + a AXFR with malformed zone content. + + The sequences of differential information are ordered oldest first + newest last. Thus, the differential sequences are the history of + changes made since the version known by the IXFR client up to the + server's current version. + + + + +M. Ohta Expires on September 5, 2000 [Page 3] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + RR sets (RRs of the same RR types) in the incremental transfer + messages may be partial. For examle, if a single RR of multiple RRs + of the same RR type changes, only the changed RR needs to be + transferred. + + An IXFR client, should only replace an older version with a newer + version after all the differences have been successfully processed. + + An incremental response is different from that of a non-incremental + response in that it begins with two SOA RRs, the server's current SOA + followed by the SOA of the client's version which is about to be + replaced. + + To determine whether an IXFR response received over TCP is + incremental or not, it is necessary to try to receive the first two + answer RRs in the answer stream (which may or may not involve + receiving two TCP DNS messages). The first RR is always an SOA. If + the second RR does not exist, the client copy of the zone is up to + date and no zone transfer is necessary. If the second RR is an SOA + with a serial number different from the first SOA, the response is + incremental, in IXFR format. If it is a non-SOA RR or a SOA RR with + the same serial number as the initial SOA RR, it is a nonincremental + response in AXFR format. The last case cannot arise unless the zone + is malformed containing only the SOA record without NS records. + + This is the only way to identify an incremental response. A slave + cannot reliably identify an incremental response based on the + presence or absence of a question section, the QTYPE field of a + possible question section, or the number of response RRs per message, + +5. Purging Strategy + + An IXFR server can not be required to hold all previous versions + forever and may delete them anytime. In general, there is a trade-off + between the size of storage space and the possibility of using IXFR. + + Information about older versions should be purged if the total length + of an IXFR response would be longer than that of an AXFR response. + Given that the purpose of IXFR is to reduce AXFR overhead, this + strategy is quite reasonable. The strategy assures that the amount + of storage required is at most twice that of the current zone + information. + + Information older than the SOA expire period should also be purged. + +6. Optional Condensation of Multiple Versions + + An IXFR server may optionally condense multiple difference sequences + + + +M. Ohta Expires on September 5, 2000 [Page 4] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + into a single difference sequence, thus, dropping information on + intermediate versions. + + This may be beneficial if a lot of versions, not all of which are + useful, are generated. For example, if multiple ftp servers share a + single DNS name and the IP address associated with the name is + changed once a minute to balance load between the ftp servers, it is + 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 access + to two IXFR servers: A and B, with inconsistent condensation results. + The current version of the IXFR client, received from server A, may + be unknown to server B. In such a case, server B can not provide + incremental data from the unknown version and a full zone transfer is + necessary. + + Condensation is completely optional. Clients can't detect from the + response whether the server has condensed the reply or not. + + For interoperability, IXFR servers, including those without the + condensation feature, should not flag an error even if it receives a + client's IXFR request with a version number known not to exist (which + means that the server has versions with version numbers newer and + older than, but not equal to, the version number) and should, + instead, attempt to perform a full zone transfer by replying with a + single SOA record of the server's current version (UDP case) or with + a full zone content (UDP or TCP case). + +7. Example + + Given the following three generations of data with the current 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. ( + 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 + + + + +M. Ohta Expires on September 5, 2000 [Page 5] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + 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 | | + +---------------------------------------------------+ + 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 | | + +---------------------------------------------------+ + + or with the following incremental message: + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + + + +M. Ohta Expires on September 5, 2000 [Page 6] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + +---------------------------------------------------+ + 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 | | + +---------------------------------------------------+ + + or, if UDP packet overflow occurs, with the following message: + + + + + + + + + + + + +M. Ohta Expires on September 5, 2000 [Page 7] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + +---------------------------------------------------+ + Header | OPCODE=SQUERY, RESPONSE | + +---------------------------------------------------+ + Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | + +---------------------------------------------------+ + Answer | JAIN.AD.JP. IN SOA serial=3 | + +---------------------------------------------------+ + Authority | | + +---------------------------------------------------+ + Additional | | + +---------------------------------------------------+ + +8. Acknowledgements + + The original idea of IXFR was conceived by Anant Kumar, Steve Hotz + and Jon Postel. + + For the refinement of the protocol and documentation, many people + have contributed including, but not limited to, Anant Kumar, Robert + Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas + Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and + the members of the IETF DNSEXT working group. + +9. References + + [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC1996, August 1996. + + [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), + November 1987. + + [XFRCLARIFY] + +10. 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 current DNS protocol. + +11. Author's Address + + Masataka Ohta + Computer Center, Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN + + Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 + + + +M. Ohta Expires on September 5, 2000 [Page 8] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + + EMail: mohta@necom830.hpcl.titech.ac.jp + + Comments should be directed to DNSEXT WG . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +M. Ohta Expires on September 5, 2000 [Page 9] + +INTERNET DRAFT Incremental Zone Transfer in DNS March 2000 + + +12. Full Copyright Statement + + "Copyright (C) The Internet Society (March/5/2000). All Rights + Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + +M. Ohta Expires on September 5, 2000 [Page 10] +