+++ /dev/null
-DNS Extensions Working Group Edward Lewis
-INTERNET-DRAFT NeuStar, Inc.
-Expires: Octopber 1, 2009 April 2009
-Updates: 1034, 1035 (if approved)
-Intended status: Standards Track
-
- DNS Zone Transfer Protocol (AXFR)
- draft-ietf-dnsext-axfr-clarify-11.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This Internet-Draft will expire on October 1, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with
- respect to this document.
-
-Abstract
-
-The Domain Name System standard mechanisms for maintaining coherent
-servers for a zone consist of three elements. One mechanism is the
-Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035.
-The definition of AXFR, has proven insufficient in detail, forcing
-implementations intended to be compliant to make assumptions, impeding
-interoperability. 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. Authoritative
-Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities"
-[RFC1034] (referred to in this document as RFC 1034) and "Domain Names
-- Implementation and Specification" [RFC1035] (aka RFC 1035).
-Incremental Zone Transfer (IXFR) is defined in "Incremental Zone
-Transfer in DNS" [RFC1995]. A mechanism for prompt notification of
-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 ought to be addressed 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].
-
-"Newer"/"New" DNS and "older"/"old" DNS refers to implementations
-written after and prior to the publication of this document.
-
-1.2 Scope
-
-In the greater context there are many ways to achieve coherency among
-a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form
-just one, the one defined in the RFCs cited. For example, there are
-DNS implementations that assemble answers from data stored in
-relational databases (as opposed to master files) relying on the
-database's non-DNS means to synchronize the database instances. Some
-of these non-DNS solutions interoperate in some fashion. As far as
-it is known, AXFR, IXFR and NOTIFY are the only in-band 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
-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
-that employs the DNS protocol message format yet do not conform to
-the 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
-(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations
-MAY exist without AXFR. (An editorial note to readers of this section.
-The mention of IXFR and NOTIFY is for context and illustration, this
-document does not make any normative comments on those mechanisms.)
-
-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 and Relationship to Original AXFR Specification
-
-This document concentrates on just the definition of AXFR. Any effort
-to update the IXFR or NOTIFY mechanisms would be done in different
-documents.
-
-The original "specification" of the AXFR sub-protocol is scattered
-through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5
-depicts the scenario for which AXFR has been designed. Section 4.3.5
-of RFC 1034 describes the zone synchronization strategies in general
-and rules for the invocation of a full zone transfer via AXFR; the
-fifth paragraph of that section contains a very short sketch of the
-AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant
-flaw in that specification. Section 3.2.3 of RFC 1035 has assigned
-the code point for the AXFR QTYPE (see section 2.1.2 below for more
-details). Section 4.2 of RFC 1035 discusses the transport layer use
-of DNS and shortly explains why UDP transport is deemed inappropriate
-for AXFR; the last paragraph of Section 4.2.2 gives details for the
-TCP connection management with AXFR. Finally, the second paragraph
-of Section 6.3 in RFC 1035 mandates server behavior when zone data
-changes occur during an ongoing zone transfer using AXFR.
-
-This document will update the specification of AXFR in fully
-specifying the record formats and processing rules for AXFR, largely
-expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing
-the transport considerations for AXFR, thus amending Section 4.2.2 of
-RFC 1035. Furthermore, it discusses backward compatibility issues
-and provides policy/management considerations as well as specific
-Security Considerations for AXFR. The goal of this document is to
-define AXFR as it exists, or is supposed to exist, currently.
-
-2 AXFR Messages
-
-An AXFR session consists of an AXFR query message and the sequence of
-AXFR response messages returned for it. In this document, the 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 AXFR.) The use of the word "session"
-without qualification refers to an AXFR session.
-
-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 inherent features that are not easily ported to UDP [RFC0768].
-
-The basic format of an AXFR message is the DNS message as defined in
-RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following:
-- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996]
-- "Domain Name System (DNS) IANA Considerations" [RFC5395]
-- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
-- "Clarifications to the DNS Specification" [RFC2181]
-- "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]
-- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
-- "Resource Records for the DNS Security Extensions" [RFC4034]
-- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
-- "Use of SHA-256 in DNSSEC ... (DS) ... (RRs)" [RFC4509]
-- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635]
-- "... (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
-
-For completeness, the following, in process, documents contain
-information about the DNS message. These documents ought not interfere
-with AXFR but these documents are helpful in understanding what will
-be carried via AXFR.
-
-- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
- Records for DNSSEC" [DRAFT1]
-- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2]
-
-The upper limit on the permissible size of a DNS message over TCP is
-only restricted by the TCP framing defined in RFC 1035, section 4.2.2
-which specifies a two-octet message length field, understood to be
-unsigned, and thus causing a limit of 65535 octets. Unlike DNS
-messages over UDP, this limit is not changed by EDNS0.
-
-Note that the TC (truncation) bit is never set by an AXFR server nor
-considered/read by an AXFR client.
-
-Field names used in this document will correspond to the names as they
-appear in the IANA registry for DNS Header Flags [DNSFLGS].
-
-2.1 AXFR query
-
-An AXFR query is sent by a client whenever there is a reason to ask.
-This might be because of zone maintenance activities or as a result of
-a command line request, say for debugging.
-
-An AXFR query is sent by a client whenever there is a reason to ask.
-This might be because of scheduled or triggered zone maintenance
-activities (see section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996],
-respectively) or as a result of a command line request, say for
-debugging.
-
-2.1.1 Header Values
-
-These are the DNS message header values for an AXFR query.
-
-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 See note 2.1.1.d
-
-Note 2.1.1.a Set to any value that the client is not already using
-with the same server. There is no specific means for selecting the
-value in this field. (Recall that AXFR is done only via TCP
-connections.)
-
-A server MUST reply using messages that use the same message ID to
-allow a client to meaningfully have multiple AXFR queries outstanding.
-
-Note 2.1.1.b The value in this field has no meaning in the context of
-AXFR query messages. For the client, it is RECOMMENDED that the
-value be zero. The server MUST ignore this value.
-
-Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore
-it.
-
-Note 2.1.1.d The client MUST set this field to be the number of
-resource records appearing in the additional section. See Section
-2.1.5 "Additional Section" for details.
-
-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
-
-The Query section of the AXFR query MUST conform to section 4.1.2 of
-RFC 1035, and contain the following values:
-
-QNAME the name of the zone requested
-QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS]
-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 OPT [RFC2671] resource record. If the
-server has indicated that it does not support EDNS0, the client MUST
-send this section without an EDNS0 OPT resource record if there is a
-retry. Indication that a server does not support EDNS0 is not an
-explicit element in the protocol, it is up to the client to interpret.
-Most likely, the server will return a FORMERR which might be related to
-the OPT resource record.
-
-The client MAY include a transaction integrity and authentication
-resource record, currently a choice of TSIG [RFC2845] or SIG(0)
-[RFC2931]. If the server has indicated that it does not recognize the
-resource record, and that the error is indeed caused by the resource
-record, the client probably ought not try again. Removing the security
-data in the face of an obstacle ought to only be done with full
-awareness of the implication of doing so.
-
-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 (or at all). A client could become
-aware of a server's abilities via a configuration setting or via some
-other (as yet) undefined means.
-
-The range of permissible resource records that MAY appear in the
-additional section might change over time. If either a change to an
-existing resource record (like the OPT RR for EDNS0) is made or
-a new additional section record is created, the new definitions ought
-to include a discussion on the impact upon AXFR. Although this is not
-predictable, future additional section residing records may have an
-effect that is orthogonal to AXFR, so can ride through the session as
-opaque data. In this case, a "wise" implementation ought to be able
-to pass these records through without disruption.
-
-2.2 AXFR response
-
-The AXFR response will consist of 0 or more messages. A "0 message"
-response is covered in section 2.2.1.
-
-An AXFR response that is transferring the zone's contents will consist
-of a series (which could be a series of length 1) of DNS messages.
-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 messages 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 - once the error condition is detected. Such
-a message MUST terminate the AXFR session; it MUST copy the Query
-Section from the AXFR query into its Query Section, but the inclusion
-of the terminating SOA resource record is not necessary.
-
-An AXFR client might receive a number of AXFR response messages
-free of an error condition before the message indicating an error
-is received.
-
-2.2.1 "0 Message" Response
-
-A legitimate "0 message" response, i.e., the client sees no response
-whatsoever, is very exceptional and controversial. Unquestionably it
-is unhealthy for there to be 0 responses in a protocol that is designed
-around a query - response paradigm over an unreliable transport. The
-lack of a response could be a sign of underlying network problems and
-cause the protocol state machine to react accordingly. However, AXFR
-uses TCP and not UDP, eliminating undetectable network errors.
-
-A "0 message response" is reserved for situations in which the server
-has a reason to suspect that the query is sent for the purpose of
-abuse. Due to the use of this being so controversial, a "0 message
-response" is not being defined as a legitimate part of the protocol
-but the use of it is being acknowledged as a warning to AXFR client
-implementations. Any earnest query has the expectation of some
-response but may not get one.
-
-2.2.2 Header Values
-
-ID See note 2.2.2.a
-QR MUST be 1 (Response)
-OPCODE MUST be 0 (Standard Query)
-AA See note 2.2.2.b
-TC MUST be 0 (Not truncated)
-RD RECOMMENDED copy request's value, MAY be set to 0
-RA See note 2.2.2.c
-Z See note 2.2.2.d
-AD See note 2.2.2.e
-CD See note 2.2.2.e
-RCODE See note 2.2.2.f
-QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all
- following
-ANCOUNT See note 2.2.2.g
-NSCOUNT MUST be 0
-ARCOUNT See note 2.2.2.h
-
-Note 2.2.2.a Because some old implementations behave differently than
-is now desired, the requirement on this field 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. AXFR clients MUST
-be able to manage sessions resulting from the issuance of multiple
-outstanding queries, whether AXFR queries or other DNS queries. A
-client SHOULD discard responses that do not correspond (via the
-message ID) to any outstanding queries.
-
-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.2.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, it is RECOMMENDED that it be set
-to 1. It is RECOMMENDED that the value be ignored by the AXFR client.
-
-Note 2.2.2.c It is RECOMMENDED that the server set the value to 0,
-the client MUST ignore this value.
-
-The server MAY set this value according to the local policy regarding
-recursive service, but doing so might confuse the interpretation of the
-response as AXFR can not be retrieved recursively. A client MAY note
-the server's policy regarding recursive service 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.2.d The server MUST set this bit to 0, the client MUST ignore
-it.
-
-Note 2.2.2.e If the implementation supports the DNS Security Extensions
-(see below) then this value MUST be set according to the rules in RFC
-4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response".
-If the implementation does not support the DNS Security Extensions,
-then 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]
-- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509]
-- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155]
-
-as well pending documents, such as these:
-
-- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource
- Records for DNSSEC" [DRAFT1]
-- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2]
-
-Note 2.2.2.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 [DNSVALS].) 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-specific response processing.
-The same is true for other error-indicating values.
-
-Note 2.2.2.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.
-
-Note 2.2.2.h The client MUST set this field to be the number of
-resource records appearing in the additional section. The
-considerations in Note 2.1.1.d above apply equally; see Section
-2.2.6 "Additional Section" below for more details.
-
-2.2.3 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 or it 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 transferred.
-
-2.2.4 Answer Section
-
-MUST be populated with the zone contents. See later section on
-encoding zone contents.
-
-2.2.5 Authority Section
-
-MUST be empty.
-
-2.2.6 Additional Section
-
-The contents of this section MUST follow the guidelines for EDNS0,
-TSIG, SIG(0), or what ever other future record is possible here. The
-contents of section 2.1.5 apply here as well.
-
-2.3 TCP Connection Aborts
-
-If an AXFR client sends a query on a TCP connection and the connection
-is closed at any point, the AXFR client MUST consider the AXFR session
-terminated. The message ID MAY be used again on a new connection,
-even if the question and AXFR server are the same. Facing a dropped
-connection a client SHOULD try to make some determination whether the
-connection closure was the result of network activity or a decision
-by the AXFR server. This determination is not an exact science. It
-is up to the AXFR client implementor to react, but the reaction
-SHOULD NOT be an endless cycle of retries nor an increasing (in
-frequency) retry rate.
-
-An AXFR server implementor SHOULD take into consideration the dilemma
-described above when a connection is closed with an outstanding query
-in the pipeline. For this reason, a server ought to reserve this
-course of action for situations in which it believes beyond a doubt
-that the AXFR client is attempting abusive behavior.
-
-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 AXFR 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
-denoting a static set of records to also cover a dynamically updated
-set of records, and then a potentially continually regenerated set of
-records as well.
-
-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", in particular, section 4.2.1,
-"Technical considerations", and it has been clarified in Section 6 of
-RFC 2181.
-
-Unless the AXFR server knows that the AXFR client is old and expects
-just one resource record per AXFR response message, an AXFR server
-SHOULD populate an AXFR response message with as many complete
-resource record sets as will fit within a DNS message.
-
-Zones for which it is impractical to list the entire zones for a serial
-number are not suitable for AXFR retrieval. A typical (but not
-limiting) description of such a zone is a zone consisting of responses
-generated via other database lookups and/or computed based upon ever
-changing data.
-
-3.2 Delegation Records
-
-In RFC 1034, section 4.2.1, this text appears (keep in mind that the
-"should" in the quotation predates [BCP14], cf. 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 phrase "that describe cuts" is a reference to the NS set and
-applicable glue records. It does not mean that the cut point and apex
-resource records are identical. For example, the SOA resource record
-is only found at the apex. The discussion here is restricted to just
-the NS resource record set and glue as these "describe cuts".
-
-DNSSEC resource records have special specifications regarding their
-occurrence at a zone cut and the apex of a zone. This has for the
-first time been described in Sections 5.3 ff. and 6.2 of RFC 2181
-(for the initial specification of DNSSEC), which now is historical.
-The current DNSSEC core document set (see Note 2.2.2.e above) gives
-the full details for DNSSEC(bis) resource record placement, and
-Section 3.1.5 of RFC 4035 normatively specifies their treatment during
-AXFR; the alternate NSEC3 resource record defined later in RFC 5155
-behaves identically as the NSEC RR, for the purpose of AXFR.
-
-Informally:
-o The DS RRSet only occurs at the parental side of a zone cut and is
- authoritative data in the parent zone, not the secure child zone.
-o The DNSKEY RRSet only occurs at the APEX of a signed zone and is
- authoritative part of the zone it serves.
-o Independent RRSIG RRSets occur at the signed parent side and of a
- zone cut and at the apex of a signed zone; they are authoritative
- part of the respective zone; simple queries for RRSIG resource
- records may return bth RRSets at once if the same server is
- authoritative for the parent zone and the child zone (Section
- 3.1.5 of RFC 4035 describes how to distinguish these RRs); this
- seeming ambiguity does not occur for AXFR, since each such RRSIG
- RRset belongs to a single zone.
-o Different NSEC [RFC4034] or NSEC3 [RFC5155] resource records
- equally may occur at the parental siede of a zone cut and at the
- apex of a zone; each such resource record belongs to exactly one
- of these zones and is to be included in the AXFR of that zone.
-
-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 (but not
-including) 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 fueled the success of the DNS.
-Still, the inconsistency is an 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 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 being transferred 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 be widely interpreted to include data
-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 (database), 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.
-
-4) This requirement is necessary to ensure that retrieving a given
-(zone,serial) pair by AXFR yields the exact same set of resource
-records no matter which of the zone's authoritative servers is
-chosen as the source of the transfer.
-
-If an AXFR server were allowed to respond with the authoritative
-NS RRset of a child zone instead of a glue NS RRset in the zone
-being transferred, the set of records returned could vary depending
-on whether or not the server happens to also be authoritative for
-the child zone.
-
-The property that a given (zone,serial) pair corresponds to a
-single, well-defined set of records is necessary for the correct
-operation of incremental transfer protocols such as IXFR
-[RFC1995]. For example, a client may retrieve a zone by AXFR from
-one server, and then apply an incremental change obtained by IXFR
-from a different server. If the two servers have different ideas
-of the zone contents, the client can end up attempting to
-incrementally add records that already exist or to delete records
-that do not exist.
-
-3.3 Glue Records
-
-As quoted in the previous section, section 4.2.1 of RFC 1034 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 to glue records for any address family [RFC1700].
-
-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
-
-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." ("Should" in the quote predates [BCP14].)
-
-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 compression,
-"a" is not equal to "A". Note that this is not the usual definition
-of name comparison in the DNS protocol and represents a new
-requirement on AXFR servers.
-
-Rules governing name compression of RDATA in an AXFR message MUST
-abide by the specification in "Handling of Unknown DNS Resource Record
-(RR) Types" [RFC3597], specifically, section 4 on "Domain Name
-Compression."
-
-3.5 Occluded Names
-
-Dynamic Update [RFC2136] operations, and in particular its interaction
-with DNAME [RFC2672], can have a side effect of occluding names in a
-zone. The addition of a delegation point via dynamic update will
-render all subordinate domain names to be in a limbo, still part of
-the zone but not available to the lookup process. The addition of a
-DNAME resource record has the same impact. The subordinate names are
-said to be "occluded."
-
-Occluded names MUST be included in AXFR responses. An AXFR client MUST
-be able to identify and handle occluded names. The rationale for this
-action is based on a speedy recovery if the dynamic update operation
-was in error and is to be undone.
-
-4 Transport
-
-AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC
-1034 that states: "Because accuracy is essential, TCP or some other
-reliable protocol must be used for AXFR requests." The restriction to
-TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet
-Hosts - Application and Support" [RFC1123].
-
-The most common scenario is for an AXFR client to open a TCP connection
-to the AXFR server, send an AXFR query, receive the AXFR response, and
-then close the connection. There are variations on this, such as a
-query for the zone's SOA resource record first, and so on. Note that
-this is documented as a most common scenario.
-
-The assumption that a TCP connection is dedicated to the single AXFR
-session is incorrect, this has led to implementation choices that
-prevent either multiple concurrent zone transfers or the use of the
-open connection for other queries.
-
-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 fall back 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 would now be possible and seem 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.
-
-4.1 TCP
-
-In the original definition there is an implicit assumption (probably
-unintentional) that a TCP connection is used for one and only one
-AXFR session. This is evidenced in no requirement to copy neither
-the Query Section nor the message ID in responses, no explicit
-ordering information within the AXFR response messages and the lack
-of an explicit notice indicating that a zone transfer continues in the
-next message.
-
-The guidance given here is intended to enable better performance of
-the AXFR exchange as well as guidelines on interactions with older
-software. Better performance includes being able to multiplex DNS
-message exchanges including zone transfer sessions. Guidelines for
-interacting with older software are generally applicable to new AXFR
-clients. In the reverse situation, older AXFR client and newer AXFR
-server ought to induce the server to operate within the specification
-for an older server.
-
-4.1.1 AXFR client TCP
-
-An AXFR client MAY request a connection to an AXFR server for any
-reason. An AXFR client SHOULD close the connection when there is
-no apparent need to use the connection for some time period. The
-AXFR server ought not have to maintain idle connections, the burden
-of connection closure ought to be on the client. Apparent need for
-the connection is a judgment for the AXFR client and the DNS
-client. If the connection is used for multiple sessions, or if it is
-known sessions will be coming or if there is other query/response
-traffic anticipated or currently on the open connection, then there
-is "apparent need."
-
-An AXFR client MAY cancel delivery of a zone only by closing the
-connection. However, this action will also cancel all other outstanding
-activity using the connection. There is no other mechanism by which
-an AXFR response can be cancelled.
-
-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 and non-AXFR transactions.
-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 to not retry
-the connection. Unfortunately, knowing which of the three cases above
-(momentary disruption, failure, policy) applies is not possible with
-certainty, and can only be assessed by heuristics.
-
-An AXFR client MAY use an already opened TCP connection to start an
-AXFR session. Using an existing open connection is RECOMMENDED over
-opening a new connection. (Non-AXFR session traffic can also use an
-open connection.) If in doing so the AXFR client realizes that
-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).
-
-4.1.2 AXFR server TCP
-
-An AXFR server MUST be able to handle multiple AXFR sessions on a
-single TCP connection, as well as handle other query/response
-transactions.
-
-If a TCP connection is closed remotely, the AXFR server MUST cancel
-all AXFR sessions in place. No retry activity is necessary; that is
-initiated by the AXFR client.
-
-Local policy MAY dictate that a TCP connection is to be closed. Such
-an 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
-
-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 (or in some instances,
-having a legal requirement) 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.
-
-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.
-
-A general purpose implementation is RECOMMENDED to implement access
-controls based upon "Secret Key Transaction Authentication for DNS"
-[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )"
-[RFC2931].
-
-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." For example, a default could
-be to restrict transfers to addresses selected by the DNS
-administrator(s) for zones on the server.
-
-6 Zone Integrity
-
-An AXFR client MUST ensure that only a successfully transferred
-copy of the zone data can be used to serve this zone. Previous
-description and implementation practice have introduced a two-stage
-model of the whole zone synchronization procedure: Upon a trigger
-event (e.g., polling of SOA resource record detects change in the
-SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session
-is initiated, whereby the zone data are saved in a zone file or
-data base (this latter step is necessary anyway to ensure proper
-restart of the server); upon successful completion of the AXFR
-operation and some sanity checks, this data set is 'loaded' and
-made available for serving the zone in an atomic operation, and
-flagged 'valid' for use during the next restart of the DNS server;
-if any error is detected, this data set MUST be deleted, and the
-AXFR client MUST continue to serve the previous version of the zone,
-if it did before. The externally visible behavior of an AXFR client
-implementation MUST be equivalent to that of this two-stage model.
-
-If a server rejects data contained in an AXFR session, the server
-SHOULD remember the serial number and MAY attempt to retrieve the
-same zone version again. The reason the same retrieval could make
-sense is that the reason for the rejection could be rooted in an
-implementation detail of one AXFR server used for the zone and not
-in another AXFR server used for the zone.
-
-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 connections, 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 the 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 the extent of
-an implementation's compatibility the greater 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 implementer's desire to maintain interoperability.
-
-It is unfortunate that a need to fall back to older behavior cannot be
-discovered, hence needs 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 be set by configuration.
-
-An implementation of an AXFR server MAY permit configuring, on a per
-AXFR client basis, a need to revert to single resource record per
-message; in that case, the default SHOULD be to use multiple records
-
-7.2 Client
-
-An AXFR client has the opportunity to try other features (i.e., those
-not defined by this document) when querying an AXFR server.
-
-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
-
-The AXFR protocol is transparent to the parts of DNS zone content that
-can possibly be subject to Internationalization considerations.
-It is assumed that for DNS labels and domain names, the issue 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."
-
-Comments since the -05 version have come from these individuals:
-Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain
-Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington,
-and other participants of the DNSEXT working group.
-
-12 References
-
-All references prefixed by "RFC" can be obtained from the RFC Editor
-web site at the URLs: http://rfc-editor.org/rfc.html
-or http://rfc-editor.org/rfcsearch.html ;
-information regarding this organization can be found at the following
-URL: http://rfc-editor.org/
-
-12.1 Normative
-
-[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
- September 1981.
-[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
- 1980.
-[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-[RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
- and Support", STD 3, RFC 1123, October 1989.
-[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC 1996, August 1996.
-[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC
- 2136, April 1997.
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations",
- BCP 42, RFC 5395, November 2008.
-[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
-[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006
-[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of Existence",
- RFC 5155, March 2008
-[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication
- Code, Secure Hash Algorithm) TSIG Algorithm Identifiers",
- RFC 4635, August 2006.
-[DNSFLGS] http://www.iana.org/assignments/dns-header-flags
-[DNSVALS] http://www.iana.org/assignments/dns-parameters
-
-12.2 Informative
-
-[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700,
- October 1994.
-[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
- Malis, "A Framework for IP Based Virtual Private Networks",
- RFC 2764, February 2000.
-[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", RFC
- 3490, March 2003.
-[DRAFT1] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and
- RRSIG Resource Records for DNSSEC",
- draft-ietf-dnsext-dnssec-rsasha256-12, work in progress.
-[DRAFT2] Weiler, S., and D. Blacka, "Clarifications and Implementation
- Notes for DNSSECbis",
- draft-ietf-dnsext-dnssec-bis-updates-08, work in progress.
-
-13 Editor's Address
-
-Edward Lewis
-46000 Center Oak Plaza
-Sterling, VA, 22033, US
-+1-571-434-5468
-ed.lewis@neustar.biz
projects / thirdparty / bind9.git / commitdiff
