From: Mark Andrews Date: Tue, 8 Dec 2009 04:57:40 +0000 (+0000) Subject: new draft X-Git-Tag: v9.4.3-P1~1^10^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4d0f4a9d3cccaef80023de684ddc9a6aae1cc574;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt deleted file mode 100644 index 5278587ddb3..00000000000 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt +++ /dev/null @@ -1,1058 +0,0 @@ -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 diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt new file mode 100644 index 00000000000..b0a269b1113 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-12.txt @@ -0,0 +1,1579 @@ + + + + + +DNS Extensions Working Group Edward Lewis +Internet-Draft NeuStar, Inc. +Updates: 1034, 1035 (if approved) A. Hoenes +Intended status: Standards Track TR-Sys +Expires: June 6, 2010 December 6, 2009 + + + DNS Zone Transfer Protocol (AXFR) + draft-ietf-dnsext-axfr-clarify-12 + +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) defined in RFC 1034 and RFC 1035. + The definition of AXFR has proven insufficient in detail, thereby + 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 AXFR -- new in the sense that is it recording an + accurate definition of an interoperable AXFR mechanism. + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. This document may contain material + from IETF Documents or IETF Contributions published or made publicly + available before November 10, 2008. The person(s) controlling the + copyright in some of this material may not have granted the IETF + Trust the right to allow modifications of such material outside the + IETF Standards Process. Without obtaining an adequate license from + the person(s) controlling the copyright in such materials, this + document may not be modified outside the IETF Standards Process, and + derivative works of it may not be created outside the IETF Standards + Process, except to format it for publication as an RFC or to + translate it into languages other than English. + + 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 + + + +Lewis & Hoenes Expires June 6, 2010 [Page 1] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This Internet-Draft will expire on June 6, 2010. + +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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 2] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 + 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Coverage and Relationship to Original AXFR Specification . 5 + 2. AXFR Messages . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. AXFR query . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.1.1. Header Values . . . . . . . . . . . . . . . . . . . . . 9 + 2.1.2. Question Section . . . . . . . . . . . . . . . . . . . . 10 + 2.1.3. Answer Section . . . . . . . . . . . . . . . . . . . . . 10 + 2.1.4. Authority Section . . . . . . . . . . . . . . . . . . . 10 + 2.1.5. Additional Section . . . . . . . . . . . . . . . . . . . 10 + 2.2. AXFR Response . . . . . . . . . . . . . . . . . . . . . . 11 + 2.2.1. "0 Message" Response . . . . . . . . . . . . . . . . . . 11 + 2.2.2. Header Values . . . . . . . . . . . . . . . . . . . . . 12 + 2.2.3. Question Section . . . . . . . . . . . . . . . . . . . . 14 + 2.2.4. Answer Section . . . . . . . . . . . . . . . . . . . . . 14 + 2.2.5. Authority Section . . . . . . . . . . . . . . . . . . . 14 + 2.2.6. Additional Section . . . . . . . . . . . . . . . . . . . 14 + 2.3. TCP Connection Aborts . . . . . . . . . . . . . . . . . . 14 + 3. Zone Contents . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.1. Records to Include . . . . . . . . . . . . . . . . . . . . 15 + 3.2. Delegation Records . . . . . . . . . . . . . . . . . . . . 16 + 3.3. Glue Records . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.4. Name Compression . . . . . . . . . . . . . . . . . . . . . 18 + 3.5. Occluded Names . . . . . . . . . . . . . . . . . . . . . . 19 + 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1.1. AXFR client TCP . . . . . . . . . . . . . . . . . . . . 20 + 4.1.2. AXFR server TCP . . . . . . . . . . . . . . . . . . . . 21 + 4.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . 22 + 6. Zone Integrity . . . . . . . . . . . . . . . . . . . . . . . 23 + 7. Backwards Compatibility . . . . . . . . . . . . . . . . . . 24 + 7.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 25 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 + 10. Internationalization Considerations . . . . . . . . . . . . 25 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 12.2. Informative References . . . . . . . . . . . . . . . . . 27 + 13. Editor's Address . . . . . . . . . . . . . . . . . . . . . 28 + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 3] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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] (henceforth + 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. + + This document re-specifies the AXFR mechanism as it is deployed in + the Internet at large, hopefully with the precision expected from + modern Internet Standards, and thereby updates RFC 1034 and RFC 1035. + +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]. + + Use of "newer"/"new" and "older"/"old" DNS refers to implementations + written after and prior to the publication of this document. + + "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 does not conform to + the entire range of DNS functionality. + + The terms "AXFR session", "AXFR server" and "AXFR client" will be + introduced in the first paragraph of Section 2, after some more + context has been established. + +1.2. Scope + + In general terms, authoritative name servers for a given zone can use + various means to achieve coherency of the zone contents they serve. + For example, there are DNS implementations that assemble answers from + data stored in relational databases (as opposed to master files), + + +Lewis & Hoenes Expires June 6, 2010 [Page 4] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + relying on the database's non-DNS means to synchronize the database + instances. Some of these non-DNS solutions interoperate in some + fashion. However, AXFR, IXFR, and NOTIFY are the only protocol- + defined in-band mechanisms to provide coherence of a set of name + servers, and they are the only mechanisms specified 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. + + A DNS implementation is not required to support AXFR, IXFR, and + NOTIFY, but it should have some means for maintaining name server + coherency. A general purpose DNS implementation will likely support + AXFR (and in the same vein IXFR and NOTIFY), but turnkey DNS + implementations may exist without AXFR. + +1.3. Context + + Besides describing the mechanisms themselves, there is the context in + which they operate to consider. In the initial specifications of + AXFR (and IXFR and NOTIFY), little consideration was 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 specification of the IXFR or NOTIFY mechanisms + is left to 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. + + + +Lewis & Hoenes Expires June 6, 2010 [Page 5] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + This document will update the specification of AXFR. To this end, it + fully specifies the record formats and processing rules for AXFR, + largely expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and it + details 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 6] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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 + Section 4 ("MESSAGES") of RFC 1035 [RFC1035], updated by the + following documents. + + o The 'Basic' DNS specification: + + - "A Mechanism for Prompt Notification of Zone Changes (DNS Notify)" + [RFC1996] + - "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] + - "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] + - "Domain Name System (DNS) IANA Considerations" [RFC5395] + + o Further additions related to the DNS Security Extensions (DNSSEC), + 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] + - "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource + Records for DNSSEC" [RFC5702] + - "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U] + + These documents contain information about the syntax and semantics of + DNS messages. They ought not interfere with AXFR but are also + helpful in understanding what will be carried via AXFR. + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 7] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + For convenience, the synopsis of the DNS message header from + [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is + reproduced here informally: + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + This document makes use of the field names as they appear in this + diagram. The names of sections in the body of DNS messages are + capitalized in this document for clarity, e.g., "Additional section". + + The DNS message size limit from [RFC1035] for DNS over UDP (and its + extension via the EDNS0 mechanism specified in [RFC2671]) is not + relevant for AXFR, as explained in Section 4. The upper limit on the + permissible size of a DNS message over TCP is only restricted by the + TCP framing defined in Section 4.2.2 of RFC 1035, which specifies a + two-octet message length field, understood to be unsigned, and thus + causing a limit of 65535 octets. 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. + +2.1. AXFR query + + 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. + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 8] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +2.1.1. Header Values + + These are the DNS message header values for an AXFR query. + + ID Selected by client; see Note a) + + QR MUST be 0 (Query) + + OPCODE MUST be 0 (Standard Query) + + Flags: + AA 'n/a' -- see Note b) + TC 'n/a' -- see Note b) + RD 'n/a' -- see Note b) + RA 'n/a' -- see Note b) + Z 'mbz' -- see Note c) + AD 'n/a' -- see Note b) + CD 'n/a' -- see Note b) + + RCODE MUST be 0 (No error) + + QDCOUNT Number of entries in Question section; MUST be 1 + + ANCOUNT Number of entries in Answer section; MUST be 0 + + NSCOUNT Number of entries in Authority section; MUST be 0 + + ARCOUNT Number of entries in Additional section -- see Note d) + + Notes: + + 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 + -- see Section 4 "Transport".) + + A server MUST reply using messages that use the same message ID to + allow a client to have multiple queries outstanding concurrently + over the same TCP connection -- see Note a) in Section 2.2.2 for + more details. + + b) 'n/a' -- 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. + + c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore + it. + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 9] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + d) The client MUST set this field to 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. Question Section + + The Query section of the AXFR query MUST conform to Section 4.1.2 of + RFC 1035, and contain a single resource record with 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 [DNSVALS] + +2.1.3. Answer Section + + The Answer section MUST be empty. + +2.1.4. Authority Section + + The Authority section MUST be empty. + +2.1.5. Additional Section + + The client MAY include an EDNS0 OPT [RFC2671] resource record. If + the server does not support EDNS0, the client MUST send this section + without an EDNS0 OPT resource record if there is a retry. However, + the protocol does not define an explicit indication that the server + does not support EDNS0; that needs to be inferred by the client. + Often, the server will return a FormErr(1) 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 should not try again. Removing + + +Lewis & Hoenes Expires June 6, 2010 [Page 10] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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. Future resource + records residing in the Additional section might 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 AXFR server MUST copy the Question + section from the corresponding AXFR query message in to the first + response message's Question section. Subsequent messages MAY do the + same or contain an empty Question section. + + An AXFR response indicates an error via a single DNS message with the + return code set to the appropriate value for the condition + encountered, sent once the error condition is detected. Such a + message terminates 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 server may send a number of AXFR response messages free of an + error condition before it sends the message indicating an error. + +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 + + +Lewis & Hoenes Expires June 6, 2010 [Page 11] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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 nevertheless may not get one. + +2.2.2. Header Values + + These are the DNS message header values for AXFR responses. + + ID MUST be copied from request -- see Note a) + + QR MUST be 1 (Response) + + OPCODE MUST be 0 (Standard Query) + + Flags: + AA normally 1 -- see Note b) + TC MUST be 0 (Not truncated) + RD RECOMMENDED: copy request's value, MAY be set to 0 + RA SHOULD be 0 -- see Note c) + Z 'mbz' -- see Note d) + AD covered by DNSSEC rules -- see Note e) + CD covered by DNSSEC rules -- see Note e) + + RCODE See Note f) + + QDCOUNT MUST be 1 in the first message; + MUST be 0 or 1 in all following messages; + MUST be 1 if RCODE indicates an error + + ANCOUNT See Note g) + + NSCOUNT MUST be 0 + + ARCOUNT See Note h) + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 12] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + Notes: + + 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. + + 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 + the 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. + + 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. + + d) 'mbz' -- The server MUST set this bit to 0, the client MUST ignore + it. + + e) If the implementation supports the DNS Security Extensions (DNSSEC + -- see Section 2), 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. + + f) In the absence of an error, the server MUST set the value of this + field to NoError(0). If a server is not authoritative for the + queried zone, the server SHOULD set the value to NotAuth(9). + (Reminder, consult the appropriate IANA registry [DNSVALS].) If a + client receives any other value in response, it MUST act according + + +Lewis & Hoenes Expires June 6, 2010 [Page 13] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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(1) value. This value is not set as part of the AXFR- + specific response processing. The same is true for other values + indicating an error. + + 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. + + h) The client MUST set this field to the number of resource records + appearing in the Additional section. The considerations of Note + d) in Section 2.1.1 apply equally; see Section 2.2.6 "Additional + Section" below for more details. + +2.2.3. Question 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. However, in an error response message (see + Section 2.2), this section MUST be copied as well. 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 Section 3 below on + encoding zone contents. + +2.2.5. Authority Section + + The Authority section MUST be empty. + +2.2.6. Additional Section + + The contents of this section MUST follow the guidelines for EDNS0 and + TSIG, SIG(0), or whatever other future record is possible here. The + contents of Section 2.1.5 apply analogously 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. + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 14] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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 (e.g., RRs synthesized "on the fly" from rule sets or + database lookup results in other forms than RR format) 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 zone 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. + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 15] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +3.2. Delegation Records + + In Section 4.2.1 of RFC 1034, 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 was first + described in Sections 5.3 ff. and 6.2 of RFC 2181 (for the initial + specification of DNSSEC), which parts of RFC 2181 now in fact are + historical. The current DNSSEC core document set (see Note e) in + Section 2.2.2 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 + part of the authoritative data of the zone it serves. + + o Independent RRSIG RRSets occur at the signed parent side of a zone + cut and at the apex of a signed zone; they are authoritative data + in the respective zone; simple queries for RRSIG resource records + may return both 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 side 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. + + +Lewis & Hoenes Expires June 6, 2010 [Page 16] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + One 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 + side of the cut point. + + When facing a situation in which a cut point's NS resource records do + not match the authoritative set, the question arises whether an AXFR + server responds with the NS resource record set that is in the zone + being transferred or the one that 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. + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 17] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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 be authoritative for the child + zone as well. + + 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 [IANA-AF]. + + 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 + + +Lewis & Hoenes Expires June 6, 2010 [Page 18] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + 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. But variations of that + most simple scenario are legitimate and likely, in particular sending + a query for the zone's SOA resource record first over the same TCP + connection, and reusing an existing TCP connection for other queries. + + Therefore, the assumption that a TCP connection is dedicated to a + single AXFR session is incorrect. This wrong assumption has led to + implementation choices that prevent either multiple concurrent zone + transfers or the use of an open connection for other queries. + + Since the early days of the DNS, operators who have sets of name + servers that are authoritative for a common set of zones found it + desirable to be able to have multiple concurrent zone transfers in + progress; this way a name server does not have to wait for one zone + + +Lewis & Hoenes Expires June 6, 2010 [Page 19] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + transfer to complete before the next could begin. RFC 1035 did not + exclude this possibility, but legacy implementations missed to + support this functionality. The remaining presence of such legacy + implementations makes it necessary that new general purpose server + implementation still provide options for gracefull fallback to the + old behavior in their support of concurrent DNS transactions and AXFR + sessions on a single TCP connection. + +4.1. TCP + + In the original definition there arguably is an implicit assumption + (probably unintentional) that a TCP connection is used for one and + only one AXFR session. This is evidenced in the lack of an explicit + requirement to copy the Query section and/or the message ID into + 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 below is intended to enable better performance of + the AXFR exchange as well as provide 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, the server ought 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 can cancel the 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 + + +Lewis & Hoenes Expires June 6, 2010 [Page 20] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + disruption was a spurious event, attempting to restart the connection + would be proper. If the disruption was caused by a failure that + proved to be persistent, 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 over it. + + 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 + + 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 seem desirable. However, there are still some + aspects of AXFR sessions that are not easily translated to UDP. + + Therefore, this document does not update RFC 1035 in this respect: + AXFR sessions over UDP transport are not defined. + + + +Lewis & Hoenes Expires June 6, 2010 [Page 21] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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. It has been argued that these reasons are + questionable, but this document, driven by the desire to leverage the + interoperable practice that has evolved since RFC 1035, acknowledges + the factual 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. + + + + + + + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 22] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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 a 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 an AXFR client rejects data contained in an AXFR session, it + 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 + present 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. + + + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 23] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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 relevant earlier sections. + + Backwards compatibility is not necessary, but the greater the extent + of an implementation's compatibility the greater its + 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 its documentation, encourage operators to + periodically review AXFR clients and servers it has made notes about + repeatedly, as old software gets updated from time to time. + +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 whether the client + can accept multiple resource records per AXFR response message. The + knowledge that a client is so restricted 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, the necessity to revert to single resource record + per message; in that case, the default SHOULD be to use multiple + records per message. + +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. + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 24] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +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 + + [[ Note to RFC-Ed: this section may be deleted before publication. ]] + + 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] or its successor(s). + + +11. Acknowledgments + + Earlier editions of this document have been edited by Andreas + Gustafsson. In his latest version, this acknowledgment 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: + Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, + Ian Jackson, Andreas Gustafsson, Brian Wellington, and other + participants of the DNSEXT working group. + + Edward Lewis served as a patiently listening sole document editor for + two years. + +12. References + + All "RFC" references by 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/ + + +Lewis & Hoenes Expires June 6, 2010 [Page 25] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + +12.1. Normative References + + [BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [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. + + + +Lewis & Hoenes Expires June 6, 2010 [Page 26] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + [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. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006 + + [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication + Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", + RFC 4635, August 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008 + + [RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 5395, November 2008. + + [RFC5702] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", RFC 5702, + October 2009. + +12.2. Informative References + + [DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", + http://www.iana.org/assignments/dns-parameters + + [IANA-AF] IANA Registry "Address Family Numbers", + http://www.iana.org/assignments/Address-family-numbers/ . + + [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. + Malis, "A Framework for IP Based Virtual Private + Networks", RFC 2764, February 2000. + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 27] + +Internet-Draft DNS Zone Transfer Protocol (AXFR) December 2009 + + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + [DNSSEC-U] Weiler, S., and D. Blacka, "Clarifications and + Implementation Notes for DNSSECbis", + draft-ietf-dnsext-dnssec-bis-updates-09 (work in + progress), September 2009. + + +13. Editors' Addresses + + Edward Lewis + 46000 Center Oak Plaza + Sterling, VA, 22033, US + + Email: ed.lewis@neustar.biz + + + Alfred Hoenes + TR-Sys + Gerlinger Str. 12 + Ditzingen D-71254 + Germany + + Email: ah@TR-Sys.de + + +Editorial Note: Discussion [[ to be removed by RFC-Editor ]] + + Comments on this draft ought to be addressed to the editors and/or to + namedroppers@ops.ietf.org. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lewis & Hoenes Expires June 6, 2010 [Page 28] +