diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc1995.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc1995.txt | 451 |
1 files changed, 0 insertions, 451 deletions
diff --git a/contrib/bind9/doc/rfc/rfc1995.txt b/contrib/bind9/doc/rfc/rfc1995.txt deleted file mode 100644 index b50bdc6..0000000 --- a/contrib/bind9/doc/rfc/rfc1995.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -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] - |
