summaryrefslogtreecommitdiffstats
path: root/doc/rfc/rfc1995.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1995.txt')
-rw-r--r--doc/rfc/rfc1995.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1995.txt b/doc/rfc/rfc1995.txt
new file mode 100644
index 0000000..b50bdc6
--- /dev/null
+++ b/doc/rfc/rfc1995.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group M. Ohta
+Request for Comments: 1995 Tokyo Institute of Technology
+Updates: 1035 August 1996
+Category: Standards Track
+
+
+ Incremental Zone Transfer in DNS
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+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.
+
+ 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.
+
+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.
+
+
+
+
+
+Ohta Standards Track [Page 1]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+ 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 in 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 DNS 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 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 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.
+
+
+
+
+
+
+
+
+Ohta Standards Track [Page 2]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+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.
+
+ 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.
+
+ RRs in the incremental transfer messages may be partial. That is, if
+ a single RR of multiple RRs of the same RR type changes, only the
+ changed RR is 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.
+
+ 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.
+
+
+
+Ohta Standards Track [Page 3]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+ Information older than the SOA expire period may also be purged.
+
+6. Optional Condensation of Multiple Versions
+
+ An IXFR server may optionally condense multiple difference sequences
+ 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 unknown version number and should,
+ instead, attempt to perform a full zone transfer.
+
+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
+
+
+
+Ohta Standards Track [Page 4]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+ 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> |
+ +---------------------------------------------------+
+
+ 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 | <empty> |
+ +---------------------------------------------------+
+ Additional | <empty> |
+ +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Ohta Standards Track [Page 5]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+ or with the following 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=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 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 | <empty> |
+ +---------------------------------------------------+
+ Additional | <empty> |
+ +---------------------------------------------------+
+
+
+
+
+
+
+
+
+Ohta Standards Track [Page 6]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+ or, if UDP packet overflow occurs, 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 |
+ +---------------------------------------------------+
+ Authority | <empty> |
+ +---------------------------------------------------+
+ Additional | <empty> |
+ +---------------------------------------------------+
+
+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 and the
+ members of the IETF DNSIND working group.
+
+9. References
+
+ [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
+ Notification of Zone Changes", RFC 1996, August 1996.
+
+ [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
+ RFC 1035), November 1987.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta Standards Track [Page 7]
+
+RFC 1995 Incremental Zone Transfer in DNS August 1996
+
+
+11. Author's Address
+
+ Masataka Ohta
+ Computer Center
+ 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.hpcl.titech.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta Standards Track [Page 8]
+
generated by cgit (git 2.34.1) at 2024-04-16 15:02:04 +0000