INTERNET-DRAFT Edward Lewis draft-ietf-dnsext-axfr-clarify-09.txt NeuStar, Inc. DNSEXT WG July 2008 Updates: 1034, 1035 (if approved) Intended status: Standards Track DNS Zone Transfer Protocol (AXFR) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 31, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The definition of AXFR, has proven insufficient in detail, forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of the AXFR, new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. 1 Introduction The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. Authoritative Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" [RFC1034] (referred to in this document as RFC 1034) and "Domain Names - Implementation and Specification" [RFC1035] (aka RFC 1035). Incremental Zone Transfer (IXFR) is defined in "Incremental Zone Transfer in DNS" [RFC1995]. A mechanism for prompt notification of zone changes (NOTIFY) is defined in "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of these mechanisms is to enable a set of DNS name servers to remain coherently authoritative for a given zone. Comments on this draft ought to be addressed to the editor or to email@example.com. 1.1 Definition of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [BCP14]. "Newer"/"New" DNS and "older"/"old" DNS refers to implementations written after and prior to the publication of this document. 1.2 Scope In the greater context there are many ways to achieve coherency among a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form just one, the one defined in the RFCs cited. For example, there are DNS implementations that assemble answers from data stored in relational databases (as opposed to master files) relying on the database's non-DNS means to synchronize the database instances. Some of these non-DNS solutions interoperate in some fashion. As far as it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms that provide an interoperable solution to the desire for coherency within the definition of DNS, they certainly are the only mechanisms documented by the IETF. This document does not cover incoherent DNS situations. There are applications of the DNS in which servers for a zone are designed to be incoherent. For these configurations, a coherency mechanism as described here would be unsuitable. "General purpose DNS implementation" refers to DNS software developed for wide-spread use. This includes resolvers and servers freely accessible as libraries and standalone processes. This also includes proprietary implementations used only in support of DNS service offerings. "Turnkey DNS implementation" refers to custom made, single use implementations of DNS. Such implementations consist of software that employs the DNS protocol message format yet do not conform to the entire range of DNS functionality. A DNS implementation is not required to support AXFR, IXFR and NOTIFY. A DNS implementation SHOULD have some means for maintaining name server coherency. A general purpose DNS implementation SHOULD include AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS implementations MAY exist without AXFR. (An editorial note to readers of this section. The mention of IXFR and NOTIFY is for context and illustration, this document does not make any normative comments on those mechanisms.) 1.3 Context Besides describing the mechanisms themselves, there is the context in which they operate to consider. When AXFR, IXFR and NOTIFY were defined, there was little consideration given to security and privacy issues. Since the original definition of AXFR, new opinions have appeared on the access to an entire zone's contents. In this document, the basic mechanisms will be discussed separately from the permission to use these mechanisms. 1.4 Coverage This document concentrates on just the definition of AXFR. Any effort to update the IXFR or NOTIFY mechanisms would be done in different documents. This is not strictly a clarification of the definition in RFC 1034 and RFC 1035. This document will update those sections, and invalidate at least one part of that definition. The goal of this document is to define AXFR as it exists, or is supposed to exist, currently. 1.4 Coverage and Relationship to Original AXFR Specification This document concentrates on just the definition of AXFR. Any effort to update the IXFR or NOTIFY mechanisms would be done in different documents. The original "specification" of the AXFR sub-protocol is scattered through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5 depicts the scenario for which AXFR has been designed. Section 4.3.5 of RFC 1034 describes the zone synchronisation strategies in general and rules for the invocation of a full zone transfer via AXFR; the fifth paragraph of that section contains a very short sketch of the AXFR protocol. Section 3.2.3 of RFC 1035 has assigned the code point for the AXFR QTYPE (see section 2.1.2 below for more details). Section 4.2 of RFC 1035 discusses the transport layer use of DNS and shortly explains why UDP transport is deemed inappropriate for AXFR; the last paragraph of Section 4.2.2 gives details for the TCP connection management with AXFR. Finally, the second paragraph of Section 6.3 in RFC 1035 mandates server behavior when zone data changes occur during an ongoing zone transfer using AXFR. This document will update the specification of AXFR in fully specifying the record formats and processing rules for AXFR, largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing the transport considerations for AXFR, thus amending Section 4.2.2 of RFC 1035. Furthermore, it discusses backward compatibility issues and provides policy/management considerations as well as specific Security Considerations for AXFR. The goal of this document is to define AXFR as it exists, or is supposed to exist, currently. 2 AXFR Messages An AXFR message exchange (or session) consists of an AXFR query message and a set of AXFR response messages. In this document, AXFR client is the sender of the AXFR query and the AXFR server is the responder. (Use of terms such as master, slave, primary, secondary are not important to defining the AXFR exchange.) The reason for the imbalance in number of messages derives from large zones whose contents cannot be fit into the limited permissible size of a DNS message. An important aspect to keep in mind is that the definition of AXFR is restricted to TCP [RFC0793]. The design of the AXFR process has certain inherent features that are not easily ported to UDP [RFC0768]. The basic format of an AXFR message is the DNS message as defined in RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: - "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] - "Domain Name System (DNS) IANA Considerations" [RFC2929] - "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] - "Extension Mechanisms for DNS (EDNS0)" [RFC2671] - "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] - "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] - "Obsoleting IQUERY" [RFC3425] - "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] - "Protocol Modifications for the DNS Security Extensions" [RFC4035] - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] The upper limit on the permissible size of a DNS message over TCP is defined in RFC 1035, section 4.2.2. Unlike DNS messages over UDP, this limit is not changed by EDNS0. Field names used in this document will correspond to the names as they appear in the IANA registry for DNS Header Flags [DNSFLGS]. 2.1 AXFR query An AXFR query is sent by a client whenever there is a reason to ask. This might be because of zone maintenance activities or as a result of a command line request, say for debugging. 2.1.1 Header Values These are the DNS message header values for an AXFR query. ID See note 2.1.1.a QR MUST be 0 (Query) OPCODE MUST be 0 (Standard Query) AA See note 2.1.1.b TC See note 2.1.1.b RD See note 2.1.1.b RA See note 2.1.1.b Z See note 2.1.1.c AD See note 2.1.1.b CD See note 2.1.1.b RCODE MUST be 0 (No error) QDCOUNT MUST be 1 ANCOUNT MUST be 0 NSCOUNT MUST be 0 ARCOUNT See note 2.1.1.d Note 2.1.1.a Set to any value that the client is not already using with the same server. There is no specific means for selecting the value in this field. (Recall that AXFR is done only via TCP connections.) A server MUST reply using messages that use the same message ID to allow a client to meaningfully have multiple AXFR queries outstanding. Note 2.1.1.b The value in this field has no meaning in the context of AXFR query messages. For the client, it is RECOMMENDED that the value be zero. The server MUST ignore this value. Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore it. Note 2.1.1.d The client MUST set this field to be the number of resource records appearing in the additional section. See Section 2.1.5 "Additional Section" for details. The value MAY be 0, 1 or 2. If it is 2, the additional section MUST contain both an EDNS0 [RFC2671] OPT resource record and a record carrying transaction integrity and authentication data, currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the value is 1, then the additional section MUST contain either only an EDNS0 OPT resource record or a record carrying transaction integrity and authentication data. If the value is 0, the additional section MUST be empty. 2.1.2 Query Section The Query section of the AXFR query MUST conform to section 4.1.2 of RFC 1035, and contain the following values: QNAME the name of the zone requested QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS] QCLASS the class of the zone requested 2.1.3 Answer Section MUST be empty. 2.1.4 Authority Section MUST be empty. 2.1.5 Additional Section The client MAY include an EDNS0 OPT [RFC2671] resource record. If the server has indicated that it does not support EDNS0, the client MUST send this section without an EDNS0 OPT resource record if there is a retry. Indication that a server does not support EDNS0 is not an explicit element in the protocol, it is up to the client to interpret. Most likely, the server will return a FORMERR which might be related to the OPT resource record. The client MAY include a transaction integrity and authentication resource record, currently a choice of TSIG [RFC2845] or SIG(0) [RFC2931]. If the server has indicated that it does not recognize the resource record, and that the error is indeed caused by the resource record, the client probably ought not try again. Removing the security data in the face of an obstacle ought to only be done with full awareness of the implication of doing so. In general, if an AXFR client is aware that an AXFR server does not support a particular mechanism, the client SHOULD NOT attempt to engage the server using the mechanism (or at all). A client could become aware of a server's abilities via a configuration setting or via some other (as yet) undefined means. The range of permissible resource records that MAY appear in the additional section might change over time. If either a change to an existing resource record (like the OPT RR for EDNS0) is made or a new additional section record is created, the new definitions ought to include a discussion on the impact upon AXFR. Although this is not predictale, future additional section residing records may have an effect that is orthogonal to AXFR, so can ride through the session as opaque data. In this case, a "wise" implementation ought to be able to pass these records through without disruption. 2.2 AXFR response The AXFR response will consist of 0 or more messages. A "0 message" response is covered in section 2.2.1. An AXFR response that is transferring the zone's contents will consist of a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the SOA resource record of the zone, the last message MUST conclude with the same SOA resource record. Intermediate messages MUST NOT contain the SOA resource record. The first message MUST copy the Query Section from the corresponding AXFR query message in to the first response message's query section. Subsequent messages MAY do the same. An AXFR response that is indicating an error MUST consist of a single DNS message with the return code set to the appropriate value for the condition encountered - once the error condition is detected. Such a message MUST copy the AXFR query Query Section into its Query Section. The inclusion of the terminating SOA resource record is not necessary. An AXFR client might receive a number of AXFR response messages free of an error condition before the message indicating an error is received. But once an error is reported, the AXFR client can assume that the error reporting message is the last. 2.2.1 "0 Message" Response A legitimate "0 message" response, i.e., the client sees no response whatsoever, is very exceptional and controversial. Unquestionably it is unhealthy for there to be 0 responses in a protocol that is designed around a query - response paradigm over an unreliable transport. The lack of a response could be a sign of underlying network problems and cause the protocol state machine to react accordingly. However, AXFR uses TCP and not UDP, eliminating undetected network errors. A "0 message response" is reserved for situations in which the server has a reason to suspect that the query is sent for the purpose of abuse. Due to the use of this being so controversial, a "0 message response" is not being defined as a legitimate part of the protocol but the use of it is being acknowledge as a warning to AXFR client implementations. Any earnest query has the expectation of some response but may not get one. If an AXFR client sends a query on a TCP connection and the connection is closed at any point, the AXFR client MUST consider the session terminated. The message ID MAY be used again on a new connection, even if the question and AXFR server are the same. Facing a dropped connection a client SHOULD try to make some determination whether the connection closure was the result of network activity or a decision by the AXFR server. This determination is not an exact science. It is up to the AXFR client implementor to react, but the reaction SHOULD NOT be an endless cycle of retires nor an increasing (in frequency) retry rate. An AXFR server implementor SHOULD take into consideration what this dilemma described above when a connection is closed with an outstanding query in the pipeline. For this reason, a server ought to reserve this course of action for situations in which it believes beyond a doubt that the AXFR client is attemping abusive behavior. 2.2.2 Header Values ID See note 2.2.2.a QR MUST be 1 (Response) OPCODE MUST be 0 (Standard Query) AA See note 2.2.2.b TC MUST be 0 (Not truncated) RD RECOMMENDED copy request's value, MAY be set to 0 RA See note 2.2.2.c Z See note 2.2.2.d AD See note 2.2.2.e CD See note 2.2.2.e RCODE See note 2.2.2.f QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all following ANCOUNT See note 2.2.2.g NSCOUNT MUST be 0 ARCOUNT See note 2.2.2.h Note 2.2.2.a Because some old implementations behave differently than is now desired, the requirement on this field is stated in detail. New DNS servers MUST set this field to the value of the AXFR query ID in each AXFR response message for the session. AXFR clients MUST be able to manage sessions resulting from the issuance of multiple outstanding queries, whether AXFR queries or other DNS queries. A client SHOULD discard responses that do not correspond (via the message ID) to any outstanding queries. Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone transfer. A client MAY become aware of a server's abilities via a configuration setting. Note 2.2.2.b If the RCODE is 0 (no error), then the AA bit MUST be 1. For any other value of RCODE, the AA bit MUST be set according to rules for that error code. If in doubt, it is RECOMMENDED that it be set to 1. It is RECOMMENDED that the value be ignored by the AXFR client. Note 2.2.2.c It is RECOMMENDED that the server set the value to 0, the client MUST ignore this value. The server MAY set this value according to the local policy regarding recursive service, but doing so might confuse the interpretation of the response as AXFR can not be retrieved recursively. A client MAY note the server's policy regarding recursive service from this value, but SHOULD NOT conclude that the AXFR response was obtained recursively even if the RD bit was 1 in the query. Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore it. Note 2.2.2.e If the implementation supports the DNS Security Extensions (see below) then this value MUST be set according to the rules in RFC 4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response". If the implementation does not support the DNS Security Extensions, then this value MUST be set to 0 and MUST be ignored upon receipt. The DNS Security Extensions (DNSSEC) is defined in these base documents: - "DNS Security Introduction and Requirements" [RFC4033] - "Resource Records for the DNS Security Extensions" [RFC4034] - "Protocol Modifications for the DNS Security Extensions" [RFC4035] Note 2.2.2.f In the absence of an error, the server MUST set the value of this field to NoError. If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth. (Reminder, consult the appropriate IANA registry [DNSVALS].) If a client receives any other value in response, it MUST act according to the error. For example, a malformed AXFR query or the presence of an EDNS0 OPT resource record sent to an old server will garner a FormErr value. This value is not set as part of the AXFR response processing. The same is true for other error-indicating values. Note 2.2.2.g The count of answer records MUST equal the number of resource records in the AXFR Answer Section. When a server is aware that a client will only accept one resource record per response message, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data. Note 2.2.2.h The client MUST set this field to be the number of resource records appearing in the additional section. See Section 2.1.5 "Additional Section" for details. 2.2.3 Query Section In the first response message, this section MUST be copied from the query. In subsequent messages this section MAY be copied from the query, MAY be empty. The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transferred. 2.2.4 Answer Section MUST be populated with the zone contents. See later section on encoding zone contents. 2.2.5 Authority Section MUST be empty. 2.2.5 Additional Section The contents of this section MUST follow the guidelines for EDNS0, TSIG, SIG(0), or what ever other future record is possible here. The contents of section 2.1.5 apply here as well. Note that TSIG and SIG(0), if in use, will treat each individual AXFR response message within a session as a unit of data. That is, each message will have a TSIG or SIG(0) (if in use) and the crytpographic check will cover just that message. The same rule will apply to future alternatives and documents covering them ought to consider the impact on AXFR response messages. 3 Zone Contents The objective of the AXFR session is to request and transfer the contents of a zone. The objective is to permit the client to reconstruct the zone as it exists at the server for the given zone serial number. Over time the definition of a zone has evolved from a static set of records to a dynamically updated set of records to a continually regenerated set of records. 3.1 Records to Include In the answer section of AXFR response messages the resource records within a zone for the given serial number MUST appear. The definition of what belongs in a zone is described in RFC 1034, Section 4.2, "How the database is divided into zones", and in particular, section 4.2.1, "Technical considerations". Unless the AXFR server knows that the AXFR client expects just one resource record per AXFR response message, an AXFR server SHOULD populate an AXFR response message with as many complete resource records as will fit within a DNS message. Zones for which it is impractical to list the entire zones for a serial number (because changes happen too quickly) are not suitable for AXFR retrieval. 3.2 Delegation Records In RFC 1034, section 4.2.1, this text appears (keep in mind that the "should" in the quotation predates [BCP14], cf. section 1.1) "The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone." There has been some controversy over this statement and the impact on which NS resource records are included in a zone transfer. The phrase "that describe cuts" is a reference to the NS set and applicable glue records. It does not mean that the cut points and the apex resource records are identical. For example, the SOA resource record is only found at the apex, as well as a slew of DNSSEC resource records. There are also some DNSSEC resource record sets that are explicitly different between the cut point and the apex. The discussion here is restricted to just the NS resource record set and glue as these "describe cuts." The issue is that in operations there are times when the NS resource records for a zone might be different at a cut point in the parent and at the apex of a zone. Sometimes this is the result of an error and sometimes it is part of an ongoing change in name servers. The DNS protocol is robust enough to overcome inconsistencies up to (but not including) there being no parent indicated NS resource record referencing a server that is able to serve the child zone. This robustness is one quality that has fueled the success of the DNS. Still, the inconsistency is a error state and steps need to be taken to make it apparent (if it is unplanned) and to make it clear once the inconsistency has been removed. Another issue is that the AXFR server could be authoritative for a different set of zones than the AXFR client. It is possible that the AXFR server be authoritative for both halves of an inconsistent cut point and that the AXFR client is authoritative for just the parent of the cut point. The question that arises is, when facing a situation in which a cut point's NS resource records do not match the authoritative set, whether an AXFR server responds with the NS resource record set that is in the zone or is at the authoritative location. The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set or not. "Registered with" can be widely interpreted to include data residing in the zone file of the zone for the particular serial number (in zone file environments) or as any data configured to be in the zone (database), statically or dynamically. The reasons for this requirement are: 1) The AXFR server might not be able to determine that there is an inconsistency given local data, hence requiring consistency would mean a lot more needed work and even network retrieval of data. An authoritative server ought not be required to perform any queries. 2) By transferring the inconsistent NS resource records from a server that is authoritative for both the cut point and the apex to a client that is not authoritative for both, the error is exposed. For example, an authorized administrator can manually request the AXFR and inspect the results to see the inconsistent records. (A server authoritative for both halves would otherwise always answer from the more authoritative set, concealing the error.) 3) The inconsistent NS resource record set might indicate a problem in a registration database. 4) Beginning with an error state of two servers for a zone having inconsistent zone contents for a given zone serial number, if a client requests and recieves an IXFR transfer from one server followed by another IXFR transfer from the other server, the client can encounter an IXFR protocol error state where an attempt is made to incrementally add a record that already exists or to delete a record that does not exist. (Editorial note, the 4th reason was suggested, but I don't see how it relates. A nudge for updated text on this.) 3.3 Glue Records As quoted in the previous section, RFC 1034, section 4.2.1, provides guidance and rationale for the inclusion of glue records as part of an AXFR transfer. And, as also argued in the previous section of this document, even when there is an inconsistency between the address in a glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is to be included. This applies for glue records for any address family. The AXFR response MUST contain the appropriate glue records as registered with the zone. The interpretation of "registered with" in the previous section applies here. Inconsistent glue records are an operational matter. 3.4 Name Compression Compression of names in DNS messages is described in RFC 1035, section 4.1.4, "Message compression". The issue highlighted here relates to a comment made in RFC 1034, section 3.1, "Name space specifications and terminology" which says "When you receive a domain name or label, you should preserve its case." ("Should" in the quote predates [BCP14].) Name compression in an AXFR message MUST preserve the case of the original domain name. That is, although when comparing a domain name, "a" equals "A", when comparing for the purposes of message compression, "a" is not equal to "A". Note that this is not the usual definition of name comparison in the DNS protocol and represents a new requirement on AXFR servers. Rules governing name compression of RDATA in an AXFR message MUST abide by the specification in "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597], specifically, section 4 on "Domain Name Compression." 3.5 Occluded Names Dynamic Update [RFC2136] (and including DNAME ) operations can have a side effect of occluding names in a zone. The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, still part of the zone but not available for to the look up process. The addition of a DNAME resource record set has the same impact. The subordinate names are said to be "occluded." Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. The rationale for this action is based on a speedy recovery if the dynamic update operation was in error and is to be undone. 4 Transport AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC 1034 that states: "Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests." The most common scenario is for an AXFR client to open a TCP connection to the AXFR server, send an AXFR query, receive the AXFR response, and then close the connection. There are variations on this, such as a query for the zone's SOA resource record first, and so on. Two issues have emerged since the original specification of AXFR. One is that lack of specificity has yielded some implementations that assume the TCP connection is dedicated to the single AXFR session, which has led to implementation choices that prevent either multiple concurrent zone transfers or the use of the open connection for other queries. The other issue is the prospect of using UDP as a transport has come to look promising because of trends in the past two decades. Being able to have multiple concurrent zone transfers is considered desirable by operators who have sets of name servers that are authoritative for a common set of zones. It would be desirable if the name server implementations did not have to wait for one zone to transfer before the next could begin. The desire here is to tighten the specification, not a change, but adding words to the unclear areas, to define what is needed to permit two servers to share a TCP connection among concurrent AXFR sessions. The challenge is to design this in a way that can fall back to the old behavior if either the AXFR client or AXFR server is incapable of performing multiple concurrent AXFR sessions. With the addition of EDNS0 and applications which require many small zones such as in web hosting and some ENUM scenarios, AXFR sessions on UDP are now possible and desirable. However, there are still some aspects of the AXFR session that are not easily translated to UDP. This document leaves AXFR over UDP undefined. 4.1 TCP In the original definition there is an implicit assumption (probably unintentional) that a TCP connection is used for one and only one AXFR session. This is evidenced in no requirement to copy neither the Query Section nor the message ID in responses, no explicit ordering information within the AXFR response messages and the lack of an explicit notice indicating that a zone transfer continues in the next message. The guidance given here is intended to enable better performance of the AXFR exchange as well as guidelines on interactions with older software. Better performance includes being able to multiplex DNS message exchanges including zone transfer sessions. Guidelines for interacting with older software are generally applicable to AXFR clients as reversing the situation, older AXFR client and newer AXFR server ought to induce the server to operate within the specification for an older server. 4.1.1 AXFR client TCP An AXFR client MAY request an connection to an AXFR server for any reason. An AXFR client SHOULD close the connection when there is no apparent need to use the connection for some time period. The AXFR server ought not have to maintain idle connections, the burden of connection closure ought to be on the client. Apparent need for the connection is a judgement for the AXFR client and the DNS client. If the connection is used for multiple sessions, or it is known sessions will be coming or is there is other query/response traffic on the open connection, that is "apparent need." An AXFR client MAY cancel delivery of a zone only by closing the connection. However, this action will also cancel all other outstanding activity using the connection. There is no other mechanism by which an AXFR response can be cancelled. When a TCP connection is closed remotely (relative to the client), whether by the AXFR server or due to a network event, the AXFR client MUST cancel all outstanding sessions. Recovery from this situation is not straightforward. If the disruption was a spurious event, attempting to restart the connection would be proper. If the disruption was caused by a medium or long term disruption, the AXFR client would be wise to not spend too many resources trying to rebuild the connection. Finally, if the connection was dropped because of a policy at the AXFR server (as can be the case with older AXFR servers), the AXFR client would be wise to not retry the connection. Unfortunately, knowing which of the three cases above applies is not clear (momentary disruption, failure, policy). An AXFR client MAY use an already opened TCP connection to start an AXFR session. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-AXFR session traffic can also use an open connection.) If in doing so the AXFR client realizes that the responses cannot be properly differentiated (lack of matching query IDs for example) or the connection is terminated for a remote reason, then the AXFR client SHOULD not attempt to reuse an open connection with the specific AXFR server until the AXFR server is updated (which is of course, not an event captured in the DNS protocol). 4.1.2 AXFR server TCP An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as handle other query/response sessions. If a TCP connection is closed remotely, the AXFR server MUST cancel all AXFR sessions in place. No retry activity is necessary, that is initiated by the AXFR client. Local policy MAY dictate that a TCP connection is to be closed. Such as action SHOULD be in reaction to limits such as those placed on the number of outstanding open connections. Closing a connection in response to a suspected security event SHOULD be done only in extreme cases, when the server is certain the action is warranted. An isolated request for a zone not on the AXFR server SHOULD receive a response with the appropriate return code and not see the connection broken. 4.2 UDP AXFR sessions over UDP transport are not defined. 5 Authorization A zone administrator has the option to restrict AXFR access to a zone. This was not envisioned in the original design of the DNS but has emerged as a requirement as the DNS has evolved. Restrictions on AXFR could be for various reasons including a desire (or in some instances, having a legal requirement) to keep the bulk version of the zone concealed or to prevent the servers from handling the load incurred in serving AXFR. All reasons are arguable, but the fact remains that there is a requirement to provide mechanisms to restrict AXFR. A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients. By default, a DNS implementation SHOULD only allow the designated authoritative servers to have access to the zone. An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed. Combining this with techniques such as Virtual Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be effective. A general purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931]. A general purpose implementation SHOULD allow access to be open to all AXFR requests. I.e., an operator ought to be able to allow any AXFR query to be granted. A general purpose implementation SHOULD NOT have a default policy for AXFR requests to be "open to all." 6 Zone Integrity Ensuring that an AXFR client does not accept a forged copy of a zone is important to the security of a zone. If a zone operator has the opportunity, protection can be afforded via dedicated links, physical or virtual via a VPN among the authoritative servers. But there are instances in which zone operators have no choice but to run AXFR sessions over the global public Internet. Besides best attempts at securing TCP sessions, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents. These techniques MAY also be used for authorization. 7 Backwards Compatibility Describing backwards compatibility is difficult because of the lack of specifics in the original definition. In this section some hints at building in backwards compatibility are given, mostly repeated from the earlier sections. Backwards compatibility is not necessary, but the greater extent of an implementation's compatibility increases it's interoperability. For turnkey implementations this is not usually a concern. For general purpose implementations this takes on varying levels of importance depending on the implementer's desire to maintain interoperability. It is unfortunate that a need to fall back to older behavior cannot be discovered, hence needs to be noted in a configuration file. An implementation SHOULD, in it's documentation, encourage operators to periodically review AXFR clients and servers it has made notes about as old software periodically gets updated. 7.1 Server An AXFR server has the luxury of being able to react to an AXFR client's abilities with the exception of knowing if the client can accept multiple resource records per AXFR response message. The knowledge that a client is so restricted apparently cannot be discovered, hence it has to be set by configuration. An implementation of an AXFR server SHOULD permit configuring, on a per AXFR client basis, a need to revert to single resource record per message. The default SHOULD be to use multiple records per message. 7.2 Client An AXFR client has the opportunity to try extensions when querying an AXFR server. Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be aborted if it interrupts the original request and SHOULD take into consideration whether the AXFR server intends to close the connection immediately upon completion of the original (connection-causing) zone transfer. 8 Security Considerations Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (section 5), "TCP" (section 4.2) and Zone Integrity (section 6). 9 IANA Considerations No new registries or new registrations are included in this document. 10 Internationalization Considerations It is assumed that supporting of international domain names has been solved via "Internationalizing Domain Names in Applications (IDNA)" [RFC3490]. 11 Acknowledgements Earlier editions of this document have been edited by Andreas Gustafsson. In his latest version, this acknowledgement appeared. "Many people have contributed input and commentary to earlier versions of this document, including but not limited to Bob Halley, Dan Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, and Brian Wellington." Comments since the -05 version have come from these individuals: Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, ... 12 References All references prefixed by "RFC" can be obtained from the RFC Editor, information regarding this organization can be found at the following URL: http://rfc-editor.org/ Additionally, these documents can be obtained via the IETF web site. 12.1 Normative [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, August 2006. [DNSFLGS] http://www.iana.org/assignments/dns-header-flags [DNSVALS] http://www.iana.org/assignments/dns-parameters 12.2 Informative [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. 13 Editor's Address Edward Lewis 46000 Center Oak Plaza Sterling, VA, 22033, US +1-571-434-5468 firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).