diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt | 393 |
1 files changed, 0 insertions, 393 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt deleted file mode 100644 index f0ce70a..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt +++ /dev/null @@ -1,393 +0,0 @@ - - - -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] - -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] - -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] - -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] - -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] - -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] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires May 2003 [Page 7] - - |
