Andreas Gustafsson draft-ietf-dnsext-axfr-clarify-05.txt NominumEdward Lewis draft-ietf-dnsext-axfr-clarify-06.txt NeuStar, Inc. November 2002DNSEXT WG January 2008 Updates: 1034, 1035 (if approved) Intended status: Standards Track DNS Zone Transfer Protocol Clarifications(AXFR) Status of this Memo This documentBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is an Internet-Draftaware have been or will be disclosed, and isany of which he or she becomes aware will be disclosed, in full conformanceaccordance with all provisions ofSection 106 of RFC2026.BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txthttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract In theThe Domain Name System,System standard facilities for maintaining coherent servers for a zone dataconsist of three elements. The Authoritative Transfer (AXFR) is replicated among authoritative DNS servers by meansdefined in RFC 1034 and RFC 1035. The Incremental Zone Transfer (IXFR) is defined in RFC 1995. A mechanism for prompt notification of the "zone transfer" protocol, also known as the "AXFR" protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specificationzone changes (NOTIFY) is defined in RFC1034. 1. IntroductionRFC 1996. The originalbase definition of the DNS zone transfer protocol consiststhese facilities, that of a single paragraphthe AXFR, has proven insufficient in [RFC1034] section 4.3.5 and some additional notesdetail, resulting in [RFC1035] section 6.3. It is not sufficiently detailed to serve as the sole basis for constructing interoperable implementations.no implementation complying with it. Yet today we have a satisfactory set of implementations that do interoperate. This document is an attempt to providea more completenew definition of the protocol. Where the textAXFR, new in RFC1034 conflicts with existing practice,the existing practice has been codifiedsense that is it recording an accurate definition of an interoperable AXFR mechanism. 1 Introduction The Domain Name System standard facilities for maintaining coherent servers for a zone consist of three elements. The Authoritative Transfer (AXFR) is defined in RFC 1034 [RFC1034] and RFC 1035 [RFC1035]. The Incremental Zone Transfer (IXFR) is defined in RFC 1995 [RFC1995]. A mechanism for prompt notification of zone changes (NOTIFY) is defined in RFC 1996 [RFC1996]. The goal of these mechanisms is to enable a set of DNS name servers to remain coherently authoritative for a given zone. Comments on this draft should be addresses to the interesteditor or to firstname.lastname@example.org. 1.1 Definition of interoperability.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 [RFC 2119]. 2. The zone transfer request To initiate a zone transfer, the slave server sends a zone transfer request"Key words for use in RFCs to Indicate Requirement Levels" [BCP14]. 1.2 Scope In the master server overgreater context, there are many ways to achieve coherency among a reliable transport such as TCP. The formset of this request is specified in sufficient detailname servers. These mechanisms form just one, the one defined in RFC1034 and needs no further clarification. Implementersthe RFCs cited. For example, there are advisedDNS implementations that one server implementationassemble answers from data riding in widespread use sends AXFR requests where the TCP message envelope size exceeds the DNS request message size by two octets. 3. The zone transfer response Ifcommercial database instances, and rely on the master server is unabledatabase's proprietary or unwillingotherwise external-to-DNS means to synchronize the database instances. Some of these non-DNS solutions may even interoperate in some fashion. As far as it is known, AXFR, IXFR, and NOTIFY are the only mechanisms that provide an interoperable solution to the desire for coherency within the definition of DNS. This document does not cover incoherent DNS situations. There are applications of the DNS in which servers for a zone transfer, it MUST respond withare designed to be incoherent. For these configurations, a coherency mechanism as described here would be unsuitable. "General purpose" DNS implementation refers to DNS software developed for wide spread use. This includes resolvers and servers freely accessible as libraries and standalone processes. This also includes proprietary implementations used only in support of DNS service offerings. "Turnkey" DNS implementation refers to custom made, single use implementations of DNS. Such implementations consist of software the use the DNS protocol message containing an appropriate RCODE other than NOERROR. If the masterformat but does not conform to entire range of DNS functionality. A DNS implementation is not authoritative for the requested zone, the RCODErequired to support AXFR, IXFR, and NOTIFY. A DNS implementation SHOULD be 9 (NOTAUTH). Slave servers should note thathave some mastermeans for maintaining name server coherency. A general purpose DNS implementation SHOULD include AXFR, IXFR, and NOTIFY, but turnkey DNS implementations will simply closeMAY operate without it. 1.3 Context Besides describing the connection when denyingmechanisms themselves, there is the slave accesscontext 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 zone. Therefore, slaves MAY interpret an immediate graceful closeoriginal definition of AXFR, new opinions have appeared on the TCP connection as equivalentaccess to a "Refused" response (RCODE 5). If a zone transfer canan entire zone's contents. In this document, the basic mechanisms will be provided,discussed separately from the master server sends one or more DNS messages containingpermission to use these mechanisms. 1.4 Coverage This document concentrates on just the zone data as described below. 3.1. Multiple answers per message The zone datadefinition of AXFR. Any effort to update the IXFR or NOTIFY mechanisms would be done in a zone transfer responsedifferent documents. This is not strictly a sequenceclarification of answer RRs. These RRs are transmitted inthe answer section(s) ofdefinition in RFC 1034 and RFC 1035. This document will update those sections, invalidate at least one or more DNS response messages.part of that definition. The goal of this document is define AXFR protocol definition in RFC1034 does not make a clear distinction between response messagesas it exists, or should exist, currently. 2 AXFR Messages An AXFR message exchange (or session) consists of an AXFR Query message and answer RRs. Historically, DNS servers always transmitteda single answer RR per message. This encodingset of AXFR Response messages. In this document, AXFR client is wasteful due tothe overheadsender of repeatedly sending DNS message headersthe AXFR Query and the lossAXFR server is the responder. (Use of domain name compression opportunities. To improve efficiency, some newer servers support a mode where multiple RRsterms such as master, slave, primary, secondary are transmitted in a single DNS response message. A master MAY transmit multiple answer RRs per response message upnot important to defining the AXFR exchange.) The reason for the largestimbalance in number that willof messages derives from large zones whose contents cannot be fit withininto the 65535 bytelimited permissible size of a DNS message. The upper limit on TCP DNS message size. Inthe casepermissible size of a small zone, this can cause the entire transfer to be transmittedDNS message is defined in a single response message. Slaves MUST accept messages containing any number[RFC2671], see section 4.5. The basic format of answer RRs. For compatibility with old slaves, masters that support sending multiple answers peran AXFR message SHOULD be configurable to revert to the historical mode of one answer per message, andis the configuration SHOULD be settable on a per-slave basis. 3.2.DNS message header contents RFC1034 does not specifyas defined in RFC 1035, Section 4 ("MESSAGES") [RFC 1035], updated by the contentsfollowing documents: RFC3425 [RFC3425], RFC1996 [RFC 1996], RFC2136 [RFC2136], [RFC4035], RFC4635 [RFC4635]. In addition, one change is credited to IANA, the reserving of OPCODE = 3. Field names used in this document will correspond to the names as the appear in the IANA registry for DNS message headerHeader Flags [DNS-FLAGS]. 2.1 AXFR Query An AXFR Query is sent by a client whenever there is a reason to ask. This may be because of thezone transfer response messages. The header of each message MUST bemaintenance activities or as follows:a result of a command line request, say for debugging. 2.1.1 Header Values ID Copy from requestSee note 2.1.1.a QR 1MUST be 0 (Query) OPCODE QUERY AA 1, but MAYMUST be 0 when RCODE is not NOERROR(Standard Query) AA See note 2.1.1.b TC 0See note 2.1.1.b RD Copy from request, or 0See note 2.1.1.b RA Set according to availability of recursion, or 0See note 2.1.1.b Z 0See note 2.1.1.c AD 0See note 2.1.1.b CD 0See note 2.1.1.b RCODE NOERROR on success, error code otherwise The slaveMUST check the RCODE in each message and abortbe 0 (No error) QDCOUNT MUST be 1 ANCOUNT MUST be 0 NSCOUNT MUST be 0 ARCOUNT MUST be either 0 or 1, the transferlatter only if itEDNS0 [RFC2671] is not NOERROR. It SHOULD check the ID ofin use Note 2.1.1.a Set to any value that the first message received and abortclient desires. There is no specified means for selecting the transfer ifvalue in this field. However, consideration can be given to making it does not match the ID ofharder for forged messages to be accepted by referencing the request.work in progress "Measures for making DNS more resilient against forged answers" [D-FORGERY]. Note 2.1.1.b The ID SHOULD be ignoredvalue in subsequent messages, and fields other than RCODE and ID SHOULD be ignoredthis field has no meaning in all messages, to ensure interoperabilitythe context of AXFR. For the client, RECOMMENDED that the value be zero. For the server, RECOMMENDED ignoring this value. Note 2.1.1.c The Z bit is no longer registered with certain older implementations which transmit incorrect or arbitrary values in these fields. 3.3. Additional section and SIG processing Zone transfer responses are not subjectIANA (no document cited for change). RECOMMENDED client set to any kind0, server MUST ignore. 2.1.2 Query Section The Query section of additionalthe AXFR query MUST conform to section processing or automatic inclusion4.1.2 of RFC 1035 contain the following values: QNAME the name of SIG records. SIG RRs inthe zone data are treated exactlyrequested QTYPE AXFR [DNS-VALUES] QCLASS the same as any other RR type. 3.4.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 question section RFC1034client MAY include an EDNS0 section. If the server has indicated that it does not specify whether zone transfer response messages havesupport EDNS0, the client MUST send this section empty if there is a questionretry. If the client is aware that the server does not support EDNS0, RECOMMENDED that this section or not. The initial messagebe sent empty. A client MAY become aware of a zone transfer response SHOULD haveserver's abilities via a question section identical to that in the request. Subsequent messages SHOULD NOT haveconfiguration setting. An implementation of a question section, though the final message MAY.general purpose client and server is RECOMMENDED to support EDNS0. 2.2 AXFR Response The receiving slaveAXFR Response will consist of 0 or more messages. A server MAY elect to ignore the request altogether. The first response MUST accept any combination of messagesbegin with and without a question section. 3.5. The authority section The master serverthe SOA resource record of the zone, the last response MUST transmit messagesconclude with an empty authority section. Slavesthe same SOA resource record. Intermediate responses MUST ignore any authority section contents they may receive from masters that donot comply with this requirement. 3.6. The additional section The additional section MAYcontain additional RRs such as transaction signatures. The slavethe SOA resource record. 2.2.1 Header Values ID See note 2.2.1.a QR MUST ignore any unexpected RRsbe 1 (Response) OPCODE MUST be 0 (Standard Query) AA See note 2.2.1.b TC MUST be 0 (Not truncated) RD RECOMMENDED copy request's value, MAY be set to 0 RA See note 2.2.1.c Z See note 2.2.1.d AD See note 2.2.1.e CD See note 2.2.1.e RCODE See note 2.2.1.f QDCOUNT MUST be 1 in the additional section. Itfirst message; MUST NOT treat additionalbe 0 or 1 in all following ANCOUNT See note 2.2.1.g NSCOUNT MUST be 0 ARCOUNT MUST be either 0 or 1, the latter only if EDNS0 [RFC2671] is in use Note 2.2.1.a Because of old implementations, the requirement on this section RRsis stated in detail. New DNS servers MUST set this field to the value of the AXFR Query ID in each AXFR Response message for the session. New DNS clients MUST be able to accept sessions in which the responses do not have the same ID field. If a client detects or is aware that the server is new, that is, all of the responses have the same ID value as the query, the client MAY issue other DNS queries (of any type) to the server using the same transport. Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone data. 4. Zone data The purposetransfer. A client MAY become aware of a server's abilities via a configuration setting. Note 2.2.1.b If the RCODE is 0 (no error), then the AA bit MUST be 1. For any other value of RCODE, the AA bit MUST be set according to rules for that error code. If in doubt, RECOMMENDED setting to 1, RECOMMENDED ignoring the value otherwise. Note 2.2.1.c RECOMMENDED server setting value to 0, RECOMMENDED client ignoring this value. The server MAY set this value according to the local policy regarding recursive service, but doing so may confuse the interpretation of the response as AXFR MAY NOT be retrieved recursively. A client MAY note the server's policy regarding recursive from this value, but SHOULD NOT conclude that the AXFR response was obtained recursively even if the RD bit was 1 in the query. Note 2.2.1.d The Z bit is no longer registered with IANA (no document cited for change). RECOMMENDED client set to 0, server MUST ignore. Note 2.2.1.e If the implementation is implementing DNSSEC [RFC4033-5], this value MUST be set according to the rules in RFC 4035 [RFC4035], section 3.1.6, "The AD and CD Bits in an Authoritative Response." If the implementation is not implementing DNSSEC, then this value MUST be set to 0 an MUST be ignored. Note 2.2.1.f In the absence of an error, the server MUST set the value of this field to NoError. If a server is not authoritative for the queried zone, the server SHOULD set the value to NotAuth. (Reminder, consult the appropriate IANA registry [DNS-VALUES].) If a client receives any other value in response, it MUST act according to the error. For example, a malformed AXFR query or the presence of an EDNS0 OPT resource record sent to an old server will garner a FormErr value. This value is not set as part of the AXFR response processing. The same is true for other error-indicating values. Note 2.2.1.g The count of answer records MUST equal the number of resource records in the AXFR Answer Section. When a server is aware that a client will only accept one resource record per response message, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data. 2.2.2 Query Section In the first response message, this section MUST be copied from the query. In subsequent messages this section MAY be copied from the query, MAY be empty. The content of this section MAY be used to determine the context of the message, that is, the name of the zone being transfered. 2.2.3 Answer Section MUST be populated with the zone contents. See later section on encoding zone contents. 2.2.4 Authority Section MUST be empty. 2.2.5 Additional Section If the query included an EDNS0 OPT RR this section MAY include an OPT RR in reply. If the query had an empty Additional Section, this MUST be empty. A client MAY ignore the contents of this section. 3 Zone Contents The objective of the AXFR session is to request and transfer the contents of a zone. The objective is to permit the client to reconstruct the zone as it exists at the server for the given zone serial number. Over time the definition of a zone has evolved from a static set of records to a dynamically updated set of records to a continually regenerated set of records. 3.1 Records to Include In the answer section of AXFR response messages the resource records within a zone for the given serial number MUST appear. The definition of what belongs in a zone is described in RFC 1034, Section 4.2, "How the database is divided into zones", and in particular, section 4.2.1., "Technical considerations." The first resource record of the first AXFR response message sent by the AXFR server MUST be the zone's SOA resource record. The last resource record of the final AXFR response message sent by the AXFR server MUST be the zone's SOA resource record. The order and grouping of all other records in the AXFR is arbitrary, but the AXFR server SHOULD group resource record sets together and transmit in the same AXFR message. Unless the AXFR server knows that the AXFR client expects just one resource record per AXFR response message, an AXFR server SHOULD populate an AXFR response message with as many complete resource records as will fit within the limited permissible message size. Zones for which it is impractical to list the entire zones for a serial number (because changes happen too quickly) are not suitable for AXFR retrieval. 3.2 Delegation Records In RFC 1034, section 4.2.1, this text appears (keep in mind that the use of the word "should" in the quotation is exempt from the interpretation in section 1.1) "The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone." There has been some controversy over this statement and the impact on which NS resource records are included in a zone transfer. The issue is that in operations there are times when the NS resource records for a zone might be different at a cut point in the parent and at the apex of a zone. Sometimes this is the result of an error and sometimes it is part of an ongoing change in name servers. The DNS protocol is robust enough to overcome inconsistencies up to there being no parent indicated NS resource record referencing a server that is able to serve the child zone. This robustness is one quality that has fueld the success of the DNS. Still, the inconsistency is a error state and steps need to be taken to make it apparent (if it is unplanned) and to make it clear once the inconsistency has been removed. Another issue is that the AXFR server could be authoritative for a different set of zones than the AXFR client. It is possible that the AXFR server may be authoritative for both halves of an inconsistent cut point and that the AXFR client is authoritative for just the parent of the cut point. The question that arises is, when facing a situation in which a cut point's NS resource records do not match the authoritative set, whether an AXFR server responds with the NS resource record set that is in the zone or is at the authoritative location. The AXFR response MUST contain the cut point NS resource record set registered with the zone whether it agrees with the authoritative set or not. "Registered with" can interpreted as residing in the zone file of the zone for the particular serial number (in zone file environments) or as any data configured to be in the zone, statically or dynamically. The reasons for this requirement are: 1) The AXFR server might not be able to determine that there is an inconsistency given local data, hence requiring consistency would mean a lot more needed work and even network retrieval of data. An authoritative server ought not be required to perform any queries. 2) By transferring the inconsistent NS resource records from a server that is authoritative for both the cut point and the apex to a client that is not authoritative for both, the error is exposed. For example, an authorized administrator can manually request the AXFR and inspect the results to see the inconsistent records. (A server authoritative for both halves would otherwise always answer from the more authoritative set, concealing the error.) 3) The inconsistent NS resource record set might indicate a problem in a registration database. The DNS shouldn't cover this over. 3.3 Glue Records As in the previous section, RFC 1034, section 4.2.1, provides guidance and rationale for the inclusion of glue records as part of an AXFR transfer. And, as also argued in the previous section of this document, even when there is an inconsistency between the address in a glue record and the authoritative copy of the name server's address, the glue resource record that is registered as part of the zone for that serial number is to be included. This applies for glue records for any address family. 3.4 Name Compression Compression of names in DNS messages is described in RFC 1035, section 4.1.4, "Message compression". The issue highlighted here relates to a comment made in RFC 1034, section 3.1, "Name space specifications and terminology" which says "When you receive a domain name or label, you should preserve its case." Name compression in an AXFR message MUST preserve the case of the original domain name. That is, although when comparing a domain name, "a" equals "A", when comparing for the purposes of message comparison, "a" is not equal to "A". Name compression of RDATA in an AXFR message MAY only be done on resource record types which explicitly permit such compression. 4 Transport AXFR sessions are restricted by RFC 1034, section 4.3.5's "because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests." With the addition of EDNS0 and applications which require many small zones such in web hosting and some ENUM scenarios, AXFR sessions on UDP are now possible and desirable. In addition, it is conceivable to interleave requests for other data or AXFRs of other zones during one session in TCP if the ID values are consistently maintained. 4.1 TCP In the original definition there is an implicit assumption that a TCP connection is used for one and only one AXFR session. This is evidenced in no requirement to maintain neither the query section nor the message ID in responses and the lack of an explicit bit indicating that a zone transfer continues in the next message. Once an AXFR client opens a connection and sends an AXFR query, the AXFR server MAY close the connection without a reply. Such an action is to be interpreted as refusal to honor the request. This option was not originally defined but has proven to be one way to stop abusive behaviors by clients attempting to use up the server's available resources for TCP activity. Accommodation for implementations assuming this can be maintained, but newer implementations MAY choose to use the open TCP connection for other queries and AXFR sessions of other zones. An AXFR client MAY send a subsequent request to the AXFR server while the AXFR server is responding to a previous query. If this action causes the AXFR server to stop the original AXFR, the AXFR client SHOULD not try this again with that AXFR server. An AXFR server MAY opt to respond to other queries while responding the original AXFR query that opened the connection. An AXFR server MAY ignore or even close the connection if there are two outstanding AXFR queries for the same zone on a connection, as this could be evidence of an abusive AXFR client. 4.2 UDP AXFR sessions over UDP are not included in the base specification of DNS. Given the definition of AXFR, probably for good reason. But there are applications in which AXFR over UDP just might work. With expanded DNS messages made possible by EDNS0, it can be possible to fit an entire zone's contents in to one DNS message. Reasons not to do AXFR over UDP include cases where multiple AXFR messages are needed for a zone, there is no way to guarantee all AXFR messages will arrive at the AXFR client and no way to detect a dropped AXFR message. If an AXFR server cannot place the entire contents of the requested zone in one AXFR response message, the AXFR server MAY silently drop the request or MAY send a response with an return code of SERVFAIL. If an AXFR client does not receive a reply to an AXFR query over UDP or receives a SERVFAIL response code, the client SHOULD retry the request via TCP. 5 Authorization A zone transfer mechanism isadministrator has the option to exactly replicate at each slaverestrict AXFR access to a zone. This was not envisioned in the setoriginal design of RRs associated withthe DNS but has emerged as a particular zone at its primary master. An RR is associated withrequirement as the DNS has evolved. Restrictions on AXFR could be for various reasons including a zone by being loaded fromdesire to keep the master filebulk version of that zone atthe primary master server, or by some other, equivalent method for configuringzone data. This replication shall be complete and unaltered, regardless of how many and which intermediate masters/slaves are involved, and regardless of what other zones those intermediate masters/slaves doconcealed or do not serve, and regardless of what data may be cached in resolvers associated withto prevent the servers from handling the intermediate masters/slaves. Therefore,load incurred in a zone transferserving AXFR. All reasons are arguable, but the master MUST send exactly those recordsfact remains that are associated withthere is a requirement to provide mechanisms to restrict AXFR. A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients. By default, a DNS implementation SHOULD only allow the zone,designated authoritative servers to have access to the zone. An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges, regardless of whether a source address could be spoofed. Combining this with techniques such as Virtual Private Networks (VPN) [RFC2764] or not their owner names wouldVirtual LANs has proven to be consideredeffective. An implementation SHOULD allow access to be "in" the zonegranted based upon "Secret Key Transaction Authentication for purposes of resolution,DNS" [RFC2845] and/or "DNS Request and whether or not they wouldTransaction Signatures ( SIG(0)s )" [RFC2931]. An implementation SHOULD allow access to be eligible for use as glue in responses. The transfer MUST NOT include any RRsopen to all requests. 6 Zone Integrity Ensuring that arean AXFR client does not associated with the zone, such as RRs associated with zones other than the one being transferred or present in the cacheaccept a forged copy of the local resolver, even if their owner names are in the zone being transferred or are pointed to by NS records in thea zone being transferred. The slave MUST associateis important to the RRs received insecurity of a zone. If a zone transfer withoperator has the specificopportunity, protection can be afforded via dedicated links, physical or virtual via a VPN among the authoritative servers. But there are instances in which zone being transferred,operators have no choice but to run AXFR sessions over the global public Internet. Besides best attempts at securing TCP sessions, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS" [RFC2845] and/or "DNS Request and maintain that associationTransaction Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the contents. These techniques MAY also be used for purposesauthorization. 7 Backwards Compatibility Describing backwards compatibility is difficult because of acting asa masterlack of specifics in outgoing transfers. 5. Transmission order RFC1034 states that "The first and last messages must contain the data forthe top authoritative node oforiginal definition. In this section some hints at building in backwards compatibility are given, mostly repeated from the zone". Thisearlier sections. Backwards compatibility is not consistent with existing practice. All known masternecessary, but the greater extent of an implementation's compatibility increases it's interoperability. For turnkey implementations send, and slavethis is not usually a concern. For general purpose implementations expect to receive,this takes on varying levels of importance depending on the zone's SOA RRimplementers desire to maintain interoperability. It is unfortunate that needs to fall back to older behavior cannot be discovered, hence need to be noted in a configuration file. An implementation SHOULD, in it's documentation, encourage operators to periodically review AXFR clients and servers it has made notes about as old software periodically gets updated. 7.1 Server An AXFR server has the first and last recordluxury of being able to react to an AXFR client's abilities with the transfer. Therefore,exception of knowing if the quoted sentenceclient can accept multiple resource records per AXFR response message. The knowledge that a client is hereby superseded by the sentence "The first and last RR transmitted mustso restricted apparently cannot be the SOA recorddiscovered, hence it has to set by configuration. An implementation of the zone". The initial and final SOAan AXFR server SHOULD permit configuring on a per AXFR client basis a need to revert to single resource record MUSTper message. The default SHOULD be identical, with the possible exception of case and compression. In particular, they MUST haveto use multiple records per message. 7.2 Client An AXFR client has the same serial number.opportunity to try extensions when querying an AXFR server. The slave MUST consideruse of EDNS0 to increase the transferDNS message size, offer authorizing proof, or to invoke message integrity can be complete when,tried and only when, it has receivedrejected by the message containingAXFR server via the second SOA record. The transmission ordermethods already described as part of all other RRs inthe zone is undefined. Each of themEDNS0 mechanism. If an AXFR client attempts to use the UDP transport, non-response from the AXFR server or other error message can indicate not to retry that. Attempting to issue multiple DNS queries over a TCP transport for an AXFR session SHOULD be transmitted only once, and slaves MUST ignore any duplicate RRs received. 6. Security Considerations The zone transfer protocol as defined in [RFC1034]aborted if it interrupts the original request and clarified by this memo does not have any built-in mechanisms forSHOULD take into consideration whether the slaveAXFR server intends to securely verifyclose the identityconnection immediately upon completion of the master serveroriginal (connection-causing) zone transfer. 8 Security Considerations Concerns regarding authorization, traffic flooding, and themessage integrity of the transferred zone data. The use of a cryptographic mechanism for ensuring authenticityare mentioned in "Authorization" (section 5), "TCP" (section 4.2) and integrity, such as TSIG [RFC2845], IPSEC,Zone Integrity (section 6). 9 IANA Considerations No new registries or TLS, is RECOMMENDED. The zone transfer protocol allows read-only public access to the complete zone data. Since datanew registrations are included in the DNS is public by definition,this document. 10 Internationalization Considerations It is generally acceptable. Sitesassumed that wish to avoid disclosing their full zone data MAY restrict zone transfer access to authorized slaves. These clarifications are not believed to themselves introduce any new security problems, nor to solve any existing ones.supporting of international domain names has been solved via "Internationalizing Domain Names in Applications (IDNA)" [RFC3490]. 11 Acknowledgements ManyEarlier 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.Wellington." 12 References 12.1 Normative [RFC1034] "Domain names - Domain Names - Conceptsconcepts and Facilities, P. Mockapetris, November 1987.facilities.", P.V. Mockapetris. Nov-01-1987. [RFC1035] "Domain names - Domain Names - Implementationimplementation and Specifications,specification." P.V. Mockapetris. Nov-01-1987. [RFC1995] "Incremental Zone Transfer in DNS." M. Ohta. August 1996. [RFC1996] "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)." P. Mockapetris, November 1987. [RFC2119] -Vixie. August 1996. [RFC2136] "Dynamic Updates in the Domain Name System (DNS UPDATE)." P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. [RFC2671] "Extension Mechanisms for DNS (EDNS0)." P. Vixie. August 1999. [RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)." P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. May 2000. [RFC2930] "Secret Key Establishment for DNS (TKEY RR)." D. Eastlake. September 2000. [RFC3425] "Obsoleting IQUERY." D. Lawrence. November 2002. [RFC4033-5] "DNS Security Introduction and Requirements," "Resource Records for the DNS Security Extensions," and "Protocol Modifications for the DNS Security Extensions." R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. [RFC4035] "Protocol Modifications for the DNS Security Extensions." R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. March 2005. [RFC4635] "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers." D. Eastlake 3rd. August 2006. [DNS-FLAGS] http://www.iana.org/assignments/dns-header-flags [DNS-VALUES] http://www.iana.org/assignments/dns-parameters 12.2 Informative [BCP14] "Key words for use in RFCs to Indicate Requirement Levels,Levels." S. Bradner, BCP 14,Bradner. March 1997. [RFC2845] - Secret Key Transaction Authentication[RFC2764] "A Framework for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake,IP Based Virtual Private Networks." B. Wellington, MayGleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. Author's[RFC3490] "Internationalizing Domain Names in Applications (IDNA)." P. Faltstrom, P. Hoffman, A. Costello. March 2003. [D-FORGERY] "Measures for making DNS more resilient against forged answers." A. Hubert, R. van Mook. Work in Progress. http://www.ietf.org/internet-drafts/ draft-ietf-dnsext-forgery-resilience-01.txt 13 Editor's Address Andreas Gustafsson Nominum Inc. 2385 Bay Rd Redwood City, CA 94063 USA Phone: +1 650 381 6004 Email: email@example.comEdward Lewis 46000 Center Oak Plaza Sterling, VA, 22033, US +1-571-434-5468 firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.IETF Trust (2008). This document and translations of it may be copied and furnishedis subject to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided thatthe above copyright notice and this paragraph are included on all such copiesrights, licenses and derivative works. However, this document itself may not be modifiedrestrictions contained in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78, and except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked byset forth therein, the Internet Society or its successors or assigns.authors retain all their rights. This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETYSOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).