draft-ietf-dnsext-axfr-clarify-01.txt   draft-ietf-dnsext-axfr-clarify-02.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc. draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc.
November 2000 June 2001
DNS Zone Transfer Protocol Clarifications DNS Zone Transfer Protocol Clarifications
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Implementers are advised that one server implementation in widespread Implementers are advised that one server implementation in widespread
use sends AXFR requests where the TCP message envelope size exceeds use sends AXFR requests where the TCP message envelope size exceeds
the DNS request message size by two octets. the DNS request message size by two octets.
3. The zone transfer response 3. The zone transfer response
If the master server is unable or unwilling to provide a zone If the master server is unable or unwilling to provide a zone
transfer, it MUST respond with a single DNS message containing an transfer, it MUST respond with a single DNS message containing an
appropriate RCODE other than NOERROR. 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 If a zone transfer can be provided, the master server sends one or
more DNS messages containing the zone data as described below. more DNS messages containing the zone data as described below.
3.1. Multiple answers per message 3.1. Multiple answers per message
The zone data in a zone transfer response is a sequence of answer 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 RRs. These RRs are transmitted in the answer section(s) of one or
more DNS response messages. more DNS response messages.
The AXFR protocol definition in RFC1034 does not make a clear The AXFR protocol definition in RFC1034 does not make a clear
skipping to change at page 3, line 15 skipping to change at page 3, line 20
3.2. DNS message header contents 3.2. DNS message header contents
RFC1034 does not specify the contents of the DNS message header of RFC1034 does not specify the contents of the DNS message header of
the zone transfer response messages. The header of each message MUST the zone transfer response messages. The header of each message MUST
be as follows: be as follows:
ID Copy from request ID Copy from request
QR 1 QR 1
OPCODE QUERY OPCODE QUERY
AA 1 (but MAY be 0 when RCODE is nonzero) AA 1, but MAY be 0 when RCODE is not NOERROR
TC 0 TC 0
RD Copy from request RD Copy from request, or 0
RA Set according to availability of recursion S Z 0 RA Set according to availability of recursion, or 0
Z 0
AD 0 AD 0
CD 0 CD 0
RCODE 0 or error code RCODE NOERROR on success, error code otherwise
The slave MUST check the RCODE and abort the transfer if it is The slave MUST check the RCODE in each message and abort the transfer
nonzero. It SHOULD check the ID of the first message received and if it is not NOERROR. It SHOULD check the ID of the first message
abort the transfer if it does not match the ID of the request. The received and abort the transfer if it does not match the ID of the
ID SHOULD be ignored in subsequent messages, and fields other than request. The ID SHOULD be ignored in subsequent messages, and fields
RCODE and ID SHOULD be ignored in all messages, to ensure other than RCODE and ID SHOULD be ignored in all messages, to ensure
interoperability with certain older implementations which transmit interoperability with certain older implementations which transmit
incorrect or arbitrary values in these fields. incorrect or arbitrary values in these fields.
3.3. Additional section and SIG processing 3.3. Additional section and SIG processing
Zone transfer responses are not subject to any kind of additional Zone transfer responses are not subject to any kind of additional
section processing or automatic inclusion of SIG records. SIG RRs in section processing or automatic inclusion of SIG records. SIG RRs in
the zone data are treated exactly the same as any other RR type. the zone data are treated exactly the same as any other RR type.
3.4. The question section 3.4. The question section
skipping to change at page 4, line 11 skipping to change at page 4, line 14
The master server MUST transmit messages with an empty authority The master server MUST transmit messages with an empty authority
section. Slaves MUST ignore any authority section contents they may section. Slaves MUST ignore any authority section contents they may
receive from masters that do not comply with this requirement. receive from masters that do not comply with this requirement.
3.6. The additional section 3.6. The additional section
The additional section MAY contain additional RRs such as transaction The additional section MAY contain additional RRs such as transaction
signatures. The slave MUST ignore any unexpected RRs in the signatures. The slave MUST ignore any unexpected RRs in the
additional section. additional section.
4. Glue 4. Zone data
A master transmitting a zone transfer MUST include the full set of The purpose of the zone transfer mechanism is to exactly replicate at
zone data it loaded from the zone's master file, from an incoming each slave the set of RRs associated with a particular zone at its
zone transfer, or other similar means of configuring zone data. This primary master. An RR is associated with a zone by being loaded from
includes any nonauthoritative data ("glue") associated with the zone the master file of that zone at the primary master server, or by some
by being present in the zone's master file or the incoming transfer other, equivalent method for configuring zone data.
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 This replication shall be complete and unaltered, regardless of how
authoritative data. This is unlike ordinary DNS responses where glue many and which intermediate masters/slaves are involved, and
is transmitted in the authority or additional section. 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.
Zone transfers MUST NOT contain RRs from the authoritative data of Therefore, in a zone transfer the master MUST send exactly those
zones other than the one being transferred or from the cache, even records that are associated with the zone, whether or not their owner
when such RRs are pointed to by NS records in the zone being names would be considered to be "in" the zone for purposes of
transferred. 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.
A slave receiving a zone transfer MUST accept glue data and recognize The slave MUST associate the RRs received in a zone transfer with the
it as such; glue MUST NOT be treated as authoritative data nor specific zone being transferred, and maintain that association for
entered into the cache. Note that classifying an RR as glue or non- purposes of acting as a master in outgoing transfers.
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 5. Transmission order
RFC1034 states that "The first and last messages must contain the RFC1034 states that "The first and last messages must contain the
data for the top authoritative node of the zone". This is not data for the top authoritative node of the zone". This is not
consistent with existing practice. All known master implementations consistent with existing practice. All known master implementations
send, and slave implementations expect to receive, the zone's SOA RR 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 as the first and last record of the transfer. Any other RRs at the
zone's apex are transmitted only once. zone's apex are transmitted only once.
Therefore, the quoted sentence is hereby changed to read "The first Therefore, the quoted sentence is hereby changed to read "The first
and last RR transmitted must be the SOA record of the zone". and last RR transmitted must be the SOA record of the zone".
The initial and final SOA record MUST be identical, with the possible The initial and final SOA record MUST be identical, with the possible
exception of case and compression. In particular, they MUST have the exception of case and compression. In particular, they MUST have the
same serial number. same serial number.
The transmission order of all other RRs in the zone, including glue The transmission order of all other RRs in the zone is undefined.
records, 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 6. Security Considerations
The zone transfer protocol as defined in [RFC1034] and clarified by The zone transfer protocol as defined in [RFC1034] and clarified by
this memo does not have any built-in mechanisms for the slave to this memo does not have any built-in mechanisms for the slave to
securely verify the identity of the master server and the integrity securely verify the identity of the master server and the integrity
of the transferred zone data. The use of TSIG [RFC2845] for this of the transferred zone data. The use of a cryptographic mechanism
purpose is RECOMMENDED. 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 The zone transfer protocol allows read-only public access to the
complete zone data. Since data in the DNS is public by definition, complete zone data. Since data in the DNS is public by definition,
this is generally acceptable. Sites that wish to avoid disclosing this is generally acceptable. Sites that wish to avoid disclosing
their full zone data MAY restrict zone transfer access to authorized their full zone data MAY restrict zone transfer access to authorized
slaves. slaves.
These clarifications are not believed to themselves introduce any new These clarifications are not believed to themselves introduce any new
security problems, nor to solve any existing ones. 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 References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987. November 1987.
[RFC1035] - Domain Names - Implementation and Specifications, P. [RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987. Mockapetris, November 1987.
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
S. Bradner, BCP 14, March 1997. S. Bradner, BCP 14, March 1997.
skipping to change at page 5, line 48 skipping to change at page 6, line 15
Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
Author's Address Author's Address
Andreas Gustafsson Andreas Gustafsson
Nominum Inc. Nominum Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 779 6004 Phone: +1 650 381 6004
Email: gson@nominum.com Email: gson@nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000, 2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/