ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2008-01-22 21:28:59 +00:00
parent 9925249931
commit 2ed540c845
2 changed files with 718 additions and 393 deletions
Download Patch File Download Diff File Expand all files Collapse all files

393
doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
View File

@@ -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]

718
doc/draft/draft-ietf-dnsext-axfr-clarify-06.txt Normal file
View File

@@ -0,0 +1,718 @@
INTERNET-DRAFT Edward Lewis
draft-ietf-dnsext-axfr-clarify-06.txt NeuStar, Inc.
DNSEXT WG January 2008
Updates: 1034, 1035 (if approved) Intended status: Standards Track
DNS Zone Transfer Protocol (AXFR)
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. The Authoritative
Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental
Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt
notification of zone changes (NOTIFY) is defined in RFC 1996. The base
definition of these facilities, that of the AXFR, has proven
insufficient in detail, resulting in no implementation complying with
it. Yet today we have a satisfactory set of implementations that do
interoperate. This document is a new definition of the AXFR, new in the
sense that is it recording an accurate definition of an interoperable
AXFR mechanism.
1 Introduction
The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. The Authoritative
Transfer (AXFR) is defined in RFC 1034 [RFC1034] and RFC 1035 [RFC1035].
The Incremental Zone Transfer (IXFR) is defined in RFC 1995 [RFC1995].
A mechanism for prompt notification of zone changes (NOTIFY) is defined
in RFC 1996 [RFC1996]. The goal of these mechanisms is to enable a set
of DNS name servers to remain coherently authoritative for a given
zone.
Comments on this draft should be addresses to the editor or to
namedroppers@ops.ietf.org.
1.1 Definition of Terms
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 "Key words for use in
RFCs to Indicate Requirement Levels" [BCP14].
1.2 Scope
In the greater context, there are many ways to achieve coherency among a
set of name servers. These mechanisms form just one, the one defined in
the RFCs cited. For example, there are DNS implementations that
assemble answers from data riding in commercial database instances, and
rely on the database's proprietary or otherwise external-to-DNS means to
synchronize the database instances. Some of these non-DNS solutions may
even interoperate in some fashion. As far as it is known, AXFR, IXFR,
and NOTIFY are the only mechanisms that provide an interoperable
solution to the desire for coherency within the definition of DNS.
This document does not cover incoherent DNS situations. There are
applications of the DNS in which servers for a zone are designed to be
incoherent. For these configurations, a coherency mechanism as
described here would be unsuitable.
"General purpose" DNS implementation refers to DNS software developed
for wide spread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service
offerings.
"Turnkey" DNS implementation refers to custom made, single use
implementations of DNS. Such implementations consist of software the
use the DNS protocol message format but does not conform to entire range
of DNS functionality.
A DNS implementation is not required to support AXFR, IXFR, and NOTIFY.
A DNS implementation SHOULD have some means for maintaining name server
coherency. A general purpose DNS implementation SHOULD include AXFR,
IXFR, and NOTIFY, but turnkey DNS implementations MAY operate without
it.
1.3 Context
Besides describing the mechanisms themselves, there is the context in
which they operate to consider. When AXFR, IXFR, and NOTIFY were
defined, there was little consideration given to security and privacy
issues. Since the original definition of AXFR, new opinions have
appeared on the access to an entire zone's contents. In this document,
the basic mechanisms will be discussed separately from the permission to
use these mechanisms.
1.4 Coverage
This document concentrates on just the definition of AXFR. Any effort
to update the IXFR or NOTIFY mechanisms would be done in different
documents. This is not strictly a clarification of the definition in
RFC 1034 and RFC 1035. This document will update those sections,
invalidate at least one part of that definition. The goal of this
document is define AXFR as it exists, or should exist, currently.
2 AXFR Messages
An AXFR message exchange (or session) consists of an AXFR Query message
and a set of AXFR Response messages. In this document, AXFR client is
the sender of the AXFR Query and the AXFR server is the responder. (Use
of terms such as master, slave, primary, secondary are not important to
defining the AXFR exchange.) The reason for the imbalance in number of
messages derives from large zones whose contents cannot be fit into the
limited permissible size of a DNS message.
The upper limit on the permissible size of a DNS message is defined in
RFC 1035 [RFC1035], section 2.3.4, and supplemented in RFC 2671
[RFC2671], see section 4.5.
The basic format of an AXFR message is the DNS message as defined in RFC
1035, Section 4 ("MESSAGES") [RFC 1035], updated by the following
documents: RFC3425 [RFC3425], RFC1996 [RFC 1996], RFC2136 [RFC2136],
RFC2671 [RFC2671], RFC2845 [RFC2845], RFC2930 [RFC2930], RFC4035
[RFC4035], RFC4635 [RFC4635]. In addition, one change is credited to
IANA, the reserving of OPCODE = 3.
Field names used in this document will correspond to the names as the
appear in the IANA registry for DNS Header Flags [DNS-FLAGS].
2.1 AXFR Query
An AXFR Query is sent by a client whenever there is a reason to ask.
This may be because of zone maintenance activities or as a result of a
command line request, say for debugging.
2.1.1 Header Values
ID See note 2.1.1.a
QR MUST be 0 (Query)
OPCODE MUST be 0 (Standard Query)
AA See note 2.1.1.b
TC See note 2.1.1.b
RD See note 2.1.1.b
RA See note 2.1.1.b
Z See note 2.1.1.c
AD See note 2.1.1.b
CD See note 2.1.1.b
RCODE MUST be 0 (No error)
QDCOUNT MUST be 1
ANCOUNT MUST be 0
NSCOUNT MUST be 0
ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671]
is in use
Note 2.1.1.a Set to any value that the client desires. There
is no specified means for selecting the value in this field. However,
consideration can be given to making it harder for forged messages to be
accepted by referencing the work in progress "Measures for making DNS
more resilient against forged answers" [D-FORGERY].
Note 2.1.1.b The value in this field has no meaning in the
context of AXFR. For the client, RECOMMENDED that the value be zero.
For the server, RECOMMENDED ignoring this value.
Note 2.1.1.c The Z bit is no longer registered with IANA (no document
cited for change). RECOMMENDED client set to 0, server MUST ignore.
2.1.2 Query Section
The Query section of the AXFR query MUST conform to section 4.1.2 of RFC
1035 contain the following values:
QNAME the name of the zone requested
QTYPE AXFR [DNS-VALUES]
QCLASS the class of the zone requested
2.1.3 Answer Section
MUST be empty.
2.1.4 Authority Section
MUST be empty.
2.1.5 Additional Section
The client MAY include an EDNS0 section. If the server has indicated
that it does not support EDNS0, the client MUST send this section empty
if there is a retry.
If the client is aware that the server does not support EDNS0,
RECOMMENDED that this section be sent empty. A client MAY become aware
of a server's abilities via a configuration setting.
An implementation of a general purpose client and server is RECOMMENDED
to support EDNS0.
2.2 AXFR Response
The AXFR Response will consist of 0 or more messages. A server MAY
elect to ignore the request altogether. The first response MUST begin
with the SOA resource record of the zone, the last response MUST
conclude with the same SOA resource record. Intermediate responses MUST
not contain the SOA resource record.
2.2.1 Header Values
ID See note 2.2.1.a
QR MUST be 1 (Response)
OPCODE MUST be 0 (Standard Query)
AA See note 2.2.1.b
TC MUST be 0 (Not truncated)
RD RECOMMENDED copy request's value, MAY be set to 0
RA See note 2.2.1.c
Z See note 2.2.1.d
AD See note 2.2.1.e
CD See note 2.2.1.e
RCODE See note 2.2.1.f
QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
following
ANCOUNT See note 2.2.1.g
NSCOUNT MUST be 0
ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671]
is in use
Note 2.2.1.a Because of old implementations, the requirement
on this section is stated in detail. New DNS servers MUST set this
field to the value of the AXFR Query ID in each AXFR Response message
for the session. New DNS clients MUST be able to accept sessions in
which the responses do not have the same ID field.
If a client detects or is aware that the server is new, that is, all of
the responses have the same ID value as the query, the client MAY issue
other DNS queries (of any type) to the server using the same transport.
Unless the client is sure that the server will consistently set the ID
field to the query's ID, the client is NOT RECOMMENDED to issue any
other queries until the end of the zone transfer. A client MAY become
aware of a server's abilities via a configuration setting.
Note 2.2.1.b If the RCODE is 0 (no error), then the AA bit
MUST be 1.
For any other value of RCODE, the AA bit MUST be set according to rules
for that error code. If in
doubt, RECOMMENDED setting to 1, RECOMMENDED ignoring the value
otherwise.
Note 2.2.1.c RECOMMENDED server setting value to 0,
RECOMMENDED client ignoring this value.
The server MAY set this value according to the local policy regarding
recursive service, but doing so may confuse the interpretation of the
response as AXFR MAY NOT be retrieved recursively. A client MAY note
the server's policy regarding recursive from this value, but SHOULD NOT
conclude that the AXFR response was obtained recursively even if the RD
bit was 1 in the query.
Note 2.2.1.d The Z bit is no longer registered with IANA (no document
cited for change). RECOMMENDED client set to 0, server MUST ignore.
Note 2.2.1.e If the implementation is implementing DNSSEC [RFC4033-5],
this value MUST be set according to the rules in RFC 4035 [RFC4035],
section 3.1.6, "The AD and CD Bits in an Authoritative Response." If
the implementation is not implementing DNSSEC, then this value MUST be
set to 0 an MUST be ignored.
Note 2.2.1.f In the absence of an error, the server MUST set the value
of this field to NoError. If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth. (Reminder,
consult the appropriate IANA registry [DNS-VALUES].) If a client
receives any other value in response, it MUST act according to the
error. For example, a malformed AXFR query or the presence of an EDNS0
OPT resource record sent to an old server will garner a FormErr value.
This value is not set as part of the AXFR response processing. The same
is true for other error-indicating values.
Note 2.2.1.g The count of answer records MUST equal the number of
resource records in the AXFR Answer Section. When a server is aware
that a client will only accept one resource record per response message,
then the value MUST be 1. A server MAY be made aware of a client's
limitations via configuration data.
2.2.2 Query Section
In the first response message, this section MUST be copied from the
query. In subsequent messages this section MAY be copied from the
query, MAY be empty. The content of this section MAY be used to
determine the context of the message, that is, the name of the zone
being transfered.
2.2.3 Answer Section
MUST be populated with the zone contents. See later section on encoding
zone contents.
2.2.4 Authority Section
MUST be empty.
2.2.5 Additional Section
If the query included an EDNS0 OPT RR this section MAY include an OPT RR
in reply. If the query had an empty Additional Section, this MUST be
empty. A client MAY ignore the contents of this section.
3 Zone Contents
The objective of the AXFR session is to request and transfer the
contents of a zone. The objective is to permit the client to
reconstruct the zone as it exists at the server for the given zone
serial number. Over time the definition of a zone has evolved from a
static set of records to a dynamically updated set of records to a
continually regenerated set of records.
3.1 Records to Include
In the answer section of AXFR response messages the resource records
within a zone for the given serial number MUST appear. The definition
of what belongs in a zone is described in RFC 1034, Section 4.2, "How
the database is divided into zones", and in particular, section 4.2.1.,
"Technical considerations."
The first resource record of the first AXFR response message sent by the
AXFR server MUST be the zone's SOA resource record. The last resource
record of the final AXFR response message sent by the AXFR server MUST
be the zone's SOA resource record. The order and grouping of all other
records in the AXFR is arbitrary, but the AXFR server SHOULD group
resource record sets together and transmit in the same AXFR message.
Unless the AXFR server knows that the AXFR client expects just one
resource record per AXFR response message, an AXFR server SHOULD
populate an AXFR response message with as many complete resource records
as will fit within the limited permissible message size.
Zones for which it is impractical to list the entire zones for a serial
number (because changes happen too quickly) are not suitable for AXFR
retrieval.
3.2 Delegation Records
In RFC 1034, section 4.2.1, this text appears (keep in mind that the use
of the word "should" in the quotation is exempt from the interpretation
in section 1.1) "The RRs that describe cuts ... should be exactly the
same as the corresponding RRs in the top node of the subzone." There has
been some controversy over this statement and the impact on which NS
resource records are included in a zone transfer.
The issue is that in operations there are times when the NS resource
records for a zone might be different at a cut point in the parent and
at the apex of a zone. Sometimes this is the result of an error and
sometimes it is part of an ongoing change in name servers. The DNS
protocol is robust enough to overcome inconsistencies up to there being
no parent indicated NS resource record referencing a server that is able
to serve the child zone. This robustness is one quality that has fueld
the success of the DNS. Still, the inconsistency is a error state and
steps need to be taken to make it apparent (if it is unplanned) and to
make it clear once the inconsistency has been removed.
Another issue is that the AXFR server could be authoritative for a
different set of zones than the AXFR client. It is possible that the
AXFR server may be authoritative for both halves of an inconsistent cut
point and that the AXFR client is authoritative for just the parent of
the cut point.
The question that arises is, when facing a situation in which a cut
point's NS resource records do not match the authoritative set, whether
an AXFR server responds with the NS resource record set that is in the
zone or is at the authoritative location.
The AXFR response MUST contain the cut point NS resource record set
registered with the zone whether it agrees with the authoritative set or
not. "Registered with" can interpreted as residing in the zone file of
the zone for the particular serial number (in zone file environments) or
as any data configured to be in the zone, statically or dynamically.
The reasons for this requirement are:
1) The AXFR server might not be able to determine that there is an
inconsistency given local data, hence requiring consistency would mean a
lot more needed work and even network retrieval of data. An
authoritative server ought not be required to perform any queries.
2) By transferring the inconsistent NS resource records from a server
that is authoritative for both the cut point and the apex to a client
that is not authoritative for both, the error is exposed. For example,
an authorized administrator can manually request the AXFR and inspect
the results to see the inconsistent records. (A server authoritative
for both halves would otherwise always answer from the more
authoritative set, concealing the error.)
3) The inconsistent NS resource record set might indicate a problem in a
registration database. The DNS shouldn't cover this over.
3.3 Glue Records
As in the previous section, RFC 1034, section 4.2.1, provides guidance
and rationale for the inclusion of glue records as part of an AXFR
transfer. And, as also argued in the previous section of this document,
even when there is an inconsistency between the address in a glue record
and the authoritative copy of the name server's address, the glue
resource record that is registered as part of the zone for that serial
number is to be included.
This applies for glue records for any address family.
3.4 Name Compression
Compression of names in DNS messages is described in RFC 1035, section
4.1.4, "Message compression". The issue highlighted here relates to a
comment made in RFC 1034, section 3.1, "Name space specifications and
terminology" which says "When you receive a domain name or label, you
should preserve its case."
Name compression in an AXFR message MUST preserve the case of the
original domain name. That is, although when comparing a domain name,
"a" equals "A", when comparing for the purposes of message comparison,
"a" is not equal to "A".
Name compression of RDATA in an AXFR message MAY only be done on
resource record types which explicitly permit such compression.
4 Transport
AXFR sessions are restricted by RFC 1034, section 4.3.5's "because
accuracy is essential, TCP or some other reliable protocol must be used
for AXFR requests." With the addition of EDNS0 and applications which
require many small zones such in web hosting and some ENUM scenarios,
AXFR sessions on UDP are now possible and desirable. In addition, it is
conceivable to interleave requests for other data or AXFRs of other
zones during one session in TCP if the ID values are consistently
maintained.
4.1 TCP
In the original definition there is an implicit assumption that a TCP
connection is used for one and only one AXFR session. This is evidenced
in no requirement to maintain neither the query section nor the message
ID in responses and the lack of an explicit bit indicating that a zone
transfer continues in the next message.
Once an AXFR client opens a connection and sends an AXFR query, the AXFR
server MAY close the connection without a reply. Such an action is to be
interpreted as refusal to honor the request. This option was not
originally defined but has proven to be one way to stop abusive
behaviors by clients attempting to use up the server's available
resources for TCP activity.
Accommodation for implementations assuming this can be maintained, but
newer implementations MAY choose to use the open TCP connection for
other queries and AXFR sessions of other zones.
An AXFR client MAY send a subsequent request to the AXFR server while
the AXFR server is responding to a previous query. If this action
causes the AXFR server to stop the original AXFR, the AXFR client SHOULD
not try this again with that AXFR server.
An AXFR server MAY opt to respond to other queries while responding the
original AXFR query that opened the connection. An AXFR server MAY
ignore or even close the connection if there are two outstanding AXFR
queries for the same zone on a connection, as this could be evidence of
an abusive AXFR client.
4.2 UDP
AXFR sessions over UDP are not included in the base specification of
DNS. Given the definition of AXFR, probably for good reason. But there
are applications in which AXFR over UDP just might work. With expanded
DNS messages made possible by EDNS0, it can be possible to fit an entire
zone's contents in to one DNS message.
Reasons not to do AXFR over UDP include cases where multiple AXFR
messages are needed for a zone, there is no way to guarantee all AXFR
messages will arrive at the AXFR client and no way to detect a dropped
AXFR message.
If an AXFR server cannot place the entire contents of the requested zone
in one AXFR response message, the AXFR server MAY silently drop the
request or MAY send a response with an return code of SERVFAIL.
If an AXFR client does not receive a reply to an AXFR query over UDP or
receives a SERVFAIL response code, the client SHOULD retry the request
via TCP.
5 Authorization
A zone administrator has the option to restrict AXFR access to a zone.
This was not envisioned in the original design of the DNS but has
emerged as a requirement as the DNS has evolved. Restrictions on AXFR
could be for various reasons including a desire to keep the bulk version
of the zone concealed or to prevent the servers from handling the load
incurred in serving AXFR. All reasons are arguable, but the fact
remains that there is a requirement to provide mechanisms to restrict
AXFR.
A DNS implementation SHOULD provide means to restrict AXFR sessions to
specific clients. By default, a DNS implementation SHOULD only allow
the designated authoritative servers to have access to the zone.
An implementation SHOULD allow access to be granted to Internet Protocol
addresses and ranges, regardless of whether a source address could be
spoofed. Combining this with techniques such as Virtual Private
Networks (VPN) [RFC2764] or Virtual LANs has proven to be effective.
An implementation SHOULD allow access to be granted based upon "Secret
Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request
and Transaction Signatures ( SIG(0)s )" [RFC2931].
An implementation SHOULD allow access to be open to all requests.
6 Zone Integrity
Ensuring that an AXFR client does not accept a forged copy of a zone is
important to the security of a zone. If a zone operator has the
opportunity, protection can be afforded via dedicated links, physical or
virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet.
Besides best attempts at securing TCP sessions, DNS implementations
SHOULD provide means to make use of "Secret Key Transaction
Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction
Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the
contents. These techniques MAY also be used for authorization.
7 Backwards Compatibility
Describing backwards compatibility is difficult because of a lack of
specifics in the original definition. In this section some hints at
building in backwards compatibility are given, mostly repeated from the
earlier sections.
Backwards compatibility is not necessary, but the greater extent of an
implementation's compatibility increases it's interoperability. For
turnkey implementations this is not usually a concern. For general
purpose implementations this takes on varying levels of importance
depending on the implementers desire to maintain interoperability.
It is unfortunate that needs to fall back to older behavior cannot be
discovered, hence need to be noted in a configuration file. An
implementation SHOULD, in it's documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about as
old software periodically gets updated.
7.1 Server
An AXFR server has the luxury of being able to react to an AXFR client's
abilities with the exception of knowing if the client can accept
multiple resource records per AXFR response message. The knowledge that
a client is so restricted apparently cannot be discovered, hence it has
to set by configuration.
An implementation of an AXFR server SHOULD permit configuring on a per
AXFR client basis a need to revert to single resource record per
message. The default SHOULD be to use multiple records per message.
7.2 Client
An AXFR client has the opportunity to try extensions when querying an
AXFR server.
The use of EDNS0 to increase the DNS message size, offer authorizing
proof, or to invoke message integrity can be tried and rejected by the
AXFR server via the methods already described as part of the EDNS0
mechanism.
If an AXFR client attempts to use the UDP transport, non-response from
the AXFR server or other error message can indicate not to retry that.
Attempting to issue multiple DNS queries over a TCP transport for an
AXFR session SHOULD be aborted if it interrupts the original request and
SHOULD take into consideration whether the AXFR server intends to close
the connection immediately upon completion of the original
(connection-causing) zone transfer.
8 Security Considerations
Concerns regarding authorization, traffic flooding, and message
integrity are mentioned in "Authorization" (section 5), "TCP" (section
4.2) and Zone Integrity (section 6).
9 IANA Considerations
No new registries or new registrations are included in this document.
10 Internationalization Considerations
It is assumed that supporting of international domain names has been
solved via "Internationalizing Domain Names in Applications (IDNA)"
[RFC3490].
11 Acknowledgements
Earlier editions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgement appeared.
"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."
12 References
12.1 Normative
[RFC1034] "Domain names - concepts and facilities.", P.V. Mockapetris.
Nov-01-1987.
[RFC1035] "Domain names - implementation and specification." P.V.
Mockapetris. Nov-01-1987.
[RFC1995] "Incremental Zone Transfer in DNS." M. Ohta. August 1996.
[RFC1996] "A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)." P. Vixie. August 1996.
[RFC2136] "Dynamic Updates in the Domain Name System (DNS UPDATE)."
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[RFC2671] "Extension Mechanisms for DNS (EDNS0)." P. Vixie.
August 1999.
[RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)."
P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. May 2000.
[RFC2930] "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake.
September 2000.
[RFC3425] "Obsoleting IQUERY." D. Lawrence. November 2002.
[RFC4033-5] "DNS Security Introduction and Requirements," "Resource
Records for the DNS Security Extensions," and "Protocol
Modifications for the DNS Security Extensions." R. Arends,
R. Austein, M. Larson, D. Massey, S. Rose. March 2005.
[RFC4035] "Protocol Modifications for the DNS Security Extensions."
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March
2005.
[RFC4635] "HMAC SHA (Hashed Message Authentication Code, Secure Hash
Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd.
August 2006.
[DNS-FLAGS] http://www.iana.org/assignments/dns-header-flags
[DNS-VALUES] http://www.iana.org/assignments/dns-parameters
12.2 Informative
[BCP14] "Key words for use in RFCs to Indicate Requirement Levels."
S. Bradner. March 1997.
[RFC2764] "A Framework for IP Based Virtual Private Networks." B.
Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February
2000.
[RFC3490] "Internationalizing Domain Names in Applications (IDNA)." P.
Faltstrom, P. Hoffman, A. Costello. March 2003.
[D-FORGERY] "Measures for making DNS more resilient against forged
answers." A. Hubert, R. van Mook. Work in Progress.
http://www.ietf.org/internet-drafts/
draft-ietf-dnsext-forgery-resilience-01.txt
13 Editor's Address
Edward Lewis
46000 Center Oak Plaza
Sterling, VA, 22033, US
+1-571-434-5468
ed.lewis@neustar.biz
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).