ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsDNSext Working Group O. Sury
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft CZ.NIC
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsUpdates: 1995 (if approved) S. Kerr, Ed.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsIntended status: Standards Track ISC
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsExpires: August 30, 2010 February 26, 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR-ONLY to Prevent IXFR Fallback to AXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews draft-kerr-ixfr-only-01
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews This documents proposes a new QTYPE (Query pseudo RRtype) for the
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Domain Name System (DNS). IXFR-ONLY is a variant of IXFR (RFC 1995)
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews that allows an authoritative server to incrementally update zone
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews content from another (primary) server without falling back from IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews to AXFR. This way, alternate peers can be contacted more quickly and
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews convergence of zone content may be achieved much faster in important,
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews resilient operational scenarios.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsStatus of this Memo
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews This Internet-Draft is submitted to IETF in full conformance with the
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews provisions of BCP 78 and BCP 79.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Internet-Drafts are working documents of the Internet Engineering
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Task Force (IETF), its areas, and its working groups. Note that
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews other groups may also distribute working documents as Internet-
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Internet-Drafts are draft documents valid for a maximum of six months
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews and may be updated, replaced, or obsoleted by other documents at any
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews time. It is inappropriate to use Internet-Drafts as reference
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews material or to cite them other than as "work in progress."
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews The list of current Internet-Drafts can be accessed at
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews The list of Internet-Draft Shadow Directories can be accessed at
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews This Internet-Draft will expire on August 30, 2010.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsCopyright Notice
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Copyright (c) 2010 IETF Trust and the persons identified as the
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews document authors. All rights reserved.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 1]
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft IXFR-ONLY February 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews This document is subject to BCP 78 and the IETF Trust's Legal
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Provisions Relating to IETF Documents
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews (http://trustee.ietf.org/license-info) in effect on the date of
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews publication of this document. Please review these documents
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews carefully, as they describe your rights and restrictions with respect
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews to this document. Code Components extracted from this document must
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews include Simplified BSD License text as described in Section 4.e of
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews the Trust Legal Provisions and are provided without warranty as
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews described in the BSD License.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsTable of Contents
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 2. IXFR Server Side . . . . . . . . . . . . . . . . . . . . . . . 4
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 3. IXFR Client Side . . . . . . . . . . . . . . . . . . . . . . . 4
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 4. Applicability of IXFR-ONLY . . . . . . . . . . . . . . . . . . 5
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 2]
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft IXFR-ONLY February 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews1. Introduction
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews For large DNS zones, RFC 1995 [RFC1995] defines Incremental Zone
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Transfer (IXFR), which allows only to transfer the changed portion(s)
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews In the document, an IXFR client and an IXFR server is defined as in
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews RFC 1995 [RFC1995], a secondary name server which requests IXFR is
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews called an IXFR client and a primary or secondary name server which
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews responds to the request is called an IXFR server.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR is an efficient way to transfer changes in zones from IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews servers to IXFR clients. However, when an IXFR client has multiple
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR servers for a single zone, it is possible that not all IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews servers have the zone with same serial number for that zone. In this
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews case, if an IXFR client attempts an IXFR from an IXFR server which
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews does not have zone with the serial number used by the IXFR client,
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews the IXFR server will fall back to a full zone transfer (AXFR) when it
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews has a version of the zone with serial number greater than the serial
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews requested by the IXFR client.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews For example, IXFR server NS1 may have serial numbers 1, 2, and 3 for
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews a zone, and IXFR server NS2 may have serial numbers 1 and 3 for the
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews same zone. An IXFR client that has the zone with serial number 2
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews which sends an IXFR request to IXFR server NS2 will get a full zone
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews transfer (AXFR) of the zone at serial number 3. This is because NS2
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews does not know the zone with serial number 2, and therefore does not
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews know what the differences are between zone with serial number 2 and
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR client in this example had known to send the query to
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR server NS1, then it could have gotten an incremental transfer
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews (IXFR). But IXFR clients can only know what the latest version of
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews the zone is at a IXFR server (this information is available via an
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews The IXFR-ONLY query type provides a way for the IXFR client to ask
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews each IXFR server to return an error instead of sending the current
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews version of the zone via full zone transfer (AXFR). By using this, a
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR client can check each IXFR server until it finds one able to
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews provide IXFR.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews1.1. Requirements Language
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews document are to be interpreted as described in RFC 2119 [RFC2119].
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 3]
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft IXFR-ONLY February 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews2. IXFR Server Side
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews A IXFR server receiving a DNS message requesting IXFR-ONLY will reply
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews as described in RFC 1995 [RFC1995] if it is able to produce an IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews for the serial number requested.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR server is is not able to reply with an IXFR it MUST NOT
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews reply with an AXFR unless AXFR result is smaller than IXFR result.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Instead, it MUST reply with RCODE CannotIXFR. (!FIXME)
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR result is larger than an AXFR, then an IXFR server MAY
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews reply with an AXFR result instead. This is an optimization, and IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews servers MAY only reply with AXFR if they are certain that the reply
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews using AXFR is smaller than an equivalent IXFR reply.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews3. IXFR Client Side
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews An IXFR client who wishes to use IXFR-ONLY will send a message to one
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews of the IXFR servers. The format is exactly the same as for IXFR,
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews except the IXFR-ONLY QTYPE code is used instead of the IXFR QTYPE
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR server replies with IXFR, then the IXFR client is done.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR server replies with an RCODE of CannotIXFR, then the IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews client proceeds on to a different IXFR server. In this case the IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews server implements IXFR-ONLY, but does not have information about zone
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews with the serial number requested.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR server replies with any RCODE other than CannotIXFR or
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews NoError, then the IXFR client proceeds on to a different IXFR server.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews In this case the IXFR server does not implement IXFR-ONLY.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If the IXFR client attempts IXFR-ONLY to each IXFR server and none of
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews them reply with an incremental transfer (IXFR), then it should
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews attempt an IXFR as described in RFC 1995 [RFC1995] to each of the
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR servers which replied with an RCODE other than CannotIXFR or
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews The method described above allows IXFR clients to operate normally in
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews situatians where some of the IXFR servers do support IXFR-ONLY, and
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews some who do not. IXFR clients MAY remember which IXFR servers
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews support IXFR-ONLY and query those IXFR servers first. However since
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR servers may change software or even run a mix of software, IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews clients MUST attempt to query each IXFR server periodically when they
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews attempt to get new versions of a zone.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 4]
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft IXFR-ONLY February 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews given IXFR server, if this is known in advance. These IXFR servers
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews are treated as if they replied with an RCODE other than CannotIXFR or
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews NoError, although no query with IXFR-ONLY is actually sent.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews4. Applicability of IXFR-ONLY
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Implementations SHOULD allow IXFR clients to disable IXFR-ONLY
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Implementations MAY allow IXFR clients to disable IXFR-ONLY for a
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews specific zone. This may be useful for small zones, where fallback to
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews AXFR is cheap, or in other cases where IXFR-ONLY is causing problems.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Usage of IXFR-ONLY may cause IXFR clients to prefer particular IXFR
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews servers, by shifting load to ones that support IXFR-ONLY. If this a
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews problem, then administrators can disable IXFR-ONLY in implementations
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews that allow it.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews If a IXFR client has a single IXFR server for a zone, it SHOULD use
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR rather than IXFR-ONLY.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews5. IANA Considerations
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IANA allocates the new IXFR-ONLY QTYPE, which means "incremental
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews transfer only". IANA allocates the CannotIXFR RCODE, which means
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews "Server cannot provide IXFR for zone".
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews6. Security Considerations
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews IXFR-ONLY may be used by someone to get information about the state
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews of IXFR servers by providing a quick and efficient way to check which
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews versions of a zone each IXFR server supports. Zones should be
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews secured via TSIG [RFC2845] to prevent unauthorized information
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews exposure. However, even administrators of IXFR servers may not want
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews this information given to IXFR clients, in which case they will need
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews to disable IXFR-ONLY.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews7. Normative References
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews August 1996.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 5]
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsInternet-Draft IXFR-ONLY February 2010
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Requirement Levels", BCP 14, RFC 2119, March 1997.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Wellington, "Secret Key Transaction Authentication for DNS
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews (TSIG)", RFC 2845, May 2000.
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsAuthors' Addresses
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 120 00 Praha 2
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Phone: +420 222 745 110
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Email: ondrej.sury@nic.cz
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Shane Kerr (editor)
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Bennebrokestraat 17-I
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews 1015 PE Amsterdam
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Phone: +31 64 6336297
ac0680e9ebb2dc4235e4381232c457876fae792fMark Andrews Email: shane@isc.org
ac0680e9ebb2dc4235e4381232c457876fae792fMark AndrewsSury & Kerr Expires August 30, 2010 [Page 6]