draft-ietf-dnsext-axfr-clarify-02.txt   draft-ietf-dnsext-axfr-clarify-03.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc. draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc.
June 2001 July 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 24 skipping to change at page 2, line 24
and needs no further clarification. and needs no further clarification.
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. 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 Slave servers should note that some master server implementations
will simply close the connection when denying the slave access to the will simply close the connection when denying the slave access to the
zone. Therefore, slaves MAY interpret an immediate graceful close of zone. Therefore, slaves MAY interpret an immediate graceful close of
the TCP connection as equivalent to a "Refused" response (RCODE 5). 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
skipping to change at page 4, line 4 skipping to change at page 4, line 7
3.4. The question section 3.4. The question section
RFC1034 does not specify whether zone transfer response messages have RFC1034 does not specify whether zone transfer response messages have
a question section or not. The initial message of a zone transfer a question section or not. The initial message of a zone transfer
response SHOULD have a question section identical to that in the response SHOULD have a question section identical to that in the
request. Subsequent messages SHOULD NOT have a question section, request. Subsequent messages SHOULD NOT have a question section,
though the final message MAY. The receiving slave server MUST accept though the final message MAY. The receiving slave server MUST accept
any combination of messages with and without a question section. any combination of messages with and without a question section.
3.5. The authority section 3.5. The authority section
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. It MUST NOT treat additional section RRs as zone
data.
4. Zone data 4. Zone data
The purpose of the zone transfer mechanism is to exactly replicate at 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 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 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 the master file of that zone at the primary master server, or by some
other, equivalent method for configuring zone data. other, equivalent method for configuring zone data.
This replication shall be complete and unaltered, regardless of how This replication shall be complete and unaltered, regardless of how
skipping to change at page 4, line 48 skipping to change at page 5, line 5
The slave MUST associate the RRs received in a zone transfer with the The slave MUST associate the RRs received in a zone transfer with the
specific zone being transferred, and maintain that association for specific zone being transferred, and maintain that association for
purposes of acting as a master in outgoing transfers. purposes of acting as a master in outgoing transfers.
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.
zone's apex are transmitted only once.
Therefore, the quoted sentence is hereby changed to read "The first Therefore, the quoted sentence is hereby superseded by the sentence
and last RR transmitted must be the SOA record of the zone". "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 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 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. The transmission order of all other RRs in the zone is undefined.
Each of them MUST be transmitted exactly once. As some older masters Each of them SHOULD be transmitted only once, and slaves MUST ignore
do not comply with this requirement, slaves SHOULD silently ignore any duplicate RRs received.
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 a cryptographic mechanism of the transferred zone data. The use of a cryptographic mechanism
for ensuring authenticity and integrity, such as TSIG [RFC2845], for ensuring authenticity and integrity, such as TSIG [RFC2845],
IPSEC, or TLS, is RECOMMENDED. IPSEC, or TLS, is RECOMMENDED.
skipping to change at page 5, line 37 skipping to change at page 5, line 43
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 Acknowledgements
Many people have contributed input and commentary to earlier versions Many people have contributed input and commentary to earlier versions
of this document, including but not limited to Bob Halley, Dan of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov, Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme. Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
Trenholme, and Brian Wellington.
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,
 End of changes. 

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