+++ /dev/null
-
-
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
- November 2002
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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.
-
-Abstract
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires May 2003 [Page 1]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- 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 [RFC 2119].
-
-2. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003 [Page 2]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires May 2003 [Page 3]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires May 2003 [Page 4]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- 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.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires May 2003 [Page 5]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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
-
-
-
-Expires May 2003 [Page 6]
-\f
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003 [Page 7]
-\f
-
--- /dev/null
+INTERNET-DRAFT Edward Lewis
+draft-ietf-dnsext-axfr-clarify-06.txt NeuStar, Inc.
+DNSEXT WG January 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 August 1, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+The Domain Name System standard facilities for maintaining coherent
+servers for a zone consist of three elements. The Authoritative
+Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental
+Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt
+notification of zone changes (NOTIFY) is defined in RFC 1996. The base
+definition of these facilities, that of the AXFR, has proven
+insufficient in detail, resulting in no implementation complying with
+it. 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. The Authoritative
+Transfer (AXFR) is defined in RFC 1034 [RFC1034] and RFC 1035 [RFC1035].
+The Incremental Zone Transfer (IXFR) is defined in RFC 1995 [RFC1995].
+A mechanism for prompt notification of zone changes (NOTIFY) is defined
+in RFC 1996 [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 should be addresses 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].
+
+1.2 Scope
+
+In the greater context, there are many ways to achieve coherency among a
+set of name servers. These mechanisms form just one, the one defined in
+the RFCs cited. For example, there are DNS implementations that
+assemble answers from data riding in commercial database instances, and
+rely on the database's proprietary or otherwise external-to-DNS means to
+synchronize the database instances. Some of these non-DNS solutions may
+even interoperate in some fashion. As far as it is known, AXFR, IXFR,
+and NOTIFY are the only mechanisms that provide an interoperable
+solution to the desire for coherency within the definition of DNS.
+
+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 the
+use the DNS protocol message format but does not conform to 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,
+IXFR, and NOTIFY, but turnkey DNS implementations MAY operate without
+it.
+
+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,
+invalidate at least one part of that definition. The goal of this
+document is define AXFR as it exists, or should 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.
+
+The upper limit on the permissible size of a DNS message is defined in
+RFC 1035 [RFC1035], section 2.3.4, and supplemented in RFC 2671
+[RFC2671], see section 4.5.
+
+The basic format of an AXFR message is the DNS message as defined in RFC
+1035, Section 4 ("MESSAGES") [RFC 1035], updated by the following
+documents: RFC3425 [RFC3425], RFC1996 [RFC 1996], RFC2136 [RFC2136],
+RFC2671 [RFC2671], RFC2845 [RFC2845], RFC2930 [RFC2930], RFC4035
+[RFC4035], RFC4635 [RFC4635]. In addition, one change is credited to
+IANA, the reserving of OPCODE = 3.
+
+Field names used in this document will correspond to the names as the
+appear in the IANA registry for DNS Header Flags [DNS-FLAGS].
+
+2.1 AXFR Query
+
+An AXFR Query is sent by a client whenever there is a reason to ask.
+This may be because of zone maintenance activities or as a result of a
+command line request, say for debugging.
+
+2.1.1 Header Values
+
+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 MUST be either 0 or 1, the latter only if EDNS0 [RFC2671]
+ is in use
+
+Note 2.1.1.a Set to any value that the client desires. There
+is no specified means for selecting the value in this field. However,
+consideration can be given to making it harder for forged messages to be
+accepted by referencing the work in progress "Measures for making DNS
+more resilient against forged answers" [D-FORGERY].
+
+Note 2.1.1.b The value in this field has no meaning in the
+context of AXFR. For the client, RECOMMENDED that the value be zero.
+For the server, RECOMMENDED ignoring this value.
+
+Note 2.1.1.c The Z bit is no longer registered with IANA (no document
+cited for change). RECOMMENDED client set to 0, server MUST ignore.
+
+2.1.2 Query Section
+
+The Query section of the AXFR query MUST conform to section 4.1.2 of RFC
+1035 contain the following values:
+
+QNAME the name of the zone requested
+QTYPE AXFR [DNS-VALUES]
+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 section. If the server has indicated
+that it does not support EDNS0, the client MUST send this section empty
+if there is a retry.
+
+If the client is aware that the server does not support EDNS0,
+RECOMMENDED that this section be sent empty. A client MAY become aware
+of a server's abilities via a configuration setting.
+
+An implementation of a general purpose client and server is RECOMMENDED
+to support EDNS0.
+
+2.2 AXFR Response
+
+The AXFR Response will consist of 0 or more messages. A server MAY
+elect to ignore the request altogether. The first response MUST begin
+with the SOA resource record of the zone, the last response MUST
+conclude with the same SOA resource record. Intermediate responses MUST
+not contain the SOA resource record.
+
+2.2.1 Header Values
+
+ID See note 2.2.1.a
+QR MUST be 1 (Response)
+OPCODE MUST be 0 (Standard Query)
+AA See note 2.2.1.b
+TC MUST be 0 (Not truncated)
+RD RECOMMENDED copy request's value, MAY be set to 0
+RA See note 2.2.1.c
+Z See note 2.2.1.d
+AD See note 2.2.1.e
+CD See note 2.2.1.e
+RCODE See note 2.2.1.f
+QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
+ following
+ANCOUNT See note 2.2.1.g
+NSCOUNT MUST be 0
+ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671]
+ is in use
+
+Note 2.2.1.a Because of old implementations, the requirement
+on this section 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. New DNS clients MUST be able to accept sessions in
+which the responses do not have the same ID field.
+
+If a client detects or is aware that the server is new, that is, all of
+the responses have the same ID value as the query, the client MAY issue
+other DNS queries (of any type) to the server using the same transport.
+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.1.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, RECOMMENDED setting to 1, RECOMMENDED ignoring the value
+otherwise.
+
+Note 2.2.1.c RECOMMENDED server setting value to 0,
+RECOMMENDED client ignoring this value.
+
+The server MAY set this value according to the local policy regarding
+recursive service, but doing so may confuse the interpretation of the
+response as AXFR MAY NOT be retrieved recursively. A client MAY note
+the server's policy regarding recursive 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.1.d The Z bit is no longer registered with IANA (no document
+cited for change). RECOMMENDED client set to 0, server MUST ignore.
+
+Note 2.2.1.e If the implementation is implementing DNSSEC [RFC4033-5],
+this value MUST be set according to the rules in RFC 4035 [RFC4035],
+section 3.1.6, "The AD and CD Bits in an Authoritative Response." If
+the implementation is not implementing DNSSEC, then this value MUST be
+set to 0 an MUST be ignored.
+
+Note 2.2.1.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 [DNS-VALUES].) 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.1.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.
+
+2.2.2 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 transfered.
+
+2.2.3 Answer Section
+
+MUST be populated with the zone contents. See later section on encoding
+zone contents.
+
+2.2.4 Authority Section
+
+MUST be empty.
+
+2.2.5 Additional Section
+
+If the query included an EDNS0 OPT RR this section MAY include an OPT RR
+in reply. If the query had an empty Additional Section, this MUST be
+empty. A client MAY ignore the contents of this section.
+
+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."
+
+The first resource record of the first AXFR response message sent by the
+AXFR server MUST be the zone's SOA resource record. The last resource
+record of the final AXFR response message sent by the AXFR server MUST
+be the zone's SOA resource record. The order and grouping of all other
+records in the AXFR is arbitrary, but the AXFR server SHOULD group
+resource record sets together and transmit in the same AXFR message.
+
+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 the limited permissible message size.
+
+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 use
+of the word "should" in the quotation is exempt from the interpretation
+in 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 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 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 fueld
+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 may 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 interpreted as 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, 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. The DNS shouldn't cover this over.
+3.3 Glue Records
+
+As 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.
+
+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."
+
+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 comparison,
+"a" is not equal to "A".
+
+Name compression of RDATA in an AXFR message MAY only be done on
+resource record types which explicitly permit such compression.
+
+4 Transport
+
+AXFR sessions are restricted by RFC 1034, section 4.3.5's "because
+accuracy is essential, TCP or some other reliable protocol must be used
+for AXFR requests." With the addition of EDNS0 and applications which
+require many small zones such in web hosting and some ENUM scenarios,
+AXFR sessions on UDP are now possible and desirable. In addition, it is
+conceivable to interleave requests for other data or AXFRs of other
+zones during one session in TCP if the ID values are consistently
+maintained.
+
+4.1 TCP
+
+In the original definition there is an implicit assumption that a TCP
+connection is used for one and only one AXFR session. This is evidenced
+in no requirement to maintain neither the query section nor the message
+ID in responses and the lack of an explicit bit indicating that a zone
+transfer continues in the next message.
+
+Once an AXFR client opens a connection and sends an AXFR query, the AXFR
+server MAY close the connection without a reply. Such an action is to be
+interpreted as refusal to honor the request. This option was not
+originally defined but has proven to be one way to stop abusive
+behaviors by clients attempting to use up the server's available
+resources for TCP activity.
+
+Accommodation for implementations assuming this can be maintained, but
+newer implementations MAY choose to use the open TCP connection for
+other queries and AXFR sessions of other zones.
+
+An AXFR client MAY send a subsequent request to the AXFR server while
+the AXFR server is responding to a previous query. If this action
+causes the AXFR server to stop the original AXFR, the AXFR client SHOULD
+not try this again with that AXFR server.
+
+An AXFR server MAY opt to respond to other queries while responding the
+original AXFR query that opened the connection. An AXFR server MAY
+ignore or even close the connection if there are two outstanding AXFR
+queries for the same zone on a connection, as this could be evidence of
+an abusive AXFR client.
+
+4.2 UDP
+
+AXFR sessions over UDP are not included in the base specification of
+DNS. Given the definition of AXFR, probably for good reason. But there
+are applications in which AXFR over UDP just might work. With expanded
+DNS messages made possible by EDNS0, it can be possible to fit an entire
+zone's contents in to one DNS message.
+
+Reasons not to do AXFR over UDP include cases where multiple AXFR
+messages are needed for a zone, there is no way to guarantee all AXFR
+messages will arrive at the AXFR client and no way to detect a dropped
+AXFR message.
+
+If an AXFR server cannot place the entire contents of the requested zone
+in one AXFR response message, the AXFR server MAY silently drop the
+request or MAY send a response with an return code of SERVFAIL.
+
+If an AXFR client does not receive a reply to an AXFR query over UDP or
+receives a SERVFAIL response code, the client SHOULD retry the request
+via TCP.
+
+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 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.
+
+An implementation SHOULD allow access to be granted based upon "Secret
+Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request
+and Transaction Signatures ( SIG(0)s )" [RFC2931].
+
+An implementation SHOULD allow access to be open to all requests.
+
+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 a 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 implementers desire to maintain interoperability.
+
+It is unfortunate that needs to fall back to older behavior cannot be
+discovered, hence need 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 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.
+
+The use of EDNS0 to increase the DNS message size, offer authorizing
+proof, or to invoke message integrity can be tried and rejected by the
+AXFR server via the methods already described as part of the EDNS0
+mechanism.
+
+If an AXFR client attempts to use the UDP transport, non-response from
+the AXFR server or other error message can indicate not to retry that.
+
+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."
+
+12 References
+
+12.1 Normative
+
+[RFC1034] "Domain names - concepts and facilities.", P.V. Mockapetris.
+ Nov-01-1987.
+[RFC1035] "Domain names - implementation and specification." P.V.
+ Mockapetris. Nov-01-1987.
+[RFC1995] "Incremental Zone Transfer in DNS." M. Ohta. August 1996.
+[RFC1996] "A Mechanism for Prompt Notification of Zone Changes (DNS
+ NOTIFY)." P. Vixie. August 1996.
+[RFC2136] "Dynamic Updates in the Domain Name System (DNS UPDATE)."
+ P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
+[RFC2671] "Extension Mechanisms for DNS (EDNS0)." P. Vixie.
+ August 1999.
+[RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)."
+ P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. May 2000.
+[RFC2930] "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake.
+ September 2000.
+[RFC3425] "Obsoleting IQUERY." D. Lawrence. November 2002.
+[RFC4033-5] "DNS Security Introduction and Requirements," "Resource
+ Records for the DNS Security Extensions," and "Protocol
+ Modifications for the DNS Security Extensions." R. Arends,
+ R. Austein, M. Larson, D. Massey, S. Rose. March 2005.
+[RFC4035] "Protocol Modifications for the DNS Security Extensions."
+ R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March
+ 2005.
+[RFC4635] "HMAC SHA (Hashed Message Authentication Code, Secure Hash
+ Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd.
+ August 2006.
+[DNS-FLAGS] http://www.iana.org/assignments/dns-header-flags
+[DNS-VALUES] http://www.iana.org/assignments/dns-parameters
+
+12.2 Informative
+
+[BCP14] "Key words for use in RFCs to Indicate Requirement Levels."
+ S. Bradner. March 1997.
+[RFC2764] "A Framework for IP Based Virtual Private Networks." B.
+ Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February
+ 2000.
+[RFC3490] "Internationalizing Domain Names in Applications (IDNA)." P.
+ Faltstrom, P. Hoffman, A. Costello. March 2003.
+[D-FORGERY] "Measures for making DNS more resilient against forged
+ answers." A. Hubert, R. van Mook. Work in Progress.
+ http://www.ietf.org/internet-drafts/
+ draft-ietf-dnsext-forgery-resilience-01.txt
+
+13 Editor's Address
+
+Edward Lewis
+46000 Center Oak Plaza
+Sterling, VA, 22033, US
++1-571-434-5468
+ed.lewis@neustar.biz
+
+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
+ ietf-ipr@ietf.org.
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
projects / thirdparty / bind9.git / commitdiff
