draft-ietf-dnsext-ixfr-00.txt   draft-ietf-dnsext-ixfr-01.txt 
INTERNET DRAFT M. Ohta INTERNET DRAFT M. Ohta
draft-ietf-dnsext-ixfr-00.txt Tokyo Institute of Technology draft-ietf-dnsext-ixfr-01.txt Tokyo Institute of Technology
March 2000 June 2000
Incremental Zone Transfer in DNS Incremental Zone Transfer in DNS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 9 skipping to change at page 2, line 9
means to propagate changes to a small part of a zone, as it transfers means to propagate changes to a small part of a zone, as it transfers
the entire zone file. the entire zone file.
Incremental transfer (IXFR) as proposed is a more efficient Incremental transfer (IXFR) as proposed is a more efficient
mechanism, as it transfers only the changed portion(s) of a zone. mechanism, as it transfers only the changed portion(s) of a zone.
In this document, a secondary name server which requests IXFR is In this document, a secondary name server which requests IXFR is
called an IXFR client and a primary or secondary name server which called an IXFR client and a primary or secondary name server which
responds to the request is called an IXFR server. responds to the request is called an IXFR server.
The AXFR specification is very terse, and in practice it does not The current AXFR specification in [STD13] is very terse, and in
contain sufficient information to construct interoperable practice it does not contain sufficient information to construct
implementations. [XFRCLARIFY] gives the clarification on the AXFR interoperable implementations. This memo assumes AXFR protocol used
specification based on existing practice, which is, unless otherwise in existing interoperable implementations.
noted, also applicable to IXFR.
2. Brief Description of the Protocol 2. Brief Description of the Protocol
If an IXFR client, which likely has an older version of a zone, If an IXFR client, which likely has an older version of a zone,
thinks it needs new information about the zone (typically through SOA thinks it needs new information about the zone (typically through SOA
refresh timeout or the NOTIFY mechanism), it sends an IXFR message refresh timeout or the NOTIFY mechanism), it sends an IXFR message
containing the SOA serial number of its, presumably outdated, copy of containing the SOA serial number of its, presumably outdated, copy of
the zone. the zone.
An IXFR server should keep record of the newest version of the zone An IXFR server should keep record of the newest version of the zone
skipping to change at page 3, line 38 skipping to change at page 3, line 37
and followed by a copy of the server's current version of the SOA. 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 Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR 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 of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR. RRs is the newer SOA RR.
Modification of an RR is performed first by removing the original RR Modification of an RR is performed first by removing the original RR
and then adding the modified one. 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 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 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 with the IXFR server. The IXFR SHOULD be aborted, and an AXFR
requested from the same server. A difference sequence which requested from the same server. A difference sequence which
indicates the addition of a seemingly duplicate (through a node may indicates the addition of a seemingly duplicate (though a node may
have multiple TXT RRs of the duplicated content) or conflicting RR have multiple TXT RR's with duplicate content) or conflicting RR may
may just be a result of malformed zone ando should be treated just as just be a malformed zone. In any case the IXFR should be aborted and
a AXFR with malformed zone content. AXFR performed.
The sequences of differential information are ordered oldest first The sequences of differential information are ordered oldest first
newest last. Thus, the differential sequences are the history of newest last. Thus, the differential sequences are the history of
changes made since the version known by the IXFR client up to the changes made since the version known by the IXFR client up to the
server's current version. server's current version.
RR sets (RRs of the same RR types) in the incremental transfer 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 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 of the same RR type changes, only the changed RR needs to be
transferred. transferred.
An IXFR client, should only replace an older version with a newer An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed. version after all the differences have been successfully processed.
An incremental response is different from that of a non-incremental 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 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 followed by the SOA of the client's version which is about to be
replaced. replaced.
To determine whether an IXFR response received over TCP is A slave receiving an IXFR response needs to classify it as one of the
incremental or not, it is necessary to try to receive the first two following four cases:
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 UDP-overflow An indication that the transfer will not fit in a
cannot reliably identify an incremental response based on the UDP packet and should be retried over TCP
presence or absence of a question section, the QTYPE field of a
possible question section, or the number of response RRs per message, 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
response RRs in a TCP response message.
An example algorithm for classifying IXFR responses appears in
Appendix A.
5. Purging Strategy 5. Purging Strategy
An IXFR server can not be required to hold all previous versions 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 forever and may delete them anytime. In general, there is a trade-
between the size of storage space and the possibility of using IXFR. off between the size of storage space and the possibility of using
IXFR.
Information about older versions should be purged if the total length Information about older versions should be purged if the total length
of an IXFR response would be longer than that of an AXFR response. 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 Given that the purpose of IXFR is to reduce AXFR overhead, this
strategy is quite reasonable. The strategy assures that the amount strategy is quite reasonable. The strategy assures that the amount
of storage required is at most twice that of the current zone of storage required is at most twice that of the current zone
information. information.
Information older than the SOA expire period should also be purged. Information older than the SOA expire period should also be purged.
skipping to change at page 5, line 37 skipping to change at page 6, line 13
older than, but not equal to, the version number) and should, older than, but not equal to, the version number) and should,
instead, attempt to perform a full zone transfer by replying with a 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 single SOA record of the server's current version (UDP case) or with
a full zone content (UDP or TCP case). a full zone content (UDP or TCP case).
7. Example 7. Example
Given the following three generations of data with the current serial Given the following three generations of data with the current serial
number of 3, number of 3,
JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. ( example.domain. IN SOA ns.example.domain. rt.example.domain. (
1 600 600 3600000 604800) 1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP. IN NS ns.example.domain.
NS.JAIN.AD.JP. IN A 133.69.136.1 ns.example.domain. IN A 10.0.0.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5 ftp.example.domain. IN A 10.0.1.1
NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added. ftp.example.domain. is removed and www.example.domain. is added.
jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( example.domain. IN SOA ns.example.domain. rt.example.domain. (
2 600 600 3600000 604800) 2 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP. IN NS ns.example.domain.
NS.JAIN.AD.JP. IN A 133.69.136.1 ns.example.domain. IN A 10.0.0.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 www.example.domain. IN A 10.0.1.2
IN A 192.41.197.2 IN A 10.0.2.1
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. ( 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) 3 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP. IN NS ns.example.domain.
NS.JAIN.AD.JP. IN A 133.69.136.1 ns.example.domain. IN A 10.0.0.1
JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 www.example.domain. IN A 10.0.3.1
IN A 192.41.197.2 IN A 10.0.2.1
The following IXFR query The following IXFR query
+---------------------------------------------------+ +---------------------------------------------------+
Header | OPCODE=SQUERY | Header | OPCODE=SQUERY |
+---------------------------------------------------+ +---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+ +---------------------------------------------------+
Answer | <empty> | Answer | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
Authority | JAIN.AD.JP. IN SOA serial=1 | Authority | example.domain. IN SOA serial=1 |
+---------------------------------------------------+ +---------------------------------------------------+
Additional | <empty> | Additional | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
could be replied to with the following full zone transfer message: could be replied to with the following full zone transfer message:
+---------------------------------------------------+ +---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE | Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+ +---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+ +---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 | Answer | example.domain. IN SOA serial=3 |
| JAIN.AD.JP. IN NS NS.JAIN.AD.JP. | | example.domain. IN NS NS.JAIN.AD.JP. |
| NS.JAIN.AD.JP. IN A 133.69.136.1 | | ns.example.domain. IN A 10.0.0.1 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | | www.example.domain. IN A 10.0.3.1 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | | www.example.domain. IN A 10.0.2.1 |
| JAIN.AD.JP. IN SOA serial=3 | | example.domain. IN SOA serial=3 |
+---------------------------------------------------+ +---------------------------------------------------+
Authority | <empty> | Authority | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
Additional | <empty> | Additional | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
or with the following incremental message: or with the following incremental message:
+---------------------------------------------------+ +---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE | Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+ +---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+ +---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 | Answer | example.domain. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 | | example.domain. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 | | ftp.example.domain. IN A 10.0.1.1 |
| JAIN.AD.JP. IN SOA serial=2 | | example.domain. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | | www.example.domain. IN A 10.0.1.2 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | | www.example.domain. IN A 10.0.2.1 |
| JAIN.AD.JP. IN SOA serial=2 | | example.domain. IN SOA serial=2 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | | www.example.domain. IN A 10.0.1.2 |
| JAIN.AD.JP. IN SOA serial=3 | | example.domain. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | | www.example.domain. IN A 10.0.3.1 |
| JAIN.AD.JP. IN SOA serial=3 | | example.domain. IN SOA serial=3 |
+---------------------------------------------------+ +---------------------------------------------------+
Authority | <empty> | Authority | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
Additional | <empty> | Additional | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
or with the following condensed incremental message: or with the following condensed incremental message:
+---------------------------------------------------+ +---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE | Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+ +---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+ +---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 | Answer | example.domain. IN SOA serial=3 |
| JAIN.AD.JP. IN SOA serial=1 | | example.domain. IN SOA serial=1 |
| NEZU.JAIN.AD.JP. IN A 133.69.136.5 | | ftp.example.domain. IN A 10.0.1.1 |
| JAIN.AD.JP. IN SOA serial=3 | | example.domain. IN SOA serial=3 |
| JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | | www.example.domain. IN A 10.0.3.1 |
| JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | | www.example.domain. IN A 10.0.2.1 |
| JAIN.AD.JP. IN SOA serial=3 | | example.domain. IN SOA serial=3 |
+---------------------------------------------------+ +---------------------------------------------------+
Authority | <empty> | Authority | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
Additional | <empty> | Additional | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
or, if UDP packet overflow occurs, with the following message: or, if UDP packet overflow occurs, with the following message:
+---------------------------------------------------+ +---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE | Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+ +---------------------------------------------------+
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+ +---------------------------------------------------+
Answer | JAIN.AD.JP. IN SOA serial=3 | Answer | example.domain. IN SOA serial=3 |
+---------------------------------------------------+ +---------------------------------------------------+
Authority | <empty> | Authority | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
Additional | <empty> | Additional | <empty> |
+---------------------------------------------------+ +---------------------------------------------------+
8. Acknowledgements 8. Acknowledgements
The original idea of IXFR was conceived by Anant Kumar, Steve Hotz The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
and Jon Postel. and Jon Postel.
skipping to change at page 8, line 36 skipping to change at page 8, line 50
the members of the IETF DNSEXT working group. the members of the IETF DNSEXT working group.
9. References 9. References
[NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone [NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC1996, August 1996. Changes (DNS NOTIFY)", RFC1996, August 1996.
[STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035), [STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035),
November 1987. November 1987.
[XFRCLARIFY] 10. Appendix A Appendix A. Pseudocode for response classification
The following pseudocode outlines one possible algorithm for
classifying IXFR responses.
10. Security Considerations 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 Though DNS is related to several security problems, no attempt is
made to fix them in this document. made to fix them in this document.
This document is believed to introduce no additional security This document is believed to introduce no additional security
problems to the current DNS protocol. problems to the current DNS protocol.
11. Author's Address 12. Author's Address
Masataka Ohta Masataka Ohta
Computer Center, Tokyo Institute of Technology Computer Center, Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN
Phone: +81-3-5734-3299, Fax: +81-3-5734-3415 Phone: +81-3-5734-3299, Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp EMail: mohta@necom830.hpcl.titech.ac.jp
Comments should be directed to DNSEXT WG <namedroppers@ops.ietf.org>. Comments should be directed to DNSEXT WG <namedroppers@ops.ietf.org>.
12. Full Copyright Statement 13. Full Copyright Statement
"Copyright (C) The Internet Society (March/5/2000). All Rights "Copyright (C) The Internet Society (March/5/2000). All Rights
Reserved. Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/