draft-ietf-dnsext-axfr-clarify-06.txt   draft-ietf-dnsext-axfr-clarify-07.txt 
INTERNET-DRAFT Edward Lewis INTERNET-DRAFT Edward Lewis
draft-ietf-dnsext-axfr-clarify-06.txt NeuStar, Inc. draft-ietf-dnsext-axfr-clarify-07.txt NeuStar, Inc.
DNSEXT WG January 2008 DNSEXT WG February 2008
Updates: 1034, 1035 (if approved) Intended status: Standards Track Updates: 1034, 1035 (if approved) Intended status: Standards Track
DNS Zone Transfer Protocol (AXFR) DNS Zone Transfer Protocol (AXFR)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at line 30 skipping to change at line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 1, 2008. This Internet-Draft will expire on September 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Domain Name System standard facilities for maintaining coherent The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. The Authoritative servers for a zone consist of three elements. The Authoritative
Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental Transfer (AXFR) is defined in RFC 1034 and RFC 1035. The Incremental
skipping to change at line 53 skipping to change at line 53
definition of these facilities, that of the AXFR, has proven definition of these facilities, that of the AXFR, has proven
insufficient in detail, resulting in no implementation complying with insufficient in detail, resulting in no implementation complying with
it. Yet today we have a satisfactory set of implementations that do 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 interoperate. This document is a new definition of the AXFR, new in the
sense that is it recording an accurate definition of an interoperable sense that is it recording an accurate definition of an interoperable
AXFR mechanism. AXFR mechanism.
1 Introduction 1 Introduction
The Domain Name System standard facilities for maintaining coherent The Domain Name System standard facilities for maintaining coherent
servers for a zone consist of three elements. The Authoritative servers for a zone consist of three elements. Authoritative
Transfer (AXFR) is defined in RFC 1034 [RFC1034] and RFC 1035 [RFC1035]. Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities"
The Incremental Zone Transfer (IXFR) is defined in RFC 1995 [RFC1995]. [RFC1034] (referred to in this document as RFC 1034) and "Domain Names
A mechanism for prompt notification of zone changes (NOTIFY) is defined - Implementation and Specification" [RFC1035] (aka RFC 1035).
in RFC 1996 [RFC1996]. The goal of these mechanisms is to enable a set Incremental Zone Transfer (IXFR) is defined in "Incremental Zone
of DNS name servers to remain coherently authoritative for a given Transfer in DNS" [RFC1995]. A mechanism for prompt notification of zone
zone. changes (NOTIFY) is defined in "A Mechanism for Prompt Notification of
Zone Changes (DNS NOTIFY)" [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 Comments on this draft ought to be addressed to the editor or to
namedroppers@ops.ietf.org. namedroppers@ops.ietf.org.
1.1 Definition of Terms 1.1 Definition of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [BCP14]. RFCs to Indicate Requirement Levels" [BCP14].
"Newer"/"New DNS and "older"/"old" DNS refers to implementations
written after and prior to the publication of this document.
1.2 Scope 1.2 Scope
In the greater context, there are many ways to achieve coherency among a 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 set of name servers. These mechanisms form just one, the one defined in
the RFCs cited. For example, there are DNS implementations that the RFCs cited. For example, there are DNS implementations that
assemble answers from data riding in commercial database instances, and assemble answers from data stored in commercial (as opposed to open
rely on the database's proprietary or otherwise external-to-DNS means to source, etc.) database instances, and rely on the database's
synchronize the database instances. Some of these non-DNS solutions may proprietary or otherwise external-to-DNS means to synchronize the
even interoperate in some fashion. As far as it is known, AXFR, IXFR, database instances. Some of these non-DNS solutions might even
and NOTIFY are the only mechanisms that provide an interoperable interoperate in some fashion. As far as it is known, AXFR, IXFR, and
solution to the desire for coherency within the definition of DNS. NOTIFY are the only mechanisms that provide an interoperable solution
to the desire for coherency within the definition of DNS, they
certainly are the only mechanisms documented by the IETF.
This document does not cover incoherent DNS situations. There are This document does not cover incoherent DNS situations. There are
applications of the DNS in which servers for a zone are designed to be applications of the DNS in which servers for a zone are designed to be
incoherent. For these configurations, a coherency mechanism as incoherent. For these configurations, a coherency mechanism as
described here would be unsuitable. described here would be unsuitable.
"General purpose" DNS implementation refers to DNS software developed "General purpose DNS implementation" refers to DNS software developed
for wide spread use. This includes resolvers and servers freely for wide-spread use. This includes resolvers and servers freely
accessible as libraries and standalone processes. This also includes accessible as libraries and standalone processes. This also includes
proprietary implementations used only in support of DNS service proprietary implementations used only in support of DNS service
offerings. offerings.
"Turnkey" DNS implementation refers to custom made, single use "Turnkey DNS implementation" refers to custom made, single use
implementations of DNS. Such implementations consist of software the implementations of DNS. Such implementations consist of software
use the DNS protocol message format but does not conform to entire range that employes the DNS protocol message format yet do not conform to
of DNS functionality. the entire range of DNS functionality.
A DNS implementation is not required to support AXFR, IXFR, and NOTIFY. A DNS implementation is not required to support AXFR, IXFR, and NOTIFY.
A DNS implementation SHOULD have some means for maintaining name server A DNS implementation SHOULD have some means for maintaining name server
coherency. A general purpose DNS implementation SHOULD include AXFR, coherency. A general purpose DNS implementation SHOULD include AXFR,
IXFR, and NOTIFY, but turnkey DNS implementations MAY operate without IXFR, and NOTIFY, but turnkey DNS implementations MAY operate without
it. it.
1.3 Context 1.3 Context
Besides describing the mechanisms themselves, there is the context in Besides describing the mechanisms themselves, there is the context in
skipping to change at line 120 skipping to change at line 128
issues. Since the original definition of AXFR, new opinions have issues. Since the original definition of AXFR, new opinions have
appeared on the access to an entire zone's contents. In this document, appeared on the access to an entire zone's contents. In this document,
the basic mechanisms will be discussed separately from the permission to the basic mechanisms will be discussed separately from the permission to
use these mechanisms. use these mechanisms.
1.4 Coverage 1.4 Coverage
This document concentrates on just the definition of AXFR. Any effort This document concentrates on just the definition of AXFR. Any effort
to update the IXFR or NOTIFY mechanisms would be done in different to update the IXFR or NOTIFY mechanisms would be done in different
documents. This is not strictly a clarification of the definition in documents. This is not strictly a clarification of the definition in
RFC 1034 and RFC 1035. This document will update those sections, RFC 1034 and RFC 1035. This document will update those sections, and
invalidate at least one part of that definition. The goal of this invalidate at least one part of that definition. The goal of this
document is define AXFR as it exists, or should exist, currently. document is to define AXFR as it exists, or is supposed to exist,
currently.
2 AXFR Messages 2 AXFR Messages
An AXFR message exchange (or session) consists of an AXFR Query message 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 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 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 of terms such as master, slave, primary, secondary are not important to
defining the AXFR exchange.) The reason for the imbalance in number of defining the AXFR exchange.) The reason for the imbalance in number of
messages derives from large zones whose contents cannot be fit into the messages derives from large zones whose contents cannot be fit into the
limited permissible size of a DNS message. limited permissible size of a DNS message.
The upper limit on the permissible size of a DNS message is defined in An important aspect to keep in mind is that the definition of AXFR is
restricted to TCP [RFC0793]. The design of the AXFR process has certain
[RFC2671], see section 4.5. inherit features that are not easily ported to UDP [RFC0768].
Nonetheless, AXFR over UDP has some potential use cases. AXFR over UDP
is not defined here and might some day appear in an extension document.
The basic format of an AXFR message is the DNS message as defined in RFC 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 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following:
documents: RFC3425 [RFC3425], RFC1996 [RFC 1996], RFC2136 [RFC2136], - "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996]
- "Domain Name System (DNS) IANA Considerations" [RFC2929]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
[RFC4035], RFC4635 [RFC4635]. In addition, one change is credited to The upper limit on the permissible size of a DNS message is defined in
IANA, the reserving of OPCODE = 3. RFC 1035, section 2.3.4, and supplemented in RFC 2671, section 4.5.
The limit on the permissible size of a DNS message will be referenced
a few times in this document.
Field names used in this document will correspond to the names as the Field names used in this document will correspond to the names as they
appear in the IANA registry for DNS Header Flags [DNS-FLAGS]. appear in the IANA registry for DNS Header Flags [DNSFLGS].
2.1 AXFR Query 2.1 AXFR query
An AXFR Query is sent by a client whenever there is a reason to ask. 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 This might be because of zone maintenance activities or as a result of
command line request, say for debugging. a command line request, say for debugging.
2.1.1 Header Values 2.1.1 Header Values
These are the DNS message header values for an AXFR query.
ID See note 2.1.1.a ID See note 2.1.1.a
QR MUST be 0 (Query) QR MUST be 0 (Query)
OPCODE MUST be 0 (Standard Query) OPCODE MUST be 0 (Standard Query)
AA See note 2.1.1.b AA See note 2.1.1.b
TC See note 2.1.1.b TC See note 2.1.1.b
RD See note 2.1.1.b RD See note 2.1.1.b
RA See note 2.1.1.b RA See note 2.1.1.b
Z See note 2.1.1.c Z See note 2.1.1.c
AD See note 2.1.1.b AD See note 2.1.1.b
CD See note 2.1.1.b CD See note 2.1.1.b
RCODE MUST be 0 (No error) RCODE MUST be 0 (No error)
QDCOUNT MUST be 1 QDCOUNT MUST be 1
ANCOUNT MUST be 0 ANCOUNT MUST be 0
NSCOUNT MUST be 0 NSCOUNT MUST be 0
ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671] ARCOUNT See note 2.1.1.d
is in use
Note 2.1.1.a Set to any value that the client desires. There 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, is no specific means for selecting the value in this field. However,
consideration can be given to making it harder for forged messages to be consideration can be given to making it harder for forged messages to be
accepted by referencing the work in progress "Measures for making DNS accepted by referencing the work in progress "Measures for making DNS
more resilient against forged answers" [D-FORGERY]. more resilient against forged answers" [FORGERY].
Note 2.1.1.b The value in this field has no meaning in the Note 2.1.1.b The value in this field has no meaning in the context of
context of AXFR. For the client, RECOMMENDED that the value be zero. AXFR query messages. For the client, it is RECOMMENDED that the
For the server, RECOMMENDED ignoring this value. value be zero. For the server, it is RECOMMENDED ignoring this value.
Note 2.1.1.c The Z bit is no longer registered with IANA (no document Note 2.1.1.c The client MUST set to 0, the server MUST ignore.
cited for change). RECOMMENDED client set to 0, server MUST ignore.
Note 2.1.1.d The value MAY be 0, 1 or 2. If it is 2, the additional
section MUST contain both an EDNS0 [RFC2671] OPT resource record and
a record carrying transaction integrity and authentication data,
currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
value is 1, then the additional section MUST contain either only an
EDNS0 OPT resource record or a record carrying transaction integrity
and authentication data. If the value is 0, the additional section
MUST be empty.
2.1.2 Query Section 2.1.2 Query Section
The Query section of the AXFR query MUST conform to section 4.1.2 of RFC The Query section of the AXFR query MUST conform to section 4.1.2 of RFC
1035 contain the following values: 1035, and contain the following values:
QNAME the name of the zone requested QNAME the name of the zone requested
QTYPE AXFR [DNS-VALUES] QTYPE AXFR [DNSVALS], see the registry for the numeric value
QCLASS the class of the zone requested QCLASS the class of the zone requested
2.1.3 Answer Section 2.1.3 Answer Section
MUST be empty. MUST be empty.
2.1.4 Authority Section 2.1.4 Authority Section
MUST be empty. MUST be empty.
2.1.5 Additional Section 2.1.5 Additional Section
The client MAY include an EDNS0 section. If the server has indicated The client MAY include an EDNS0 OPT resource record. If the server
that it does not support EDNS0, the client MUST send this section empty has indicated that it does not support EDNS0, the client MUST send
if there is a retry. this section without an EDNS0 OPT resource record if there is a retry.
If the client is aware that the server does not support EDNS0, The client MAY include a transaction integrity and authentication
RECOMMENDED that this section be sent empty. A client MAY become aware resource record, currently a choice of TSIG or SIG(0). If the server
of a server's abilities via a configuration setting. has indicated that it does not recognize the resource record, the client
MUST send this section without such a resource record if there is a
retry.
An implementation of a general purpose client and server is RECOMMENDED If the client is aware that the server does not support EDNS0, it is
to support EDNS0. RECOMMENDED that this section be sent without the OPT resource record.
If the client is aware that the server will not participate in TSIG or
SIG(0), it is RECOMMENDED that the client not try to send such a record.
In general, if an AXFR client is aware that an AXFR server does not
support a particular mechanism, the client SHOULD NOT attempt to engage
the server using the mechanism. A client MAY become aware of a server's
abilities via a configuration setting.
2.2 AXFR Response 2.2 AXFR response
The AXFR Response will consist of 0 or more messages. A server MAY The AXFR response will consist of 0 or more messages.
elect to ignore the request altogether. The first response MUST begin
with the SOA resource record of the zone, the last response MUST An AXFR response that is transferring the zone's contents will consist
conclude with the same SOA resource record. Intermediate responses MUST of a series of DNS messages bounded in size by the limited permissible
not contain the SOA resource record. size. In such a series, the first message MUST begin with the SOA
resource record of the zone, the last message MUST conclude with the
same SOA resource record. Intermediate message MUST NOT contain the
SOA resource record. The first message MUST copy the Query Section
from the corresponding AXFR query message in to the first response
message's query section. Subsequent messages MAY do the same.
An AXFR response that is indicating an error MUST consist of a single
DNS message with the return code set to the appropriate value for the
condition encountered. Such a message MUST copy the AXFR query
Query Section into its Query Section.
An AXFR client MUST be able to react to no AXFR response Messages from
the server. An AXFR server MAY elect to silently discard the AXFR
query but this is only RECOMMENDED if the server has reasons to deduce
that the query was sent maliciously.
An AXFR server MAY elect to close the underlying TCP connection in
response to an AXFR query. Because this action could impact other
DNS queries and responses, it is RECOMMENDED that this tactic only be
employed when there are strong indications of malicious activity.
Still, an AXFR client MUST be able to adequately react to this
situation.
2.2.1 Header Values 2.2.1 Header Values
ID See note 2.2.1.a ID See note 2.2.1.a
QR MUST be 1 (Response) QR MUST be 1 (Response)
OPCODE MUST be 0 (Standard Query) OPCODE MUST be 0 (Standard Query)
AA See note 2.2.1.b AA See note 2.2.1.b
TC MUST be 0 (Not truncated) TC MUST be 0 (Not truncated)
RD RECOMMENDED copy request's value, MAY be set to 0 RD RECOMMENDED copy request's value, MAY be set to 0
RA See note 2.2.1.c RA See note 2.2.1.c
Z See note 2.2.1.d Z See note 2.2.1.d
AD See note 2.2.1.e AD See note 2.2.1.e
CD See note 2.2.1.e CD See note 2.2.1.e
RCODE See note 2.2.1.f RCODE See note 2.2.1.f
QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
following following
ANCOUNT See note 2.2.1.g ANCOUNT See note 2.2.1.g
NSCOUNT MUST be 0 NSCOUNT MUST be 0
ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671] ARCOUNT See note 2.2.1.h
is in use
Note 2.2.1.a Because of old implementations, the requirement Note 2.2.1.a Because of old implementations, the requirement
on this section is stated in detail. New DNS servers MUST set this 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 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 for the session. New AXFR clients MUST be able to accept sessions in
which the responses do not have the same ID field. 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 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 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. 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 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 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 other queries until the end of the zone transfer. A client MAY become
aware of a server's abilities via a configuration setting. 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 Note 2.2.1.b If the RCODE is 0 (no error), then the AA bit MUST be 1.
MUST be 1.
For any other value of RCODE, the AA bit MUST be set according to rules For any other value of RCODE, the AA bit MUST be set according to rules
for that error code. If in for that error code. If in doubt, it is RECOMMENDED that is be set
doubt, RECOMMENDED setting to 1, RECOMMENDED ignoring the value to 1. It is RECOMMENDED that the value be ignored by the AXFR client.
otherwise.
Note 2.2.1.c RECOMMENDED server setting value to 0, Note 2.2.1.c It is RECOMMENDED that the server set the value to 0,
RECOMMENDED client ignoring this value. it is RECOMMENDED that the client ignore this value.
The server MAY set this value according to the local policy regarding The server MAY set this value according to the local policy regarding
recursive service, but doing so may confuse the interpretation of the recursive service, but doing so might confuse the interpretation of the
response as AXFR MAY NOT be retrieved recursively. A client MAY note response as AXFR can not be retrieved recursively. A client MAY note
the server's policy regarding recursive from this value, but SHOULD NOT the server's policy regarding recursive from this value, but SHOULD NOT
conclude that the AXFR response was obtained recursively even if the RD conclude that the AXFR response was obtained recursively even if the RD
bit was 1 in the query. bit was 1 in the query.
Note 2.2.1.d The Z bit is no longer registered with IANA (no document Note 2.2.1.d The server MUST set to 0, and the client MUST ignore.
cited for change). RECOMMENDED client set to 0, server MUST ignore.
Note 2.2.1.e If the implementation is implementing DNSSEC [RFC4033-5], Note 2.2.1.e If the implementation supports the DNS Security Extensions
this value MUST be set according to the rules in RFC 4035 [RFC4035], (see below) then this value MUST be set according to the rules in RFC
section 3.1.6, "The AD and CD Bits in an Authoritative Response." If 4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response".
the implementation is not implementing DNSSEC, then this value MUST be If the implementation does not support the DNS Security Extensions, then
set to 0 an MUST be ignored. this value MUST be set to 0 and MUST be ignored upon receipt.
The DNS Security Extensions (DNSSEC) is defined in these base documents:
- "DNS Security Introduction and Requirements" [RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
Note 2.2.1.f In the absence of an error, the server MUST set the value 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 of this field to NoError. If a server is not authoritative for the
queried zone, the server SHOULD set the value to NotAuth. (Reminder, queried zone, the server SHOULD set the value to NotAuth. (Reminder,
consult the appropriate IANA registry [DNS-VALUES].) If a client consult the appropriate IANA registry [DNSVALS].) If a client
receives any other value in response, it MUST act according to the 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 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. 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 This value is not set as part of the AXFR response processing. The same
is true for other error-indicating values. is true for other error-indicating values.
Note 2.2.1.g The count of answer records MUST equal the number of 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 resource records in the AXFR Answer Section. When a server is aware
that a client will only accept one resource record per response message, 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 then the value MUST be 1. A server MAY be made aware of a client's
limitations via configuration data. limitations via configuration data.
Note 2.2.1.h The value MAY be 0, 1 or 2. If it is 2, the additional
section MUST contain both an EDNS0 [RFC2671] OPT resource record and
a record carrying transaction integrity and authentication data,
currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the
value is 1, then the additional section MUST contain either only an
EDNS0 OPT resource record or a record carrying transaction integrity
and authentication data. If the value is 0, the additional section
MUST be empty.
2.2.2 Query Section 2.2.2 Query Section
In the first response message, this section MUST be copied from the In the first response message, this section MUST be copied from the
query. In subsequent messages this section MAY 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 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 determine the context of the message, that is, the name of the zone
being transfered. being transferred.
2.2.3 Answer Section 2.2.3 Answer Section
MUST be populated with the zone contents. See later section on encoding MUST be populated with the zone contents. See later section on encoding
zone contents. zone contents.
2.2.4 Authority Section 2.2.4 Authority Section
MUST be empty. MUST be empty.
2.2.5 Additional Section 2.2.5 Additional Section
If the query included an EDNS0 OPT RR this section MAY include an OPT RR The contents of this section MUST follow the guidelines for EDNS0, TSIG,
in reply. If the query had an empty Additional Section, this MUST be SIG(0), or what ever other future record is possible here. See the
empty. A client MAY ignore the contents of this section. appropriate specifications for instructions and restrictions.
3 Zone Contents 3 Zone Contents
The objective of the AXFR session is to request and transfer the The objective of the AXFR session is to request and transfer the
contents of a zone. The objective is to permit the client to 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 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 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 static set of records to a dynamically updated set of records to a
continually regenerated set of records. continually regenerated set of records.
3.1 Records to Include 3.1 Records to Include
In the answer section of AXFR response messages the resource records In the answer section of AXFR response messages the resource records
within a zone for the given serial number MUST appear. The definition 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 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., the database is divided into zones", and in particular, section 4.2.1,
"Technical considerations." "Technical considerations".
The first resource record of the first AXFR response message sent by the 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 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 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 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 records in the AXFR is arbitrary, but the AXFR server SHOULD group
resource record sets together and transmit in the same AXFR message. resource record sets together.
Unless the AXFR server knows that the AXFR client expects just one Unless the AXFR server knows that the AXFR client expects just one
resource record per AXFR response message, an AXFR server SHOULD resource record per AXFR response message, an AXFR server SHOULD
populate an AXFR response message with as many complete resource records populate an AXFR response message with as many complete resource records
as will fit within the limited permissible message size. as will fit within the limited permissible message size.
Zones for which it is impractical to list the entire zones for a serial 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 number (because changes happen too quickly) are not suitable for AXFR
retrieval. retrieval.
3.2 Delegation Records 3.2 Delegation Records
In RFC 1034, section 4.2.1, this text appears (keep in mind that the use 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 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 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 same as the corresponding RRs in the top node of the subzone." There
been some controversy over this statement and the impact on which NS has been some controversy over this statement and the impact on which
resource records are included in a zone transfer. NS resource records are included in a zone transfer.
The phrase "that describe cuts" is a reference to the NS set and
applicable glue records. It does not mean that the cut points and the
apex resource records are identical. For example, the SOA resource
record is only found at the apex, as well as a slew of DNSSEC resource
records. There are also some DNSSEC resource record sets that are
explicitly different between the cut point and the apex. The
discussion here is restricted to just the NS resource record set and
glue as these "describe cuts."
The issue is that in operations there are times when the NS resource 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 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 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 sometimes it is part of an ongoing change in name servers. The DNS
protocol is robust enough to overcome inconsistencies up to there being protocol is robust enough to overcome inconsistencies up to there being
no parent indicated NS resource record referencing a server that is able 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 to serve the child zone. This robustness is one quality that has
the success of the DNS. Still, the inconsistency is a error state and fueled the success of the DNS. Still, the inconsistency is a error
steps need to be taken to make it apparent (if it is unplanned) and to state and steps need to be taken to make it apparent (if it is
make it clear once the inconsistency has been removed. unplanned) and to make it clear once the inconsistency has been removed.
Another issue is that the AXFR server could be authoritative for a 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 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 AXFR server be authoritative for both halves of an inconsistent cut
point and that the AXFR client is authoritative for just the parent of point and that the AXFR client is authoritative for just the parent of
the cut point. the cut point.
The question that arises is, when facing a situation in which a cut 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 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 an AXFR server responds with the NS resource record set that is in the
zone or is at the authoritative location. zone or is at the authoritative location.
The AXFR response MUST contain the cut point NS resource record set The AXFR response MUST contain the cut point NS resource record set
registered with the zone whether it agrees with the authoritative set or registered with the zone whether it agrees with the authoritative set or
not. "Registered with" can interpreted as residing in the zone file of not. "Registered with" can be widely interpreted to include data
the zone for the particular serial number (in zone file environments) or residing in the zone file of the zone for the particular serial
as any data configured to be in the zone, statically or dynamically. number (in zone file environments) or as any data configured to be in
the zone (database), statically or dynamically.
The reasons for this requirement are: The reasons for this requirement are:
1) The AXFR server might not be able to determine that there is an 1) The AXFR server might not be able to determine that there is an
inconsistency given local data, hence requiring consistency would mean a inconsistency given local data, hence requiring consistency would mean
lot more needed work and even network retrieval of data. An a lot more needed work and even network retrieval of data. An
authoritative server ought not be required to perform any queries. authoritative server ought not be required to perform any queries.
2) By transferring the inconsistent NS resource records from a server 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 authoritative for both the cut point and the apex to a client
that is not authoritative for both, the error is exposed. For example, that is not authoritative for both, the error is exposed. For example,
an authorized administrator can manually request the AXFR and inspect an authorized administrator can manually request the AXFR and inspect
the results to see the inconsistent records. (A server authoritative the results to see the inconsistent records. (A server authoritative
for both halves would otherwise always answer from the more for both halves would otherwise always answer from the more
authoritative set, concealing the error.) authoritative set, concealing the error.)
3) The inconsistent NS resource record set might indicate a problem in a 3) The inconsistent NS resource record set might indicate a problem in a
registration database. The DNS shouldn't cover this over. registration database.
3.3 Glue Records 3.3 Glue Records
As in the previous section, RFC 1034, section 4.2.1, provides guidance As quoted in the previous section, RFC 1034, section 4.2.1, provides
and rationale for the inclusion of glue records as part of an AXFR guidance and rationale for the inclusion of glue records as part of
transfer. And, as also argued in the previous section of this document, an AXFR transfer. And, as also argued in the previous section of this
even when there is an inconsistency between the address in a glue record document, even when there is an inconsistency between the address in a
and the authoritative copy of the name server's address, the glue glue record and the authoritative copy of the name server's address,
resource record that is registered as part of the zone for that serial the glue resource record that is registered as part of the zone for
number is to be included. that serial number is to be included.
This applies for glue records for any address family. This applies for glue records for any address family.
The AXFR response MUST contain the appropriate glue records as
registered with the zone. The interpretation of "registered with"
in the previous section applies here. Inconsistent glue records are
an operational matter.
3.4 Name Compression 3.4 Name Compression
Compression of names in DNS messages is described in RFC 1035, section Compression of names in DNS messages is described in RFC 1035, section
4.1.4, "Message compression". The issue highlighted here relates to a 4.1.4, "Message compression". The issue highlighted here relates to a
comment made in RFC 1034, section 3.1, "Name space specifications and comment made in RFC 1034, section 3.1, "Name space specifications and
terminology" which says "When you receive a domain name or label, you terminology" which says "When you receive a domain name or label, you
should preserve its case." should preserve its case." ("Should" in the quote predates [BCP14].)
Name compression in an AXFR message MUST preserve the case of the Name compression in an AXFR message MUST preserve the case of the
original domain name. That is, although when comparing a domain name, original domain name. That is, although when comparing a domain name,
"a" equals "A", when comparing for the purposes of message comparison, "a" equals "A", when comparing for the purposes of message comparison,
"a" is not equal to "A". "a" is not equal to "A".
Name compression of RDATA in an AXFR message MAY only be done on Name compression of RDATA in an AXFR message MAY only be done on
resource record types which explicitly permit such compression. resource record types which explicitly permit such compression.
4 Transport 4 Transport
AXFR sessions are restricted by RFC 1034, section 4.3.5's "because 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 accuracy is essential, TCP or some other reliable protocol must be used
for AXFR requests." With the addition of EDNS0 and applications which for AXFR requests." The most common scenario is for an AXFR client
require many small zones such in web hosting and some ENUM scenarios, to open a TCP connection to the AXFR server, send an AXFR query,
AXFR sessions on UDP are now possible and desirable. In addition, it is receive the AXFR response, and then close the connection. There are
conceivable to interleave requests for other data or AXFRs of other variations on this, such as a query for the zone's SOA resource
zones during one session in TCP if the ID values are consistently record first, and so on.
maintained.
Two issues have emerged since the original specification of AXFR.
One is that lack of specificity has yielded some implementations
that assume the TCP connection is dedicated to the single AXFR
session, which has led to implementation choices that prevent either
multiple concurrent zone transfers or the use of the open connection
for other queries. The other issue is the prospect of using UDP as a
transport has come to look promising because of trends in the past
two decades.
Being able to have multiple concurrent zone transfers is considered
desirable by operators who have sets of name servers that are
authoritative for a common set of zones. It would be desirable
if the name server implementations did not have to wait for one
zone to transfer before the next could begin. The desire here is to
tighten the specification, not a change, but adding words to the
unclear areas, to define what is needed to permit two servers to
share a TCP connection among concurrent AXFR sessions. The challenge
is to design this in a way that can fallback to the old behavior if
either the AXFR client or AXFR server is incapable of performing
multiple concurrent AXFR sessions.
With the addition of EDNS0 and applications which require many
small zones such as in web hosting and some ENUM scenarios, AXFR
sessions on UDP are now possible and desirable. However, there
are still some aspects of the AXFR session that are not easily
translated to UDP. This document leaves AXFR over UDP undefined,
with the issue to be discussed and possibly appear in a separate
definition.
4.1 TCP 4.1 TCP
In the original definition there is an implicit assumption that a TCP In the original definition there is an implicit assumption (probably
connection is used for one and only one AXFR session. This is evidenced unintentional) that a TCP connection is used for one and only one
in no requirement to maintain neither the query section nor the message AXFR session. This is evidenced in no requirement to copy neither
ID in responses and the lack of an explicit bit indicating that a zone the Query Section nor the message ID in responses, no explicit
transfer continues in the next message. ordering information within the AXFR response messages and the lack
of an explicit notice indicating that a zone transfer continues in the
next message.
Once an AXFR client opens a connection and sends an AXFR query, the AXFR The guidance given here is intended to enable better performance of
server MAY close the connection without a reply. Such an action is to be the AXFR exchange as well as guidelines on interactions with older
interpreted as refusal to honor the request. This option was not software. Better performance includes being able to multiplex DNS
originally defined but has proven to be one way to stop abusive message exchanges including zone transfer sessions. Guidelines for
behaviors by clients attempting to use up the server's available interacting with older software are generally applicable to AXFR
resources for TCP activity. clients as reversing the situation, older AXFR client and newer
AXFR server ought to induce the server to operate within the
specification for an older server.
Accommodation for implementations assuming this can be maintained, but 4.1.1 AXFR client TCP
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 An AXFR client MAY request an connection to an AXFR server upon any
the AXFR server is responding to a previous query. If this action demand. An AXFR client SHOULD close the connection when there is
causes the AXFR server to stop the original AXFR, the AXFR client SHOULD no apparent need to use the connection for some time period. This
not try this again with that AXFR server. latter comment is made so that the AXFR server does not have
to keep open idle connections, and placing the planning for a
connection closure on the client. Apparent need for the connection
is a judgement for the AXFR client and the DNS client in general, if
the connection is used for multiple sessions, or it is know sessions
will be coming, or is there is other query/response traffic on the
open connection, that is "apparent need."
An AXFR server MAY opt to respond to other queries while responding the An AXFR client MAY cancel delivery of a zone only by closing the
original AXFR query that opened the connection. An AXFR server MAY connection. However, this action will also cancel all other outstanding
ignore or even close the connection if there are two outstanding AXFR activity using the connection. There is no other mechanism by which
queries for the same zone on a connection, as this could be evidence of an AXFR response can be cancelled.
an abusive AXFR client.
4.2 UDP When a TCP connection is closed remotely (relative to the client),
whether by the AXFR server or due to a network event, the AXFR client
MUST cancel all outstanding sessions. Recovery from this situation
is not straightforward. If the disruption was a spurious event,
attempting to restart the connection would be proper. If the
disruption was caused by a medium or long term disruption, the AXFR
client would be wise to not spend too many resources trying to rebuild
the connection. Finally, if the connection was dropped because of a
policy at the AXFR server (as can be the case with older AXFR servers),
the AXFR client would be wise not retry the connection. Unfortunately,
knowing which of the three cases above applies is not clear
(momentary disruption, failure, policy).
AXFR sessions over UDP are not included in the base specification of An AXFR client MAY use an already opened TCP connection to start an
DNS. Given the definition of AXFR, probably for good reason. But there AXFR session. Using an existing open connection is RECOMMENDED over
are applications in which AXFR over UDP just might work. With expanded opening a new connection. (Non AXFR session traffic can also use an
DNS messages made possible by EDNS0, it can be possible to fit an entire open connection.) If in doing so that the AXFR client realizes that
zone's contents in to one DNS message. the responses cannot be properly differentiated (lack of matching
query IDs for example) or the connection is terminated for a remote
reason, then the AXFR client SHOULD not attempt to reuse an open
connection with the specific AXFR server until the AXFR server is
updated (which is of course, not an event captured in the DNS protocol).
Reasons not to do AXFR over UDP include cases where multiple AXFR 4.1.2 AXFR server TCP
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 An AXFR server MUST be able to handle multiple AXFR sessions on a
in one AXFR response message, the AXFR server MAY silently drop the single TCP connection, as well as handle other query/response sessions.
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 If a TCP connection is closed remotely, the AXFR server MUST cancel
receives a SERVFAIL response code, the client SHOULD retry the request all AXFR sessions in place. No retry activity is necessary, that is
via TCP. initiated by the AXFR client.
Local policy MAY dictate that a TCP connection is to be closed. Such
as action SHOULD be in reaction to limits such as those placed on
the number of outstanding open connections. Closing a connection in
response to a suspected security event SHOULD be done only in extreme
cases, when the server is certain the action is warranted. An
isolated request for a zone not on the AXFR server SHOULD receive
a response with the appropriate return code and not see the connection
broken.
4.2 UDP
AXFR sessions over UDP transport are not defined.
5 Authorization 5 Authorization
A zone administrator has the option to restrict AXFR access to a zone. 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 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 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 could be for various reasons including a desire (or in some instances,
of the zone concealed or to prevent the servers from handling the load having a legal requirement) to keep the bulk version of the zone
incurred in serving AXFR. All reasons are arguable, but the fact concealed or to prevent the servers from handling the load incurred in
remains that there is a requirement to provide mechanisms to restrict serving AXFR. All reasons are arguable, but the fact remains that
AXFR. there is a requirement to provide mechanisms to restrict AXFR.
A DNS implementation SHOULD provide means to restrict AXFR sessions to A DNS implementation SHOULD provide means to restrict AXFR sessions to
specific clients. By default, a DNS implementation SHOULD only allow specific clients. By default, a DNS implementation SHOULD only allow
the designated authoritative servers to have access to the zone. the designated authoritative servers to have access to the zone.
An implementation SHOULD allow access to be granted to Internet Protocol An implementation SHOULD allow access to be granted to Internet Protocol
addresses and ranges, regardless of whether a source address could be addresses and ranges, regardless of whether a source address could be
spoofed. Combining this with techniques such as Virtual Private spoofed. Combining this with techniques such as Virtual Private
Networks (VPN) [RFC2764] or Virtual LANs has proven to be effective. Networks (VPN) [RFC2764] or Virtual LANs has proven to be effective.
An implementation SHOULD allow access to be granted based upon "Secret A general purpose implementation is RECOMMENDED to implement access
Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request controls based upon "Secret Key Transaction Authentication for DNS"
and Transaction Signatures ( SIG(0)s )" [RFC2931]. [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
[RFC2931].
An implementation SHOULD allow access to be open to all requests. A general purpose implementation SHOULD allow access to be open to
all AXFR requests. I.e., an operator ought to be able to allow any
AXFR query to be granted.
A general purpose implementation SHOULD NOT have a default policy
for AXFR requests to be "open to all."
6 Zone Integrity 6 Zone Integrity
Ensuring that an AXFR client does not accept a forged copy of a zone is 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 important to the security of a zone. If a zone operator has the
opportunity, protection can be afforded via dedicated links, physical or opportunity, protection can be afforded via dedicated links, physical or
virtual via a VPN among the authoritative servers. But there are virtual via a VPN among the authoritative servers. But there are
instances in which zone operators have no choice but to run AXFR instances in which zone operators have no choice but to run AXFR
sessions over the global public Internet. sessions over the global public Internet.
skipping to change at line 567 skipping to change at line 717
implementation SHOULD, in it's documentation, encourage operators to implementation SHOULD, in it's documentation, encourage operators to
periodically review AXFR clients and servers it has made notes about as periodically review AXFR clients and servers it has made notes about as
old software periodically gets updated. old software periodically gets updated.
7.1 Server 7.1 Server
An AXFR server has the luxury of being able to react to an AXFR client's 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 abilities with the exception of knowing if the client can accept
multiple resource records per AXFR response message. The knowledge that multiple resource records per AXFR response message. The knowledge that
a client is so restricted apparently cannot be discovered, hence it has a client is so restricted apparently cannot be discovered, hence it has
to set by configuration. to be set by configuration.
An implementation of an AXFR server SHOULD permit configuring on a per An implementation of an AXFR server SHOULD permit configuring, on a per
AXFR client basis a need to revert to single resource record per AXFR client basis, a need to revert to single resource record per
message. The default SHOULD be to use multiple records per message. message. The default SHOULD be to use multiple records per message.
7.2 Client 7.2 Client
An AXFR client has the opportunity to try extensions when querying an An AXFR client has the opportunity to try extensions when querying an
AXFR server. AXFR server.
The use of EDNS0 to increase the DNS message size, offer authorizing 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 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 AXFR server via the methods already described as part of the EDNS0
skipping to change at line 619 skipping to change at line 769
Earlier editions of this document have been edited by Andreas Earlier editions of this document have been edited by Andreas
Gustafsson. In his latest version, this acknowledgement appeared. Gustafsson. In his latest version, this acknowledgement appeared.
"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, Robert Elz, Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme,
and Brian Wellington." and Brian Wellington."
Comments since the -05 version have come from these individuals:
Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain
Calder, Tony Finch, Ian Jackson, ...
12 References 12 References
All references prefixed by "RFC" can be obtained from the RFC Editor,
information regarding this organization can be found at the following
URL:
http://rfc-editor.org/
Additionally, these documents can be obtained via the IETF web site.
12.1 Normative 12.1 Normative
[RFC0793] "Transmission Control Protocol." J. Postel. September 1981.
[RFC0768] "User Datagram Protocol. " J. Postel. August 1980.
[RFC1034] "Domain names - concepts and facilities.", P.V. Mockapetris. [RFC1034] "Domain names - concepts and facilities.", P.V. Mockapetris.
Nov-01-1987. Nov-01-1987.
[RFC1035] "Domain names - implementation and specification." P.V. [RFC1035] "Domain names - implementation and specification." P.V.
Mockapetris. Nov-01-1987. Mockapetris. Nov-01-1987.
[RFC1995] "Incremental Zone Transfer in DNS." M. Ohta. August 1996. [RFC1995] "Incremental Zone Transfer in DNS." M. Ohta. August 1996.
[RFC1996] "A Mechanism for Prompt Notification of Zone Changes (DNS [RFC1996] "A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)." P. Vixie. August 1996. NOTIFY)." P. Vixie. August 1996.
[RFC2136] "Dynamic Updates in the Domain Name System (DNS UPDATE)." [RFC2136] "Dynamic Updates in the Domain Name System (DNS UPDATE)."
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
[RFC2671] "Extension Mechanisms for DNS (EDNS0)." P. Vixie. [RFC2671] "Extension Mechanisms for DNS (EDNS0)." P. Vixie.
August 1999. August 1999.
[RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)." [RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)."
P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. May 2000. P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington.
May 2000.
[RFC2929] "Domain Name System (DNS) IANA Considerations." D. Eastlake
3rd, E. Brunner-Williams, B. Manning. September 2000.
[RFC2930] "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake. [RFC2930] "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake.
September 2000. September 2000.
[RFC2931] "DNS Request and Transaction Signatures ( SIG(0)s)."
D. Eastlake. September 2000.
[RFC3425] "Obsoleting IQUERY." D. Lawrence. November 2002. [RFC3425] "Obsoleting IQUERY." D. Lawrence. November 2002.
[RFC4033-5] "DNS Security Introduction and Requirements," "Resource [RFC4033] "DNS Security Introduction and Requirements."
Records for the DNS Security Extensions," and "Protocol R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March
Modifications for the DNS Security Extensions." R. Arends, 2005.
R. Austein, M. Larson, D. Massey, S. Rose. March 2005. [RFC4034] "Resource Records 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." [RFC4035] "Protocol Modifications for the DNS Security Extensions."
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March
2005. 2005.
[RFC4635] "HMAC SHA (Hashed Message Authentication Code, Secure Hash [RFC4635] "HMAC SHA (Hashed Message Authentication Code, Secure Hash
Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd. Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd.
August 2006. August 2006.
[DNS-FLAGS] http://www.iana.org/assignments/dns-header-flags [DNSFLGS] http://www.iana.org/assignments/dns-header-flags
[DNS-VALUES] http://www.iana.org/assignments/dns-parameters [DNSVALS] http://www.iana.org/assignments/dns-parameters
12.2 Informative 12.2 Informative
[BCP14] "Key words for use in RFCs to Indicate Requirement Levels." [BCP14] "Key words for use in RFCs to Indicate Requirement Levels."
S. Bradner. March 1997. S. Bradner. March 1997.
[RFC2764] "A Framework for IP Based Virtual Private Networks." B. [RFC2764] "A Framework for IP Based Virtual Private Networks." B.
Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis.
2000. February 2000.
[RFC3490] "Internationalizing Domain Names in Applications (IDNA)." P. [RFC3490] "Internationalizing Domain Names in Applications (IDNA)." P.
Faltstrom, P. Hoffman, A. Costello. March 2003. Faltstrom, P. Hoffman, A. Costello. March 2003.
[D-FORGERY] "Measures for making DNS more resilient against forged [FORGERY] "Measures for making DNS more resilient against forged
answers." A. Hubert, R. van Mook. Work in Progress. answers." A. Hubert, R. van Mook. Work in Progress.
http://www.ietf.org/internet-drafts/ http://www.ietf.org/internet-drafts/
draft-ietf-dnsext-forgery-resilience-01.txt draft-ietf-dnsext-forgery-resilience-01.txt
13 Editor's Address 13 Editor's Address
Edward Lewis Edward Lewis
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA, 22033, US Sterling, VA, 22033, US
+1-571-434-5468 +1-571-434-5468
 End of changes. 78 change blocks. 
184 lines changed or deleted 353 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/