From: Automatic Updater Date: Wed, 9 Dec 2009 01:22:47 +0000 (+0000) Subject: sync X-Git-Tag: v9.4-ESVrc1~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=67e991fadf577296466c57018b1fb753b96db8bf;p=thirdparty%2Fbind9.git sync --- diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt deleted file mode 100644 index 5278587ddb3..00000000000 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt +++ /dev/null @@ -1,1058 +0,0 @@ -DNS Extensions Working Group Edward Lewis -INTERNET-DRAFT NeuStar, Inc. -Expires: Octopber 1, 2009 April 2009 -Updates: 1034, 1035 (if approved) -Intended status: Standards Track - - DNS Zone Transfer Protocol (AXFR) - draft-ietf-dnsext-axfr-clarify-11.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and 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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on October 1, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with - respect to this document. - -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 -namedroppers@ops.ietf.org. - -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 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 synchronization 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 5.5 of RFC 2181 has corrected a significant -flaw in that specification. 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 session consists of an AXFR query message and the sequence of -AXFR response messages returned for it. In this document, the 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 AXFR.) The use of the word "session" -without qualification refers to an AXFR session. - -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" [RFC5395] -- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] -- "Clarifications to the DNS Specification" [RFC2181] -- "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] -- "Resource Records for the DNS Security Extensions" [RFC4034] -- "Protocol Modifications for the DNS Security Extensions" [RFC4035] -- "Use of SHA-256 in DNSSEC ... (DS) ... (RRs)" [RFC4509] -- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] -- "... (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155] - -For completeness, the following, in process, documents contain -information about the DNS message. These documents ought not interfere -with AXFR but these documents are helpful in understanding what will -be carried via AXFR. - -- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [DRAFT1] -- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2] - -The upper limit on the permissible size of a DNS message over TCP is -only restricted by the TCP framing defined in RFC 1035, section 4.2.2 -which specifies a two-octet message length field, understood to be -unsigned, and thus causing a limit of 65535 octets. Unlike DNS -messages over UDP, this limit is not changed by EDNS0. - -Note that the TC (truncation) bit is never set by an AXFR server nor -considered/read by an AXFR client. - -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. - -An AXFR query is sent by a client whenever there is a reason to ask. -This might be because of scheduled or triggered zone maintenance -activities (see section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], -respectively) 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 -predictable, 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 terminate the AXFR session; it MUST copy the Query -Section from the AXFR query into its Query Section, but 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. - -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 undetectable 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 acknowledged as a warning to AXFR client -implementations. Any earnest query has the expectation of some -response but may not get one. - -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] -- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] -- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] - -as well pending documents, such as these: - -- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [DRAFT1] -- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2] - -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-specific 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. The -considerations in Note 2.1.1.d above apply equally; see Section -2.2.6 "Additional Section" below for more 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 or it 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.6 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. - -2.3 TCP Connection Aborts - -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 AXFR 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 retries nor an increasing (in -frequency) retry rate. - -An AXFR server implementor SHOULD take into consideration the 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 attempting abusive behavior. - -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 AXFR 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 -denoting a static set of records to also cover a dynamically updated -set of records, and then a potentially continually regenerated set of -records as well. - -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", in particular, section 4.2.1, -"Technical considerations", and it has been clarified in Section 6 of -RFC 2181. - -Unless the AXFR server knows that the AXFR client is old and expects -just one resource record per AXFR response message, an AXFR server -SHOULD populate an AXFR response message with as many complete -resource record sets as will fit within a DNS message. - -Zones for which it is impractical to list the entire zones for a serial -number are not suitable for AXFR retrieval. A typical (but not -limiting) description of such a zone is a zone consisting of responses -generated via other database lookups and/or computed based upon ever -changing data. - -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 point and apex -resource records are identical. For example, the SOA resource record -is only found at the apex. The discussion here is restricted to just -the NS resource record set and glue as these "describe cuts". - -DNSSEC resource records have special specifications regarding their -occurrence at a zone cut and the apex of a zone. This has for the -first time been described in Sections 5.3 ff. and 6.2 of RFC 2181 -(for the initial specification of DNSSEC), which now is historical. -The current DNSSEC core document set (see Note 2.2.2.e above) gives -the full details for DNSSEC(bis) resource record placement, and -Section 3.1.5 of RFC 4035 normatively specifies their treatment during -AXFR; the alternate NSEC3 resource record defined later in RFC 5155 -behaves identically as the NSEC RR, for the purpose of AXFR. - -Informally: -o The DS RRSet only occurs at the parental side of a zone cut and is - authoritative data in the parent zone, not the secure child zone. -o The DNSKEY RRSet only occurs at the APEX of a signed zone and is - authoritative part of the zone it serves. -o Independent RRSIG RRSets occur at the signed parent side and of a - zone cut and at the apex of a signed zone; they are authoritative - part of the respective zone; simple queries for RRSIG resource - records may return bth RRSets at once if the same server is - authoritative for the parent zone and the child zone (Section - 3.1.5 of RFC 4035 describes how to distinguish these RRs); this - seeming ambiguity does not occur for AXFR, since each such RRSIG - RRset belongs to a single zone. -o Different NSEC [RFC4034] or NSEC3 [RFC5155] resource records - equally may occur at the parental siede of a zone cut and at the - apex of a zone; each such resource record belongs to exactly one - of these zones and is to be included in the AXFR of that zone. - -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 an 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 being transferred 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) This requirement is necessary to ensure that retrieving a given -(zone,serial) pair by AXFR yields the exact same set of resource -records no matter which of the zone's authoritative servers is -chosen as the source of the transfer. - -If an AXFR server were allowed to respond with the authoritative -NS RRset of a child zone instead of a glue NS RRset in the zone -being transferred, the set of records returned could vary depending -on whether or not the server happens to also be authoritative for -the child zone. - -The property that a given (zone,serial) pair corresponds to a -single, well-defined set of records is necessary for the correct -operation of incremental transfer protocols such as IXFR -[RFC1995]. For example, a client may retrieve a zone by AXFR from -one server, and then apply an incremental change obtained by IXFR -from a different server. If the two servers have different ideas -of the zone contents, the client can end up attempting to -incrementally add records that already exist or to delete records -that do not exist. - -3.3 Glue Records - -As quoted in the previous section, section 4.2.1 of RFC 1034 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 to glue records for any address family [RFC1700]. - -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] operations, and in particular its interaction -with DNAME [RFC2672], 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 to the lookup process. The addition of a -DNAME resource record 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 restriction to -TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet -Hosts - Application and Support" [RFC1123]. - -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. Note that -this is documented as a most common scenario. - -The assumption that a TCP connection is dedicated to the single AXFR -session is incorrect, this has led to implementation choices that -prevent either multiple concurrent zone transfers or the use of the -open connection for other queries. - -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 would now be possible and seem 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 new AXFR -clients. In the reverse 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 a 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 judgment for the AXFR client and the DNS -client. If the connection is used for multiple sessions, or if it is -known sessions will be coming or if there is other query/response -traffic anticipated or currently on the open connection, then there -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 and non-AXFR transactions. -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 -(momentary disruption, failure, policy) applies is not possible with -certainty, and can only be assessed by heuristics. - -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 -transactions. - -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 -an 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. - -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." For example, a default could -be to restrict transfers to addresses selected by the DNS -administrator(s) for zones on the server. - -6 Zone Integrity - -An AXFR client MUST ensure that only a successfully transferred -copy of the zone data can be used to serve this zone. Previous -description and implementation practice have introduced a two-stage -model of the whole zone synchronization procedure: Upon a trigger -event (e.g., polling of SOA resource record detects change in the -SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session -is initiated, whereby the zone data are saved in a zone file or -data base (this latter step is necessary anyway to ensure proper -restart of the server); upon successful completion of the AXFR -operation and some sanity checks, this data set is 'loaded' and -made available for serving the zone in an atomic operation, and -flagged 'valid' for use during the next restart of the DNS server; -if any error is detected, this data set MUST be deleted, and the -AXFR client MUST continue to serve the previous version of the zone, -if it did before. The externally visible behavior of an AXFR client -implementation MUST be equivalent to that of this two-stage model. - -If a server rejects data contained in an AXFR session, the server -SHOULD remember the serial number and MAY attempt to retrieve the -same zone version again. The reason the same retrieval could make -sense is that the reason for the rejection could be rooted in an -implementation detail of one AXFR server used for the zone and not -in another AXFR server used for the zone. - -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 connections, 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 the extent of -an implementation's compatibility the greater 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 MAY permit configuring, on a per -AXFR client basis, a need to revert to single resource record per -message; in that case, the default SHOULD be to use multiple records - -7.2 Client - -An AXFR client has the opportunity to try other features (i.e., those -not defined by this document) 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 - -The AXFR protocol is transparent to the parts of DNS zone content that -can possibly be subject to Internationalization considerations. -It is assumed that for DNS labels and domain names, the issue 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, -and other participants of the DNSEXT working group. - -12 References - -All references prefixed by "RFC" can be obtained from the RFC Editor -web site at the URLs: http://rfc-editor.org/rfc.html -or http://rfc-editor.org/rfcsearch.html ; -information regarding this organization can be found at the following -URL: http://rfc-editor.org/ - -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. -[RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. -[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. -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 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. -[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations", - BCP 42, RFC 5395, November 2008. -[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. -[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006 -[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of Existence", - RFC 5155, March 2008 -[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. -[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700, - October 1994. -[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. -[DRAFT1] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and - RRSIG Resource Records for DNSSEC", - draft-ietf-dnsext-dnssec-rsasha256-12, work in progress. -[DRAFT2] Weiler, S., and D. Blacka, "Clarifications and Implementation - Notes for DNSSECbis", - draft-ietf-dnsext-dnssec-bis-updates-08, work in progress. - -13 Editor's Address - -Edward Lewis -46000 Center Oak Plaza -Sterling, VA, 22033, US -+1-571-434-5468 -ed.lewis@neustar.biz