INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc.
November 2000
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 2001 [Page 1]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
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 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
Expires May 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
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 nonzero)
TC 0
RD Copy from request
RA Set according to availability of recursion S Z 0
AD 0
CD 0
RCODE 0 or error code
The slave MUST check the RCODE and abort the transfer if it is
nonzero. 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.
Expires May 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
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 a zone transfer MUST include the full set of
zone data it loaded from the zone's master file, from an incoming
zone transfer, or other similar means of configuring zone data. This
includes any nonauthoritative data ("glue") associated with the zone
by being present in the zone's master file or the incoming transfer
along with the authoritative data. This glue data includes any
configured zone data obscured by zone cuts or otherwise outside the
zone in case; it is not limited to RRs pointed to by NS records.
The glue RRs are transmitted in the answer section along with the
authoritative data. This is unlike ordinary DNS responses where glue
is transmitted in the authority or additional section.
Zone transfers MUST NOT contain RRs from the authoritative data of
zones other than the one being transferred or from the cache, even
when such RRs are pointed to by NS records in the zone being
transferred.
A slave receiving a zone transfer MUST 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 until the entire zone has been received so
that the zone cuts defined by the zone's NS records can be
determined. Glue data that is not below the zone origin ("cross-zone
glue") MAY be discarded by the slave.
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
Expires May 2001 [Page 4]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
same serial number.
The transmission order of all other RRs in the zone, including glue
records, is undefined.
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] for this
purpose 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.
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 779 6004
Email: gson@nominum.com
Expires May 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-01.txt November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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."
Expires May 2001 [Page 6]