< draft-ietf-dnsind-ixfr-05.txt		draft-ietf-dnsind-ixfr-06.txt >
	INTERNET DRAFT M. Ohta		INTERNET DRAFT M. Ohta
	draft-ietf-dnsind-ixfr-05.txt Tokyo Institute of Technology		draft-ietf-dnsind-ixfr-06.txt Tokyo Institute of Technology
	January 1996		February 1996
	Incremental Zone Transfer in DNS		Incremental Zone Transfer in DNS
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months. Internet-Drafts may be updated, replaced, or obsoleted by		and may be updated, replaced, or obsoleted by other documents at any
	other documents at any time. It is not appropriate to use Internet-		time. It is inappropriate to use Internet- Drafts as reference
	Drafts as reference material or to cite them other than as a		material or to cite them other than as ``work in progress.''
	``working draft'' or ``work in progress.''
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	1id-abstracts.txt listing contained in the Internet-Drafts Shadow		``1id-abstracts.txt'' listing contained in the Internet- Drafts
	Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or		Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au.		munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
			ftp.isi.edu (US West Coast).
	Abstract		Abstract
	This document proposes extensions to the DNS protocols to provide an		This document proposes extensions to the DNS protocols to provide an
	incremental zone transfer (IXFR) mechanism.		incremental zone transfer (IXFR) mechanism.
	1. Introduction		1. Introduction
	For the quick propagation of changes to a DNS database [STD13], it is		For rapid propagation of changes to a DNS database [STD13], it is
	necessary to reduce latency by actively notifying servers of the		necessary to reduce latency by actively notifying servers of the
	change. This is accomplished by NOTIFY extension of DNS [NOTIFY].		change. This is accomplished by the NOTIFY extension of the DNS
			[NOTIFY].
	The current full zone transfer mechanism (AXFR) is not an efficient		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		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
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	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
	and the differences between that copy and several older versions.		and the differences between that copy and several older versions.
	When an IXFR request with an older version number is received, the		When an IXFR request with an older version number is received, the
	IXFR server needs to send only the differences required to make that		IXFR server needs to send only the differences required to make that
	version current. Alternatively, the server may choose to transfer		version current. Alternatively, the server may choose to transfer
	the entire zone just as in a normal full zone transfer.		the entire zone just as in a normal full zone transfer.
	Upon an update of a zone, new difference information should not be		When a zone has been updated, it should be saved in stable storage
	available until after the updated version is placed in a stable		before the new version is used to respond to IXFR (or AXFR) queries.
	storage. Otherwise, if a server crashes, the effect of IXFR on		Otherwise, if the server crashes, data which is no longer available
	unstable data, which is lost on the server at the crash, will		may have been distributed to secondary servers, which can cause
	persistently survive the following IXFRs on some client, causing		persistent database inconsistencies.
	inconsistency of the database.
	If an IXFR query with the same or newer version number than that of		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 is received, it is replied to with a single SOA record of
	the server's current version, just as in AXFR.		the server's current version, just as in AXFR.
	Transport of a query may be by either UDP or TCP. If an IXFR query		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		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		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		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		record of the server's current version to inform the client that a
	TCP query should be initiated.		TCP query should be initiated.
	Thus, a client should first make an IXFR query using UDP. If the		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		query type is not recognized by the server, an AXFR (preceded by a
	UDP SOA query) should be tried. If the query response is a single		UDP SOA query) should be tried. If the query response is a single
	packet with the entire new zone, or if the server does not have a		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		newer version than the client, everything is done. Otherwise, a TCP
	IXFR query should be tried.		IXFR query should be tried.
	To ensure integrity, servers should use UDP checksums for all UDP		To ensure integrity, servers should use UDP checksums for all UDP
	responses. A cautious client which receives a UDP packet with the		responses. A cautious client which receives a UDP packet with a
	checksum value of zero should ignore the result and try a TCP IXFR		checksum value of zero should ignore the result and try a TCP IXFR
	instead.		instead.
	The query type value of IXFR assigned by IANA is 251.		The query type value of IXFR assigned by IANA is 251.
	3. Query Format		3. Query Format
	The IXFR query packet format is the same as that of a normal DNS		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		query, but with the query type being IXFR and the authority section
	containing the SOA record of client's version of the zone.		containing the SOA record of client's version of the zone.
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 44 ¶
	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.
	5. Purging Strategy		5. Purging Strategy
	An IXFR server can not be required to forever hold all previous		An IXFR server can not be required to hold all previous versions
	versions and may delete them anytime. In general, there is a trade-		forever and may delete them anytime. In general, there is a trade-off
	off between the size of storage space and the possibility of using		between the size of storage space and the possibility of using IXFR.
	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 may also be purged.		Information older than the SOA expire period may also be purged.
	6. Optional Condensation of Multiple Versions		6. Optional Condensation of Multiple Versions
	An IXFR server may optionally condense multiple difference sequences		An IXFR server may optionally condense multiple difference sequences
	into a single difference sequence, thus, dropping information on		into a single difference sequence, thus, dropping information on
	intermediate versions.		intermediate versions.
	The feature may be useful if there are a lot of versions, not all of		This may be beneficial if a lot of versions, not all of which are
	which are so useful, are generated. For example, if multiple ftp		useful, are generated. For example, if multiple ftp servers share a
	servers share a single DNS name and changes an IP address of the name		single DNS name and the IP address associated with the name is
	once per a minutes to balance load between ftp servers, it is not so		changed once a minute to balance load between the ftp servers, it is
	meaningful to keep track of all the history of changes.		not so important to keep track of all the history of changes.
	But, the feature may not be so useful if an IXFR client has access to		But, this feature may not be so useful if an IXFR client has access
	two IXFR servers: A and B, with inconsistent condensation results.		to two IXFR servers: A and B, with inconsistent condensation results.
	The current version of the IXFR client, received from server A, may		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		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		incremental data from the unknown version and a full zone transfer is
	necessary.		necessary.
	The condensation is completely optional.		Condensation is completely optional. Clients can't detect from the
			response whether the server has condensed the reply or not.
	For the interoperability, IXFR servers, including those without the		For interoperability, IXFR servers, including those without the
	condensation feature, should not flag any error even if it receives a		condensation feature, should not flag an error even if it receives a
	client's IXFR request with a unknown version number and should,		client's IXFR request with a unknown version number and should,
	instead, attempt to perform a full zone transfer.		instead, attempt to perform a full zone transfer.
	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. (		JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
	1 600 600 3600000 604800)		1 600 600 3600000 604800)
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 47 ¶
	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		11. Author's Address
	Masataka Ohta		Masataka Ohta
	Computer Center		Computer Center, Tokyo Institute of Technology
	Tokyo Institute of Technology		2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
	2-12-1, O-okayama, Meguro-ku
	Tokyo 152, JAPAN
	Phone: +81-3-5734-3299		Phone: +81-3-5734-3299, Fax: +81-3-5734-3415
	Fax: +81-3-5734-3415
	EMail: mohta@necom830.cc.titech.ac.jp		EMail: mohta@necom830.cc.titech.ac.jp
End of changes. 15 change blocks.
	40 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/