559 lines
23 KiB
Plaintext
559 lines
23 KiB
Plaintext
|
||
INTERNET DRAFT M. Ohta
|
||
draft-ietf-dnsext-ixfr-01.txt Tokyo Institute of Technology
|
||
June 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 December 5, 2000 [Page 1]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 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 current AXFR specification in [STD13] is very terse, and in
|
||
practice it does not contain sufficient information to construct
|
||
interoperable implementations. This memo assumes AXFR protocol used
|
||
in existing interoperable implementations.
|
||
|
||
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
|
||
IXFR query should be tried.
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 2]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
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.
|
||
|
||
Each individual difference sequence must leave the zone in a
|
||
consistent state with contents identical to those visible in the
|
||
master at the time identified by the new SOA serial number. During a
|
||
transfer, the slave server may save the zone data to stable storage
|
||
and use it in responding to queries after applying one or more
|
||
complete difference sequences even if they do not yet form a complete
|
||
incremental transfer.
|
||
|
||
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 (though a node may
|
||
have multiple TXT RR's with duplicate content) or conflicting RR may
|
||
just be a malformed zone. In any case the IXFR should be aborted and
|
||
AXFR performed.
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 3]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
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.
|
||
|
||
RR sets (RRs of the same RR types) in the incremental transfer
|
||
messages may be partial. For example, 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.
|
||
|
||
A slave receiving an IXFR response needs to classify it as one of the
|
||
following four cases:
|
||
|
||
UDP-overflow An indication that the transfer will not fit in a
|
||
UDP packet and should be retried over TCP
|
||
|
||
up-to-date An indication that the serial number of the
|
||
request is current and no transfer is necessary
|
||
|
||
incremental An incremental transfer
|
||
|
||
nonincremental A full zone transfer
|
||
|
||
Performing this classification requires some care. For example,
|
||
UDP-overflow responses differ from UDP up-to-date responses only in
|
||
the value of the SOA serial number. Also, to distinguish between a
|
||
nonincremental and an incremental transfer, the slave needs to
|
||
receive the first two response RRs and check whether the second one
|
||
is a SOA. If the master chose to transmit each RR in a separate TCP
|
||
message, this involves waiting for a second TCP response message. On
|
||
the other hand, in the case of an up-to-date response, the slave must
|
||
not wait for a second TCP message as doing so would cause it to hang
|
||
waiting for a message the master will never send. Therefore, the
|
||
slave must examine the first message and eliminate the possibility
|
||
that it is a TCP up-to-date response before it attempts to receive a
|
||
second message.
|
||
|
||
Slaves must not attempt to classify a response based on incidental
|
||
information such as the presence or absence of a question section,
|
||
the QTYPE field of a possible question section, or the number of
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 4]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
response RRs in a TCP response message.
|
||
|
||
An example algorithm for classifying IXFR responses appears in
|
||
Appendix A.
|
||
|
||
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
|
||
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,
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 5]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
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,
|
||
|
||
example.domain. IN SOA ns.example.domain. rt.example.domain. (
|
||
1 600 600 3600000 604800)
|
||
IN NS ns.example.domain.
|
||
ns.example.domain. IN A 10.0.0.1
|
||
ftp.example.domain. IN A 10.0.1.1
|
||
|
||
ftp.example.domain. is removed and www.example.domain. is added.
|
||
|
||
example.domain. IN SOA ns.example.domain. rt.example.domain. (
|
||
2 600 600 3600000 604800)
|
||
IN NS ns.example.domain.
|
||
ns.example.domain. IN A 10.0.0.1
|
||
www.example.domain. IN A 10.0.1.2
|
||
IN A 10.0.2.1
|
||
|
||
One of the IP addresses of www.example.domain. is changed.
|
||
|
||
example.domain. IN SOA ns.example.domain. rt.example.domain. (
|
||
3 600 600 3600000 604800)
|
||
IN NS ns.example.domain.
|
||
ns.example.domain. IN A 10.0.0.1
|
||
www.example.domain. IN A 10.0.3.1
|
||
IN A 10.0.2.1
|
||
|
||
The following IXFR query
|
||
|
||
+---------------------------------------------------+
|
||
Header | OPCODE=SQUERY |
|
||
+---------------------------------------------------+
|
||
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
|
||
+---------------------------------------------------+
|
||
Answer | <empty> |
|
||
+---------------------------------------------------+
|
||
Authority | example.domain. IN SOA serial=1 |
|
||
+---------------------------------------------------+
|
||
Additional | <empty> |
|
||
+---------------------------------------------------+
|
||
|
||
could be replied to with the following full zone transfer message:
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 6]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
+---------------------------------------------------+
|
||
Header | OPCODE=SQUERY, RESPONSE |
|
||
+---------------------------------------------------+
|
||
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
|
||
+---------------------------------------------------+
|
||
Answer | example.domain. IN SOA serial=3 |
|
||
| example.domain. IN NS NS.JAIN.AD.JP. |
|
||
| ns.example.domain. IN A 10.0.0.1 |
|
||
| www.example.domain. IN A 10.0.3.1 |
|
||
| www.example.domain. IN A 10.0.2.1 |
|
||
| example.domain. IN SOA serial=3 |
|
||
+---------------------------------------------------+
|
||
Authority | <empty> |
|
||
+---------------------------------------------------+
|
||
Additional | <empty> |
|
||
+---------------------------------------------------+
|
||
|
||
or with the following incremental message:
|
||
|
||
+---------------------------------------------------+
|
||
Header | OPCODE=SQUERY, RESPONSE |
|
||
+---------------------------------------------------+
|
||
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
|
||
+---------------------------------------------------+
|
||
Answer | example.domain. IN SOA serial=3 |
|
||
| example.domain. IN SOA serial=1 |
|
||
| ftp.example.domain. IN A 10.0.1.1 |
|
||
| example.domain. IN SOA serial=2 |
|
||
| www.example.domain. IN A 10.0.1.2 |
|
||
| www.example.domain. IN A 10.0.2.1 |
|
||
| example.domain. IN SOA serial=2 |
|
||
| www.example.domain. IN A 10.0.1.2 |
|
||
| example.domain. IN SOA serial=3 |
|
||
| www.example.domain. IN A 10.0.3.1 |
|
||
| example.domain. IN SOA serial=3 |
|
||
+---------------------------------------------------+
|
||
Authority | <empty> |
|
||
+---------------------------------------------------+
|
||
Additional | <empty> |
|
||
+---------------------------------------------------+
|
||
|
||
or with the following condensed incremental message:
|
||
|
||
+---------------------------------------------------+
|
||
Header | OPCODE=SQUERY, RESPONSE |
|
||
+---------------------------------------------------+
|
||
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
|
||
+---------------------------------------------------+
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 7]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
Answer | example.domain. IN SOA serial=3 |
|
||
| example.domain. IN SOA serial=1 |
|
||
| ftp.example.domain. IN A 10.0.1.1 |
|
||
| example.domain. IN SOA serial=3 |
|
||
| www.example.domain. IN A 10.0.3.1 |
|
||
| www.example.domain. IN A 10.0.2.1 |
|
||
| example.domain. IN SOA serial=3 |
|
||
+---------------------------------------------------+
|
||
Authority | <empty> |
|
||
+---------------------------------------------------+
|
||
Additional | <empty> |
|
||
+---------------------------------------------------+
|
||
|
||
or, if UDP packet overflow occurs, with the following message:
|
||
|
||
+---------------------------------------------------+
|
||
Header | OPCODE=SQUERY, RESPONSE |
|
||
+---------------------------------------------------+
|
||
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
|
||
+---------------------------------------------------+
|
||
Answer | example.domain. 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, 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.
|
||
|
||
10. Appendix A Appendix A. Pseudocode for response classification
|
||
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 8]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
The following pseudocode outlines one possible algorithm for
|
||
classifying IXFR responses.
|
||
|
||
receive the first response message;
|
||
extract the first response RR, always an SOA;
|
||
if (the serial number of this SOA RR is less
|
||
than or equal to that of the request) {
|
||
the response is an up-to-date response;
|
||
} else {
|
||
if (the response message was received by UDP and
|
||
contains no more RRs after the initial SOA) {
|
||
the response is a UDP-overflow response;
|
||
} else {
|
||
extract the second response RR, waiting for a second TCP
|
||
response message if necessary;
|
||
if (this second RR is an SOA) {
|
||
the response is an incremental transfer;
|
||
} else {
|
||
the response is a nonincremental transfer;
|
||
}
|
||
}
|
||
}
|
||
|
||
11. 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.
|
||
|
||
12. 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
|
||
EMail: mohta@necom830.hpcl.titech.ac.jp
|
||
|
||
Comments should be directed to DNSEXT WG <namedroppers@ops.ietf.org>.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
M. Ohta Expires on December 5, 2000 [Page 9]
|
||
|
||
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
|
||
|
||
|
||
13. 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 December 5, 2000 [Page 10]
|
||
|