INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txtdraft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc. November 2000June 2001 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. 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. 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 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 (but1, but MAY be 0 when RCODE is nonzero)not NOERROR TC 0 RD Copy from requestrequest, or 0 RA Set according to availability of recursion Srecursion, or 0 Z 0 AD 0 CD 0 RCODE 0 orNOERROR on success, error code otherwise The slave MUST check the RCODE in each message and abort the transfer if it is nonzero.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 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. 4. Glue A master transmitting aZone data The purpose of the zone transfer MUST includemechanism is to exactly replicate at each slave the fullset of RRs associated with a particular zone data itat its primary master. An RR is associated with a zone by being loaded from the zone'smaster file, from an incomingfile of that zone transfer,at the primary master server, or other similar means ofby some other, equivalent method for configuring zone data. This includes any nonauthoritativereplication 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 ("glue")may be cached in resolvers associated with the zone by being presentintermediate masters/slaves. Therefore, in a zone transfer the zone'smaster file or the incoming transfer alongMUST send exactly those records that are associated with the authoritative data. This glue data includes any configured zone data obscured by zone cutszone, whether or otherwise outside the zone in case; it isnot limited to RRs pointedtheir owner names would be considered to by NS records. The glue RRs are transmitted in the answer section along withbe "in" the authoritative data. This is unlike ordinary DNS responses wherezone for purposes of resolution, and whether or not they would be eligible for use as glue is transmittedin the authority or additional section. Zone transfersresponses. The transfer MUST NOT containinclude any RRs fromthat are not associated with the authoritative data ofzone, such as RRs associated with zones other than the one being transferred or frompresent in the cache of the cache,local resolver, even when such RRsif their owner names are in the zone being transferred or are pointed to by NS records in the zone being transferred. AThe slave receiving a zone transferMUST accept glue data and recognize it as such; glue MUST NOT be treated as authoritative data nor entered into the cache. Note that classifying an RR as glue or non- glue may not be possible untilassociate the entire zone has beenRRs received so that thein a zone cuts defined by the zone's NS records can be determined. Glue data that is not belowtransfer with the specific zone origin ("cross-zone glue") MAY be discarded by the slave.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 send, and slave implementations expect to receive, the zone's SOA RR as the first and last record of the transfer. Any other RRs at the zone's apex are transmitted only once. Therefore, the quoted sentence is hereby changed to read "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 transmission order of all other RRs in the zone, including glue records,zone is undefined. Each of them MUST be transmitted exactly once. As some older masters do not comply with this requirement, slaves SHOULD silently ignore duplicate RRs for interoperability. 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 TSIG [RFC2845]a cryptographic mechanism for this purposeensuring 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, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme. References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987. [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. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 779381 6004 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2000).(2000, 2001). 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."