Internet Engineering Task Force (IETF) E. Lewis
Request for Comments: 5936 NeuStar, Inc.
Updates: 1034, 1035 A. Hoenes, Ed.
Category: Standards Track TR-Sys
ISSN: 2070-1721 June 2010
Internet Engineering Task Force (IETF) E. Lewis
Request for Comments: 5936 NeuStar, Inc.
Updates: 1034, 1035 A. Hoenes, Ed.
Category: Standards Track TR-Sys
ISSN: 2070-1721 June 2010
DNS Zone Transfer Protocol (AXFR)
DNS区域传输协议（AXFR）
Abstract
摘要
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.
域名系统协议中维护区域权威名称服务器一致性的标准方法包括三种机制。权威传输（AXFR）是机制之一，在RFC 1034和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 it records an accurate definition of an interoperable AXFR mechanism.
事实证明，AXFR的定义不够详细，因此迫使原本符合要求的实现做出假设，从而妨碍了互操作性。然而，今天我们有了一套令人满意的实现，可以进行互操作。本文档是AXFR的一个新定义，它记录了可互操作的AXFR机制的准确定义。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5936.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5936.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Definition of Terms ........................................4
1.2. Scope ......................................................5
1.3. Context ....................................................5
1.4. Coverage and Relationship to Original AXFR Specification ...5
2. AXFR Messages ...................................................6
2.1. AXFR Query .................................................8
2.1.1. Header Values .......................................8
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. Header Values ......................................12
2.2.2. Question Section ...................................14
2.2.3. Answer Section .....................................14
2.2.4. Authority Section ..................................14
2.2.5. Additional Section .................................14
2.3. TCP Connection Aborts .....................................15
3. Zone Contents ..................................................15
3.1. Records to Include ........................................15
3.2. Delegation Records ........................................16
3.3. Glue Records ..............................................18
3.4. Name Compression ..........................................19
3.5. Occluded Names ............................................19
4. Transport ......................................................20
4.1. TCP .......................................................20
4.1.1. AXFR Client TCP ....................................21
4.1.2. AXFR Server TCP ....................................22
4.2. UDP .......................................................22
5. Authorization ..................................................22
6. Zone Integrity .................................................23
7. Backwards Compatibility ........................................24
7.1. Server ....................................................24
7.2. Client ....................................................25
8. Security Considerations ........................................25
9. IANA Considerations ............................................25
10. Internationalization Considerations ...........................25
11. Acknowledgments ...............................................25
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................28
1. Introduction ....................................................4
1.1. Definition of Terms ........................................4
1.2. Scope ......................................................5
1.3. Context ....................................................5
1.4. Coverage and Relationship to Original AXFR Specification ...5
2. AXFR Messages ...................................................6
2.1. AXFR Query .................................................8
2.1.1. Header Values .......................................8
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. Header Values ......................................12
2.2.2. Question Section ...................................14
2.2.3. Answer Section .....................................14
2.2.4. Authority Section ..................................14
2.2.5. Additional Section .................................14
2.3. TCP Connection Aborts .....................................15
3. Zone Contents ..................................................15
3.1. Records to Include ........................................15
3.2. Delegation Records ........................................16
3.3. Glue Records ..............................................18
3.4. Name Compression ..........................................19
3.5. Occluded Names ............................................19
4. Transport ......................................................20
4.1. TCP .......................................................20
4.1.1. AXFR Client TCP ....................................21
4.1.2. AXFR Server TCP ....................................22
4.2. UDP .......................................................22
5. Authorization ..................................................22
6. Zone Integrity .................................................23
7. Backwards Compatibility ........................................24
7.1. Server ....................................................24
7.2. Client ....................................................25
8. Security Considerations ........................................25
9. IANA Considerations ............................................25
10. Internationalization Considerations ...........................25
11. Acknowledgments ...............................................25
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................28
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.
域名系统用于维护区域一致性服务器的标准设施由三个要素组成。权威传输（AXFR）在“域名-概念和设施”[RFC1034]（本文件中称为RFC 1034）和“域名-实施和规范”[RFC1035]（以下简称RFC 1035）中定义。增量区域传输（IXFR）在“DNS中的增量区域传输”[RFC1995]中定义。“区域更改提示通知（DNS通知）机制”[RFC1996]中定义了区域更改提示通知（通知）机制。这些机制的目标是使一组DNS名称服务器在给定区域内保持一致的权威性。
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.
本文档重新指定了AXFR机制，因为它广泛部署在Internet上，希望能够达到现代Internet标准所期望的精度，从而更新RFC 1034和RFC 1035。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”中的描述进行解释[BCP14]。
Use of "newer"/"new" and "older"/"old" DNS refers to implementations written after and prior to the publication of this document.
“更新的”/“新的”和“旧的”/“旧的”DNS的使用是指在本文档发布之后和之前编写的实现。
"General-purpose DNS implementation" refers to DNS software developed for widespread 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.
“通用DNS实施”指为广泛使用而开发的DNS软件。这包括可作为库和独立进程自由访问的解析器和服务器。这还包括仅用于支持DNS服务产品的专有实现。
"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.
“交钥匙DNS实施”是指定制的、一次性使用的DNS实施。此类实现包括采用DNS协议消息格式但不符合整个DNS功能范围的软件。
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.
术语“AXFR会话”、“AXFR服务器”和“AXFR客户端”将在第2节的第一段中介绍，在建立更多上下文之后。
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), 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.
一般来说，给定区域的权威名称服务器可以使用各种方法来实现其服务的区域内容的一致性。例如，有些DNS实现根据存储在关系数据库（而不是主文件）中的数据收集答案，依靠数据库的非DNS手段来同步数据库实例。其中一些非DNS解决方案以某种方式进行互操作。然而，AXFR、IXFR和NOTIFY是唯一定义在带内机制的协议，以提供一组名称服务器的一致性，并且它们是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.
本文档不包括不一致的DNS情况。DNS的一些应用程序中，某个区域的服务器被设计为不连贯的。对于这些配置，此处描述的一致性机制将不适用。
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.
DNS实现不需要支持AXFR、IXFR和NOTIFY，但它应该有一些方法来维护名称服务器的一致性。通用DNS实现可能支持AXFR（与IXFR和NOTIFY相同），但在没有AXFR的情况下可能存在交钥匙DNS实现。
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.
除了描述机制本身外，还有它们需要考虑的上下文。在AXFR（以及IXFR和NOTIFY）的初始规范中，很少考虑安全和隐私问题。自AXFR最初定义以来，对整个区域内容的访问出现了新的观点。在本文件中，将分别讨论基本机制和使用这些机制的许可。
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.
本文档仅关注AXFR的定义。任何更新IXFR规范或通知机制的工作都留给不同的文档来完成。
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
AXFR子协议的原始“规范”分散在RFC1034和RFC1035中。RFC 1035第2.2节（第5页）描述了AXFR的设计方案。RFC 1034的第4.3.5节描述了区域同步的一般策略和通过AXFR调用完整区域传输的规则；该节的第五段包含了AXFR协议的简短概述；RFC 2181第5.5节纠正了该规范中的一个重大缺陷。RFC 1035第3.2.3节已为AXFR QTYPE分配了代码点（更多信息，请参见下文第2.1.2节）
details). Section 4.2 of RFC 1035 discusses how the DNS uses the transport layer and briefly explains why UDP transport is deemed inappropriate for AXFR; the last paragraph of Section 4.2.2 gives details regarding TCP connection management for 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.
详情）。RFC 1035的第4.2节讨论了DNS如何使用传输层，并简要解释了为什么认为UDP传输不适合AXFR；第4.2.2节的最后一段详细介绍了AXFR的TCP连接管理。最后，RFC 1035第6.3节的第二段规定了在使用AXFR进行区域传输期间发生区域数据更改时服务器的行为。
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 is understood by the DNS community to exist today.
本文件将更新AXFR的规范。为此，它全面规定了AXFR的记录格式和处理规则，在很大程度上扩展了RFC 1034第4.3.5节的第5段，并详细说明了AXFR的传输注意事项，从而修订了RFC 1035第4.2.2节。此外，它还讨论了向后兼容性问题，并为AXFR提供了策略/管理注意事项以及特定的安全注意事项。本文档的目标是按照DNS社区目前的理解定义AXFR。
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, and secondary are not important for defining AXFR.) The use of the word "session" without qualification refers to an AXFR session.
AXFR会话由AXFR查询消息和为其返回的AXFR响应消息序列组成。在本文档中，AXFR客户端是AXFR查询的发送方，AXFR服务器是响应方。（使用诸如主、从、主和辅助等术语对于定义AXFR并不重要。）不加限定使用“会话”一词指的是AXFR会话。
An important aspect to keep in mind is that the definition of AXFR is restricted to TCP [RFC0793] (see Section 4 for details). The design of the AXFR process has certain inherent features that are not easily ported to UDP [RFC0768].
需要记住的一个重要方面是，AXFR的定义仅限于TCP[RFC0793]（有关详细信息，请参阅第4节）。AXFR进程的设计具有某些固有特性，这些特性不容易移植到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.
AXFR消息的基本格式为RFC 1035[RFC1035]第4节（“消息”）中定义的DNS消息，并由以下文档更新。
o The "Basic" DNS specification:
o “基本”DNS规范：
- "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]
- “区域更改提示通知机制（DNS通知）”[RFC1996]
- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136]
- “域名系统中的动态更新（DNS更新）”[RFC2136]
- "Clarifications to the DNS Specification" [RFC2181]
- “DNS规范澄清”[RFC2181]
- "Extension Mechanisms for DNS (EDNS0)" [RFC2671]
- “DNS的扩展机制（EDNS0）”[RFC2671]
- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845]
- “DNS的密钥交易身份验证（TSIG）”[RFC2845]
- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930]
- “DNS密钥建立（TKEY RR）”[RFC2930]
- "Obsoleting IQUERY" [RFC3425]
- “废弃液体”[RFC3425]
- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597]
- “未知DNS资源记录（RR）类型的处理”[RFC3597]
- "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers" [RFC4635]
- “HMAC SHA（哈希消息认证码，安全哈希算法）TSIG算法标识符”[RFC4635]
- "Domain Name System (DNS) IANA Considerations" [RFC5395]
- “域名系统（DNS）IANA注意事项”[RFC5395]
o Further additions related to the DNS Security Extensions (DNSSEC), defined in these base documents:
o 与这些基本文档中定义的DNS安全扩展（DNSSEC）相关的进一步添加：
- "DNS Security Introduction and Requirements" [RFC4033]
- “DNS安全介绍和要求”[RFC4033]
- "Resource Records for the DNS Security Extensions" [RFC4034]
- “DNS安全扩展的资源记录”[RFC4034]
- "Protocol Modifications for the DNS Security Extensions" [RFC4035]
- “DNS安全扩展的协议修改”[RFC4035]
- "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)" [RFC4509]
- “在DNSSEC授权签署人（DS）资源记录（RRs）中使用SHA-256”[RFC4509]
- "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155]
- “DNS安全性（DNSSEC）哈希认证拒绝存在”[RFC5155]
- "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC" [RFC5702]
- “在DNSSEC的DNSKEY和RRSIG资源记录中使用带RSA的SHA-2算法”[RFC5702]
- "Clarifications and Implementation Notes for DNSSECbis" [DNSSEC-U]
- “DNSSECbis的澄清和实施说明”[DNSSEC-U]
These documents contain information about the syntax and semantics of DNS messages. They do not interfere with AXFR but are also helpful in understanding what will be carried via AXFR.
这些文档包含有关DNS消息的语法和语义的信息。它们不会干扰AXFR，但也有助于理解通过AXFR携带的内容。
For convenience, the synopsis of the DNS message header from [RFC5395] (and the IANA registry for DNS Parameters [DNSVALS]) is reproduced here informally:
为方便起见，[RFC5395]（和DNS参数的IANA注册表[DNSVALS]）的DNS消息头概要非正式复制如下：
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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".
本文档使用此图表中显示的字段名。为清晰起见，DNS消息正文中的节名称在本文档中大写，例如“附加节”。
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.
如第4节所述，[RFC1035]对UDP上的DNS（及其通过[RFC2671]中指定的EDNS0机制进行的扩展）的DNS消息大小限制与AXFR无关。TCP上DNS消息的允许大小上限仅受RFC 1035第4.2.2节中定义的TCP帧的限制，该帧指定了一个两个八位字节的消息长度字段，该字段被理解为无符号，因此导致限制为65535个八位字节。EDNS0不会更改此限制。
Note that the TC (truncation) bit is never set by an AXFR server nor considered/read by an AXFR client.
请注意，AXFR服务器从未设置TC（截断）位，AXFR客户端也从未考虑/读取该位。
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.
只要有理由询问，客户端就会发送AXFR查询。这可能是由于计划或触发的区域维护活动（分别参见RFC 1034和DNS NOTIFY[RFC1996]的第4.3.5节）或命令行请求（例如调试）的结果。
These are the DNS message header values for an AXFR query.
这些是AXFR查询的DNS消息头值。
ID Selected by client; see Note a)
客户选择的ID；见注a）
QR MUST be 0 (Query)
QR必须为0（查询）
OPCODE MUST be 0 (Standard Query)
操作码必须为0（标准查询）
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)
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)
RCODE必须为0（无错误）
QDCOUNT Number of entries in Question section; MUST be 1
QDCOUNT问题部分的条目数；必须是1
ANCOUNT Number of entries in Answer section; MUST be 0
a统计答案部分的条目数；必须是0
NSCOUNT Number of entries in Authority section; MUST be 0
NSCOUNT权限部分中的条目数；必须是0
ARCOUNT Number of entries in Additional section -- see Note d)
ARCOUNT附加部分中的条目数——见注释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) 设置为客户端尚未在同一服务器上使用的任何值。此字段中没有选择值的具体方法。（回想一下，AXFR仅通过TCP连接完成——请参阅第4节“传输”。）
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.1 for more details.
服务器必须使用使用相同消息ID的消息进行回复，以允许客户端在同一TCP连接上同时有多个未完成的查询——有关更多详细信息，请参见第2.2.1节中的注释A）。
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.
b) “n/a”-此字段中的值在AXFR查询消息的上下文中没有意义。对于客户端，建议该值为零。服务器必须忽略此值。
c) "mbz" -- The client MUST set this bit to 0; the server MUST ignore it.
c) “mbz”--客户端必须将该位设置为0；服务器必须忽略它。
d) The client MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR queries, the value MAY be 0, 1, or 2. See Section 2.1.5, "Additional Section", for details on the currently applicable RRs.
d) 客户端必须将此字段设置为它放入附加节的资源记录数。如果在AXFR查询的附加部分中没有明确说明要携带的新RRs，则该值可以是0、1或2。有关当前适用RRs的详细信息，请参见第2.1.5节“附加章节”。
The Question 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:
AXFR查询的问题部分必须符合RFC 1035的第4.1.2节，并包含具有以下值的单个资源记录：
QNAME the name of the zone requested
QNAME请求的区域的名称
QTYPE AXFR (= 252), the pseudo-RR type for zone transfer [DNSVALS]
QTYPE AXFR（=252），区域传输的伪RR类型[DNSVALS]
QCLASS the class of the zone requested [DNSVALS]
QCLASS所请求区域的类别[DNSVALS]
The Answer section MUST be empty.
答案部分必须为空。
The Authority section MUST be empty.
权限部分必须为空。
Currently, two kinds of resource records are defined that can appear in the Additional section of AXFR queries and responses: EDNS and DNS transaction security. Future specifications defining RRs that can be carried in the Additional section of normal DNS transactions need to explicitly describe their use with AXFR, should that be desired.
目前，定义了两种资源记录，它们可以出现在AXFR查询和响应的附加部分中：EDNS和DNS事务安全性。如果需要，定义可在正常DNS事务的附加部分中携带的RRs的未来规范需要明确描述它们与AXFR的使用。
The client MAY include one OPT resource record [RFC2671]. If the server does not support EDNS0, the client MUST send this section without an 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) that might be related to the OPT resource record. Note that, at the time of this writing, only the EXTENDED-RCODE field of the OPT RR is meaningful in the context of AXFR; future specifications of EDNS flags and/or EDNS options must describe their usage in the context of AXFR, if applicable.
客户端可以包括一个OPT资源记录[RFC2671]。如果服务器不支持EDNS0，则如果重试，客户端必须发送不带OPT资源记录的此节。但是，协议没有明确指出服务器不支持EDNS0；这需要由客户来推断。通常，服务器将返回可能与OPT资源记录相关的FormErr（1）。注意，在撰写本文时，只有OPT RR的EXTENDED-RCODE字段在AXFR上下文中有意义；EDNS标志和/或EDNS选项的未来规范必须描述其在AXFR上下文中的使用（如果适用）。
The client MAY include one 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 the security data in the face of an obstacle ought to only be done with full awareness of the implication of doing so.
客户端可以包括一个事务完整性和认证资源记录，当前可以选择TSIG[RFC2845]或SIG（0）[RFC2931]。如果服务器指示它无法识别资源记录，并且错误确实是由资源记录引起的，则客户端可能不应该重试。在遇到障碍时删除安全数据只能在充分意识到这样做的含义的情况下进行。
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 engage the server at all). A client could become aware of a server's abilities via a configuration setting or via some other (as yet) undefined means.
通常，如果AXFR客户端知道AXFR服务器不支持特定机制，则客户端不应尝试使用该机制与服务器接洽（或根本不与服务器接洽）。客户机可以通过配置设置或其他未定义的方式了解服务器的能力。
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 EDNS) is made or a new Additional section record is created, the new definitions ought to include a discussion on the applicability and impact upon AXFR. Future resource records residing in the Additional section might have an effect that is orthogonal to AXFR, and 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.
附加部分中可能出现的允许资源记录的范围可能会随时间而变化。如果对现有资源记录（如EDN的OPT RR）进行了更改，或创建了新的附加章节记录，则新定义应包括对AXFR适用性和影响的讨论。驻留在附加部分中的未来资源记录可能具有与AXFR正交的效果，因此可以作为不透明数据贯穿会话。在这种情况下，“明智”的实现应该能够在不中断的情况下传递这些记录。
The AXFR response will consist of one or more messages. The special case of a server closing the TCP connection without sending an AXFR response is covered in Section 2.3.
AXFR响应将由一条或多条消息组成。第2.3节介绍了服务器关闭TCP连接而不发送AXFR响应的特殊情况。
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, and 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 into the first response message's Question section. For subsequent messages, it MAY do the same or leave the Question section empty.
传输区域内容的AXFR响应将由一系列（可能是一系列长度为1的）DNS消息组成。在这样的系列中，第一条消息必须以区域的SOA资源记录开始，最后一条消息必须以相同的SOA资源记录结束。中间消息不能包含SOA资源记录。AXFR服务器必须将问题部分从相应的AXFR查询消息复制到第一条响应消息的问题部分。对于后续消息，它可能会执行相同的操作，或者将问题部分留空。
The AXFR protocol treats the zone contents as an unordered collection (or to use the mathematical term, a "set") of RRs. Except for the requirement that the transfer must begin and end with the SOA RR, there is no requirement to send the RRs in any particular order or grouped into response messages in any particular way. Although servers typically do attempt to send related RRs (such as the RRs forming an RRset, and the RRsets of a name) as a contiguous group or, when message space allows, in the same response message, they are not required to do so, and clients MUST accept any ordering and grouping of the non-SOA RRs. Each RR SHOULD be transmitted only once, and AXFR clients MUST ignore any duplicate RRs received.
AXFR协议将区域内容视为RRs的无序集合（或者使用数学术语，称为“集合”）。除了传输必须以SOA RR开始和结束的要求外，不需要以任何特定顺序发送RRs或以任何特定方式分组到响应消息中。尽管服务器通常会尝试将相关的RRs（例如形成RRs集的RRs和名称的RRs集）作为连续组发送，或者在消息空间允许的情况下，在同一响应消息中，它们不需要这样做，并且客户端必须接受非SOA RRs的任何排序和分组。每个RR只能传输一次，AXFR客户端必须忽略接收到的任何重复RR。
Each AXFR response message SHOULD contain a sufficient number of RRs to reasonably amortize the per-message overhead, up to the largest number that will fit within a DNS message (taking the required content of the other sections into account, as described below).
每个AXFR响应消息应包含足够数量的RRs，以合理分摊每条消息的开销，最多为DNS消息中适合的最大数量（考虑到其他部分所需的内容，如下所述）。
Some old AXFR clients expect each response message to contain only a single RR. To interoperate with such clients, the server MAY restrict response messages to a single RR. As there is no standard way to automatically detect such clients, this typically requires manual configuration at the server.
一些旧的AXFR客户端希望每个响应消息只包含一个RR。为了与这些客户机进行互操作，服务器可能会将响应消息限制为单个RR。由于没有自动检测此类客户端的标准方法，因此通常需要在服务器上进行手动配置。
To indicate an error in an AXFR response, the AXFR server sends a single DNS message when the error condition is detected, with the response code set to the appropriate value for the condition encountered. Such a message terminates the AXFR session; it MUST contain a copy of the Question section from the AXFR query in its Question section, but the inclusion of the terminating SOA resource record is not necessary.
要指示AXFR响应中的错误，当检测到错误条件时，AXFR服务器将发送一条DNS消息，并将响应代码设置为所遇到条件的相应值。这样的消息终止AXFR会话；它必须在其问题部分包含来自AXFR查询的问题部分的副本，但不需要包含终止SOA资源记录。
An AXFR server may send a number of AXFR response messages free of an error condition before it sends the message indicating an error.
AXFR服务器在发送指示错误的消息之前，可能会发送大量没有错误条件的AXFR响应消息。
These are the DNS message header values for AXFR responses.
这些是AXFR响应的DNS消息头值。
ID MUST be copied from request -- see Note a)
ID必须从请求中复制--请参见注释a）
QR MUST be 1 (Response)
QR必须为1（响应）
OPCODE MUST be 0 (Standard Query)
操作码必须为0（标准查询）
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 "mbz" -- see Note d) CD "mbz" -- see Note d)
标志：AA通常为1——请参见注释b）TC必须为0（未截断）RD建议：复制请求的值；可设置为0 RA应为0——参见注释c）Z“mbz”--参见注释d）AD“mbz”--参见注释d）CD“mbz”--参见注释d）
RCODE See Note e)
R代码（见注e）
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
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 f)
a计数（见注f）
NSCOUNT MUST be 0
NSCOUNT必须为0
ARCOUNT See Note g)
ARCOUNT（见注g）
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.
a) 由于一些旧的实现的行为与现在所期望的不同，因此详细说明了该字段的要求。新DNS服务器必须将此字段设置为会话的每个AXFR响应消息中AXFR查询ID的值。AXFR客户端必须能够管理由于发出多个未完成查询（无论是AXFR查询还是其他DNS查询）而产生的会话。客户机应该放弃（通过消息ID）与任何未完成查询不对应的响应。
Unless the client is sure that the server will consistently set the ID field to the query's ID, the client is NOT RECOMMENDED to issue any other queries until the end of the zone transfer. A client MAY become aware of a server's abilities via a configuration setting.
除非客户机确信服务器将一致地将ID字段设置为查询的ID，否则在区域传输结束之前，不建议客户机发出任何其他查询。客户机可以通过配置设置了解服务器的能力。
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.
b) 如果RCODE为0（无错误），则AA位必须为1。对于RCODE的任何其他值，必须根据该错误代码的规则设置AA位。如果有疑问，建议将其设置为1。建议AXFR客户端忽略该值。
c) It is RECOMMENDED that the server set the value to 0; the client MUST ignore this value.
c) 建议服务器将该值设置为0；客户端必须忽略此值。
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 cannot 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.
服务器可以根据有关递归服务的本地策略设置此值，但这样做可能会混淆响应的解释，因为无法递归检索AXFR。客户机可能会从该值中注意到服务器关于递归服务的策略，但不应断定AXFR响应是递归获得的，即使查询中的RD位是1。
d) "mbz" -- The server MUST set this bit to 0; the client MUST ignore it.
d) “mbz”--服务器必须将该位设置为0；客户必须忽略它。
e) 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 to the error. For example, a malformed AXFR query or the presence of an OPT resource record sent to an old server will result in 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.
e) 如果没有错误，服务器必须将此字段的值设置为NoError（0）。如果服务器对查询的区域没有权威，则服务器应将该值设置为NotAuth（9）。（提醒：请咨询相应的IANA注册表[DNSVALS]）如果客户端收到任何其他值作为响应，则必须根据错误进行操作。例如，格式错误的AXFR查询或存在发送到旧服务器的OPT资源记录将导致FormErr（1）值。此值未设置为AXFR特定响应处理的一部分。对于指示错误的其他值也是如此。
f) 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 response messages with a single resource record, then the value MUST be 1. A server MAY be made aware of a client's limitations via configuration data.
f) 应答记录的计数必须等于AXFR应答部分中的资源记录数。当服务器意识到客户端只接受带有单个资源记录的响应消息时，该值必须为1。服务器可以通过配置数据了解客户端的限制。
g) The server MUST set this field to the number of resource records it places into the Additional section. In the absence of explicit specification of new RRs to be carried in the Additional section of AXFR response messages, the value MAY be 0, 1, or 2. See Section 2.1.5 above for details on the currently applicable RRs and Section 2.2.5 for additional considerations specific to AXFR servers.
g) 服务器必须将此字段设置为它放入附加节的资源记录数。如果在AXFR响应消息的附加部分中没有明确指定要携带的新RRs，则该值可以是0、1或2。有关当前适用RRs的详细信息，请参见上文第2.1.5节；有关AXFR服务器的其他注意事项，请参见第2.2.5节。
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节），也必须复制该节。本节内容可用于确定消息的上下文，即正在传输的区域的名称。
The Answer section MUST be populated with the zone contents. See Section 3 below on encoding zone contents.
答案部分必须填充区域内容。有关编码区域内容，请参见下文第3节。
The Authority section MUST be empty.
权限部分必须为空。
The contents of this section MUST follow the guidelines for the OPT, TSIG, and SIG(0) RRs, or whatever other future record is possible here. The contents of Section 2.1.5 apply analogously as well.
本节内容必须遵循OPT、TSIG和SIG（0）RRs指南，或此处可能的任何其他未来记录。第2.1.5节的内容同样适用。
The following considerations specifically apply to AXFR responses:
以下注意事项特别适用于AXFR响应：
If the client has supplied an EDNS OPT RR in the AXFR query and if the server supports EDNS as well, it SHOULD include one OPT RR in the first response message and MAY do so in subsequent response messages (see Section 2.2); the specifications of EDNS options to be carried in the OPT RR may impose stronger requirements.
如果客户机在AXFR查询中提供了一个EDNS OPT RR，并且如果服务器也支持EDNS，则它应该在第一个响应消息中包含一个OPT RR，并且可以在后续响应消息中包含一个OPT RR（参见第2.2节）；OPT RR中的EDNS选项规范可能会提出更高的要求。
If the client has supplied a transaction security resource record (currently a choice of TSIG and SIG(0)) and the server supports the method chosen by the client, it MUST place the corresponding resource record into the AXFR response message(s), according to the rules specified for that method.
如果客户端提供了事务安全资源记录（当前选择TSIG和SIG（0）），并且服务器支持客户端选择的方法，则必须根据为该方法指定的规则将相应的资源记录放入AXFR响应消息中。
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.
如果AXFR客户端在TCP连接上发送查询，并且在任何时候关闭连接，AXFR客户端必须考虑AXFR会话终止。即使问题和AXFR服务器相同，也可以在新连接上再次使用消息ID。
Facing a dropped connection, a client SHOULD try to make some determination as to whether the connection closure was the result of network activity or due to a decision by the AXFR server. This determination is not an exact science. It is up to the AXFR client to react, but the implemented reaction SHOULD NOT be either an endless cycle of retries or an increasing (in frequency) retry rate.
面对断开的连接，客户端应尝试确定连接关闭是网络活动的结果还是AXFR服务器的决定。这个决定不是一门精确的科学。由AXFR客户端做出反应，但实现的反应不应该是无休止的重试周期或不断增加的（频率）重试率。
An AXFR server implementer 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.
AXFR服务器实现者应该考虑在管道中存在未完成查询的情况下关闭连接时的上述困境。出于这个原因，服务器应该在其毫无疑问地认为AXFR客户端正在尝试滥用行为的情况下保留此操作过程。
The objective of the AXFR session is to request and transfer the contents of a zone, in order to permit the AXFR client to faithfully reconstruct the zone as it exists at the primary server for the given zone serial number. The word "exists" here designates the externally visible behavior, i.e., the zone content that is being served (handed out to clients) -- not its persistent representation in a zone file or database used by the server -- and that for consistency should be served subsequently by the AXFR client in an identical manner.
AXFR会话的目标是请求和传输区域的内容，以允许AXFR客户端根据给定的区域序列号忠实地重建主服务器上存在的区域。这里的单词“exists”表示外部可见的行为，即正在提供（分发给客户机）的区域内容，而不是服务器使用的区域文件或数据库中的持久表示，并且AXFR客户机随后应以相同的方式提供一致性。
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.
随着时间的推移，区域的定义已经从表示一组静态记录发展到还包括一组动态更新的记录，然后是一组潜在的不断重新生成的记录（例如，从规则集或以RR格式以外的其他形式的数据库查找结果“动态”合成的RRs）。
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,
在AXFR响应消息的应答部分，必须显示给定序列号区域内的资源记录。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.
第4.2节“数据库如何划分区域”（特别是第4.2.1节“技术考虑”），RFC 2181第6节对此进行了澄清。
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.
无法为序列号列出整个区域的区域不适用于AXFR检索。此类区域的典型（但不限于）描述是由通过其他数据库查找生成和/或基于不断变化的数据计算的响应组成的区域。
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):
在RFC 1034的第4.2.1节中，出现了该文本（请记住，报价中的“应该”早于[BCP14]，参见第1.1节）：
The RRs that describe cuts ... should be exactly the same as the corresponding RRs in the top node of the subzone.
描述切割的RRs。。。应与子区域顶部节点中的相应RRs完全相同。
There has been some controversy over this statement and the impact on which NS resource records are included in a zone transfer.
关于这一声明以及区域转移中包括哪些NS资源记录的影响，存在一些争议。
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".
短语“描述切割”是指NS集合和适用的粘合记录。这并不意味着切割点和顶点资源记录是相同的。例如，SOA资源记录只能在顶点处找到。这里的讨论仅限于NS资源记录集和胶水，因为这些“描述剪切”。
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 second bullet in Section 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 to the NSEC RR, for the purpose of AXFR.
DNSSEC资源记录有关于其在区域切割和区域顶点处出现的特殊规范。这首先在第5.3节及其后的章节中进行了描述。RFC 2181的第6.2节（DNSSEC的初始规范），RFC 2181的哪些部分实际上是历史性的。当前的DNSSEC核心文件集（见上文第2节中的第二个项目符号）给出了DNSSEC（bis）资源记录放置的完整细节，RFC 4035第3.1.5节规范性地规定了在AXFR期间的处理方法；出于AXFR的目的，RFC 5155后面定义的备用NSEC3资源记录的行为与NSEC RR相同。
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 DS RRSet仅出现在分区切割的父侧，是父分区中的权威数据，而不是安全子分区中的权威数据。
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 DNSKEY RRSet仅出现在签名区域的顶点，并且是其所服务区域的权威数据的一部分。
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 独立的RRSIG RRSET出现在区域切割的有符号父侧和有符号区域的顶点；它们是各自区域内的权威数据；如果同一台服务器对父区域和子区域具有权威性，则对RRSIG资源记录的简单查询可能会同时返回两个RRs集（RFC 4035第3.1.5节描述了如何区分这些RRs）；AXFR不会出现这种看似模糊的情况，因为每个这样的RRSIG RRset都属于一个区域。
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.
o 不同的NSEC[RFC4034]（或NSEC3[RFC5155]）资源记录同样可能出现在分区切割的父端和分区的顶点；每个这样的资源记录只属于这些区域中的一个，并且要包含在该区域的AXFR中。
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).
一个问题是，在操作中，有时分区的NS资源记录在父分区的切点和分区的顶点可能不同。有时这是错误的结果，有时这是名称服务器正在进行的更改的一部分。DNS协议足够健壮，可以克服不一致性，直到（但不包括）没有引用能够为子区域提供服务的服务器的父指示NS资源记录为止。这种健壮性是推动DNS成功的一个因素。然而，不一致性是一种错误状态，需要采取措施使其变得明显（如果是非计划的）。
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.
另一个问题是，AXFR服务器可能对不同于AXFR客户端的区域集具有权威性。AXFR服务器可能对不一致切点的两半都具有权威性，而AXFR客户端可能仅对切点的父端具有权威性。
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.
当遇到切点的NS资源记录与权威集不匹配的情况时，问题在于AXFR服务器是使用正在传输的区域中的NS资源记录集还是使用权威位置的NS资源记录集进行响应。
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.
AXFR响应必须包含在分区中注册的切点NS资源记录集，无论它是否与权威集一致。“注册于”可广泛解释为包括特定序列号（在区域文件环境中）的区域文件中的数据，或静态或动态配置为区域（数据库）中的任何数据。
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.
1) AXFR服务器可能无法确定给定的本地数据是否存在不一致性；因此，要求一致性意味着需要进行更多的工作，甚至需要对数据进行网络检索。执行任何查询都不需要权威服务器。
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.)
2) 通过将不一致的NS资源记录从对切入点和顶点都有权威的服务器传输到对两者都没有权威的客户端，错误就会暴露出来。例如，授权管理员可以手动请求AXFR并检查结果以查看不一致的记录。（对于两个部分都具有权威性的服务器将始终从更权威的集合中应答，从而隐藏错误。）
3) The inconsistent NS resource record set might indicate a problem in a registration database.
3) 不一致的NS资源记录集可能表明注册数据库中存在问题。
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.
4) 此要求对于确保AXFR检索给定（区域、串行）对产生完全相同的资源记录集是必要的，无论选择哪个区域的权威服务器作为传输源。
If an AXFR server were allowed to respond with the authoritative NS RRset of a child zone instead of a parent-side NS RRset in the zone being transferred, the set of records returned could vary depending on whether or not the server happened to be authoritative for the child zone as well.
如果允许AXFR服务器使用子区域的权威NS RRset而不是正在传输的区域中的父端NS RRset进行响应，则返回的记录集可能会有所不同，这取决于服务器是否恰好也是子区域的权威。
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.
一个给定的（区域，串行）对对应于一个单独的、定义良好的记录集的属性对于增量传输协议（如IXFR[RFC1995]）的正确操作是必要的。例如，客户端可以通过AXFR从一台服务器检索区域，然后应用IXFR从另一台服务器获得的增量更改。如果两台服务器对区域内容有不同的看法，那么客户端最终可能会尝试以增量方式添加已经存在的记录或删除不存在的记录。
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 response. 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.
如前一节所述，RFC 1034第4.2.1节提供了将胶水记录作为AXFR响应的一部分的指南和基本原理。而且，正如本文件前一节所述，即使胶水记录中的地址与名称服务器地址的权威副本之间存在不一致，也应包括注册为该序列号区域一部分的胶水资源记录。
This applies to glue records for any address family [IANA-AF].
这适用于任何地址族[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.
AXFR响应必须包含在区域中注册的相应粘合记录。前一节中“注册于”的解释适用于此处。不一致的胶水记录是一个操作问题。
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:
DNS消息中名称的压缩在RFC 1035第4.1.4节“消息压缩”中描述。此处强调的问题与RFC 1034第3.1节“名称空间规范和术语”中的评论有关，其中指出：
When you receive a domain name or label, you should preserve its case.
当您收到域名或标签时，应保留其大小写。
("Should" in the quote predates [BCP14].)
（“引用中的“应该”早于[BCP14]。）
Since the primary objective of AXFR is to enable the client to serve the same zone content as the server, unlike such normal DNS responses that are expected to preserve the case in the query, the actual zone transfer needs to retain the case of the labels in the zone content. Hence, name compression in an AXFR message SHOULD be performed in a case-preserving manner, unlike how it is done for "normal" DNS responses. That is, although when comparing a domain name for matching, "a" equals "A", when comparing for the purposes of message compression for AXFR, "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 understanding of the requirement on AXFR servers.
由于AXFR的主要目标是使客户端能够提供与服务器相同的区域内容，因此与预期在查询中保留大小写的正常DNS响应不同，实际区域传输需要保留区域内容中标签的大小写。因此，AXFR消息中的名称压缩应以保留大小写的方式执行，这与“正常”DNS响应的压缩方式不同。也就是说，虽然在比较域名进行匹配时，“a”等于“a”，但在比较AXFR的消息压缩时，“a”不等于“a”。请注意，这不是DNS协议中名称比较的常见定义，代表了对AXFR服务器要求的新理解。
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".
管理AXFR消息中RDATA名称压缩的规则必须遵守“未知DNS资源记录（RR）类型的处理”[RFC3597]中的规范，特别是“域名压缩”第4节。
Dynamic Update [RFC2136] operations, and in particular their 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".
动态更新[RFC2136]操作，特别是它们与DNAME[RFC2672]的交互，可能会产生在区域中屏蔽名称的副作用。通过动态更新添加委派点将使所有从属域名处于不确定状态，仍然是区域的一部分，但不可用于查找过程。添加DNAME资源记录具有相同的影响。从属名称被称为“闭塞”。
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.
被遮挡的名称必须包含在AXFR响应中。AXFR客户端必须能够识别和处理被屏蔽的名称。此操作的基本原理是，如果动态更新操作出错并要撤消，则可以快速恢复。
AXFR sessions are currently restricted to TCP by Section 4.3.5 of RFC 1034, which states:
RFC 1034第4.3.5节规定，AXFR会话目前仅限于TCP，其中规定：
Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.
由于准确性至关重要，因此AXFR请求必须使用TCP或其他可靠协议。
The restriction to TCP is also mentioned in Section 6.1.3.2 of "Requirements for Internet Hosts - Application and Support" [RFC1123].
“互联网主机要求-应用程序和支持”[RFC1123]第6.1.3.2节也提到了对TCP的限制。
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.
最常见的情况是AXFR客户端打开到AXFR服务器的TCP连接，发送AXFR查询，接收AXFR响应，然后关闭连接。但这种最简单场景的变体是合法的，也很可能是：特别是，首先通过相同的TCP连接发送对区域SOA资源记录的查询，然后将现有的TCP连接重新用于其他查询。
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.
因此，假设TCP连接专用于单个AXFR会话是不正确的。这种错误的假设导致了实现选择，这些实现选择要么阻止多个并发区域传输，要么阻止对其他查询使用开放连接。
Since the early days of the DNS, operators who have sets of name servers that are authoritative for a common set of zones have 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 transfer to complete before the next can begin. RFC 1035 did not exclude this possibility, but legacy implementations failed to support this functionality efficiently, over a single TCP connection. The remaining presence of such legacy implementations makes it necessary that new general-purpose client implementations still provide options for graceful fallback to the old behavior in their support of concurrent DNS transactions and AXFR sessions on a single TCP connection.
自DNS早期以来，拥有一组对一组公共区域具有权威性的名称服务器的运营商发现，希望能够进行多个并发区域传输；这样，名称服务器就不必等待一个区域传输完成，然后才能开始下一个区域传输。RFC1035没有排除这种可能性，但传统的实现无法通过单个TCP连接有效地支持此功能。这些遗留实现的剩余存在使得新的通用客户机实现仍然需要提供一些选项，以便在支持单个TCP连接上的并发DNS事务和AXFR会话时，优雅地回退到旧行为。
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 Question section and/or the message ID into
在最初的定义中，有一个隐含的假设（可能是无意的），即TCP连接只用于一个AXFR会话。这表现在没有明确要求将问题部分和/或消息ID复制到
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.
响应，AXFR响应消息中没有明确的排序信息，并且没有明确的通知指示区域传输在下一条消息中继续。
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.
下面给出的指导旨在提高AXFR exchange的性能，并提供有关与旧软件交互的指导。更好的性能包括能够多路复用DNS消息交换，包括区域传输会话。与旧软件交互的指导原则通常适用于新的AXFR客户端。在相反的情况下——较旧的AXFR客户端和较新的AXFR服务器——服务器应该在较旧服务器的规范内运行。
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 that sessions will be coming, or if there is other query/response traffic anticipated or currently on the open connection, then there is "apparent need".
AXFR客户端可能出于任何原因请求连接到AXFR服务器。当一段时间内不需要使用连接时，AXFR客户端应关闭连接。AXFR服务器不应该保持空闲连接；连接关闭的负担应该由客户端承担。连接的“明显需要”是对AXFR客户端和DNS客户端的判断。如果连接用于多个会话，或者如果已知会话将要到来，或者如果在打开的连接上预期或当前存在其他查询/响应流量，则“显然需要”。
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.
AXFR客户端只能通过关闭连接来取消区域的传递。但是，此操作还将取消使用连接的所有其他未完成活动。没有其他机制可以取消AXFR响应。
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 failure that proved to be persistent, the AXFR client would be wise not to spend too many resources trying to rebuild the connection. Finally, if the connection was dropped because of a policy at the AXFR server (as can be the case with older AXFR servers), the AXFR client would be wise not to 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. This exemplifies the general complications for clients in connection-oriented protocols not receiving meaningful error responses.
无论是由AXFR服务器还是由于网络事件远程关闭TCP连接（相对于客户端），AXFR客户端都必须取消所有未完成的会话和非AXFR事务。从这种情况中恢复并非易事。如果中断是虚假事件，则尝试重新启动连接是正确的。如果中断是由一个被证明是持久性的故障引起的，那么AXFR客户机最好不要花费太多的资源尝试重建连接。最后，如果由于AXFR服务器上的策略而断开了连接（旧的AXFR服务器就是这种情况），AXFR客户端最好不要重试连接。不幸的是，知道上述三种情况（暂时中断、失败、政策）中的哪一种适用是不可能确定的，只能通过启发式方法进行评估。这举例说明了面向连接的协议中的客户端没有收到有意义的错误响应的一般复杂性。
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).
AXFR客户端可以使用已打开的TCP连接启动AXFR会话。与打开新连接相比，建议使用现有打开的连接。（非AXFR会话通信也可以使用开放连接。）如果在这样做时，AXFR客户端意识到响应无法正确区分（例如，缺少匹配的查询ID），或者连接因远程原因而终止，然后，在更新AXFR服务器之前，AXFR客户端不应尝试重用与特定AXFR服务器的打开连接（当然，这不是DNS协议中捕获的事件）。
An AXFR server MUST be able to handle multiple AXFR sessions on a single TCP connection, as well as to handle other query/response transactions over it.
AXFR服务器必须能够在单个TCP连接上处理多个AXFR会话，以及通过它处理其他查询/响应事务。
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.
如果远程关闭TCP连接，AXFR服务器必须取消所有AXFR会话。不需要重试活动；这是由AXFR客户端启动的。
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 response code and not see the connection broken.
本地策略可能指示关闭TCP连接。此类行动应针对未完成开放连接的数量等限制作出反应。只有在极端情况下，当服务器确信该操作是正确的时，才应关闭连接以响应可疑的安全事件。针对不在AXFR服务器上的区域的隔离请求应收到带有相应响应代码的响应，并且不会看到连接断开。
With the addition of EDNS0 and applications that 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.
随着EDNS0和需要许多小区域的应用程序的添加，例如在web托管和一些枚举场景中，UDP上的AXFR会话现在似乎是可取的。但是，AXFR会话仍有一些方面不容易转换为UDP。
Therefore, this document does not update RFC 1035 in this respect: AXFR sessions over UDP transport are not defined.
因此，本文档不在这方面更新RFC 1035：未定义UDP传输上的AXFR会话。
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
区域管理员可以选择限制AXFR对区域的访问。这在DNS的原始设计中没有设想，但随着DNS的发展，这已成为一项要求。对AXFR的限制可能有多种原因，包括希望（或在某些情况下，有法律要求）隐藏区域的批量版本或阻止服务器处理负载
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.
在服务AXFR时发生的费用。有人认为，这些原因值得商榷，但本文件出于利用RFC 1035以来发展的互操作实践的愿望，承认提供限制AXFR机制的事实要求。
A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients.
DNS实现应提供将AXFR会话限制到特定客户端的方法。
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 (VPNs) [RFC2764] or Virtual LANs has proven to be effective.
实现应该允许访问Internet协议地址和范围，而不管源地址是否可能被欺骗。将其与虚拟专用网络（VPN）[RFC2764]或虚拟局域网等技术相结合已被证明是有效的。
A general-purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931].
建议使用通用实现来实现基于“DNS密钥事务验证（TSIG）”[RFC2845]和/或“DNS请求和事务签名（SIG（0）s）”[RFC2931]的访问控制。
A general-purpose implementation SHOULD allow access to be open to all AXFR requests. That is, an operator ought to be able to allow any AXFR query to be granted.
通用实现应允许对所有AXFR请求开放访问。也就是说，操作员应该能够允许授予任何AXFR查询。
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.
对于AXFR请求，“向所有人开放”，通用实现不应具有默认策略。例如，默认情况下可以将传输限制为DNS管理员为服务器上的区域选择的地址。
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 has introduced a two-stage model of the whole zone synchronization procedure: Upon a trigger event (e.g., when polling of a SOA resource record detects a change in the SOA serial number, or when a DNS NOTIFY request [RFC1996] is received), the AXFR session is initiated, whereby the zone data are saved in a zone file or database (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.
AXFR客户端必须确保只有成功传输的区域数据副本才能用于服务此区域。前面的描述和实施实践介绍了整个区域同步过程的两阶段模型：在触发事件（例如，当轮询SOA资源记录检测到SOA序列号发生变化时，或当接收到DNS通知请求[RFC1996]时），启动AXFR会话，区域数据保存在区域文件或数据库中（后一步是确保服务器正确重启所必需的）；成功完成AXFR操作和一些健全性检查后，此数据集将“加载”，并可用于在原子操作中为区域提供服务，并标记为“有效”，以便在下次重新启动DNS服务器时使用；如果检测到任何错误，则必须删除此数据集，并且AXFR客户端必须继续为以前版本的区域提供服务（如果以前有）。AXFR客户端实现的外部可见行为必须与此两阶段模型的行为等效。
If an AXFR client rejects data obtained 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.
如果AXFR客户端拒绝在AXFR会话中获取的数据，它应该记住序列号，并可能再次尝试检索相同的区域版本。同样的检索之所以有意义，是因为拒绝的原因可能源于用于该区域的一台AXFR服务器的实现细节，而不存在于用于该区域的另一台AXFR服务器中。
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.
确保AXFR客户端不接受区域的伪造副本对于区域的安全非常重要。如果区域运营商有机会，可以通过专用链路提供保护，通过授权服务器之间的VPN提供物理或虚拟链路。但在某些情况下，区域运营商别无选择，只能通过全球公共互联网运行AXFR会话。
Besides best attempts at securing TCP connections, DNS implementations SHOULD provide means to make use of "Secret Key Transaction Authentication for DNS (TSIG)" [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.
除了保护TCP连接的最佳尝试外，DNS实现还应提供使用“DNS密钥事务验证（TSIG）”[RFC2845]和/或“DNS请求和事务签名（SIG（0）s）”[RFC2931]的方法，以允许AXFR客户端验证内容。这些技术也可用于授权。
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, and thus has 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.
不幸的是，无法发现退回到旧行为的需要，因此必须在配置文件中注明。实施应在其文档中鼓励运营商定期检查其反复记录的AXFR客户端和服务器，因为旧软件会不时更新。
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.
AXFR服务器可以对AXFR客户端的功能做出反应，但知道客户端是否可以接受每个AXFR响应消息的多个资源记录除外。无法发现客户受到如此限制的信息；因此，必须通过配置进行设置。
An implementation of an AXFR server MAY permit configuring, on a per AXFR client basis, the necessity to revert to a single resource record per message; in that case, the default SHOULD be to use multiple records per message.
AXFR服务器的实现可允许在每个AXFR客户端的基础上配置每个消息恢复为单个资源记录的必要性；在这种情况下，默认情况下应为每条消息使用多条记录。
An AXFR client has the opportunity to try other features (i.e., those not defined by this document) when querying an AXFR server.
查询AXFR服务器时，AXFR客户端有机会尝试其他功能（即本文档未定义的功能）。
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.
如果试图通过TCP传输为AXFR会话发出多个DNS查询中断了原始请求，则应中止查询，并应考虑AXFR服务器是否打算在原始（导致连接的）区域传输完成后立即关闭连接。
This document is a clarification of a mechanism outlined in RFCs 1034 and 1035 and as such does not add any new security considerations. RFC 3833 [RFC3833] is devoted entirely to security considerations for the DNS; its Section 4.3 delineates zone transfer security aspects from the security threats addressed by DNSSEC.
本文件是对RFCs 1034和1035中概述的机制的澄清，因此未添加任何新的安全注意事项。RFC 3833[RFC3833]完全用于DNS的安全考虑；其第4.3节从DNSSEC解决的安全威胁中描述了区域转移安全方面。
Concerns regarding authorization, traffic flooding, and message integrity are mentioned in "Authorization" (Section 5), "TCP" (Section 4.1), and "Zone Integrity" (Section 6).
“授权”（第5节）、“TCP”（第4.1节）和“区域完整性”（第6节）中提到了有关授权、流量泛滥和消息完整性的问题。
IANA has added a reference to this RFC in the AXFR (252) row of the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry.
IANA在“域名系统（DNS）参数”注册表的“资源记录（RR）类型”子区的AXFR（252）行中添加了对该RFC的引用。
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).
AXFR协议对DNS区域内容中可能受到国际化考虑的部分是透明的。假设对于DNS标签和域名，该问题已通过“应用程序中的域名国际化（IDNA）”[RFC3490]或其后续版本解决。
Earlier draft versions of this document have been edited by Andreas Gustafsson. In his latest draft version, this acknowledgment appeared:
本文件的早期草稿由Andreas Gustafsson编辑。在他的最新版本草稿中，出现了这样的致谢：
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.
许多人对本文件的早期版本提供了意见和评论，包括但不限于Bob Halley、Dan Bernstein、Eric A.Hall、Josh Littlefield、Kevin Darcy、Robert Elz、Levon Esibov、Mark Andrews、Michael Patton、Peter Koch、Sam Trenholme和Brian Wellington。
Comments on later draft versions have come from these individuals: Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, Niall O'Reilly, Bill Manning, and other participants of the DNSEXT working group. Significant comments from the IETF at large have been received from Subramanian Moonesamy, Chris Lonvick, and Vijay K. Gurbani.
对后来的草案版本的评论来自以下个人：马克·安德鲁斯、保罗·维克西、沃特·维恩加德斯、伊恩·卡尔德、托尼·芬奇、伊恩·杰克逊、安德烈亚斯·古斯塔夫松、布赖恩·惠灵顿、尼尔·奥赖利、比尔·曼宁以及DNSEXT工作组的其他参与者。来自IETF的重要评论已经从Subramanian Moonesay、Chris Lonvick和Vijay K.Gurbani收到。
Edward Lewis served as a patiently listening sole document editor for two years.
爱德华·刘易斯（Edward Lewis）担任了两年耐心倾听的唯一文档编辑。
All "RFC" references below -- like all RFCs -- and information about the RFC series can be obtained from the RFC Editor web site at http://www.rfc-editor.org.
下面所有的“RFC”参考——就像所有的RFC一样——以及关于RFC系列的信息都可以从RFC编辑器网站上获得，网址是http://www.rfc-editor.org.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1996]Vixie，P.，“区域变更即时通知机制（DNS通知）”，RFC 1996，1996年8月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
[RFC2672]克劳福德，M.，“非终端DNS名称重定向”，RFC 26721999年8月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930]Eastlake 3rd，D.，“DNS密钥建立（TKEY RR）”，RFC 2930，2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931]Eastlake 3rd，D.，“DNS请求和事务签名（SIG（0）s）”，RFC 29312000年9月。
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002.
[RFC3425]劳伦斯，D.，“淘汰液体”，RFC 34252002年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", RFC 4635, August 2006.
[RFC4635]Eastlake 3rd，D.，“HMAC SHA（哈希消息认证码，安全哈希算法）TSIG算法标识符”，RFC 4635，2006年8月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC5395] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 5395, November 2008.
[RFC5395]Eastlake 3rd，D.，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 53952008年11月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，2009年10月。
[DNSVALS] IANA Registry "Domain Name System (DNS) Parameters", http://www.iana.org/.
[DNSVALS]IANA注册表“域名系统（DNS）参数”，http://www.iana.org/.
[IANA-AF] IANA Registry "Address Family Numbers", http://www.iana.org/.
[IANA-AF]IANA注册表“地址系列号”，http://www.iana.org/.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764]Gleeson，B.，Lin，A.，Heinanen，J.，Armitage，G.，和A.Malis，“基于IP的虚拟专用网络框架”，RFC 2764，2000年2月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[DNSSEC-U] Weiler, S. and D. Blacka, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2010.
[DNSSEC-U]Weiler，S.和D.Blacka，“DNSSECbis的澄清和实施说明”，正在进行的工作，2010年3月。
Authors' Addresses
作者地址
Edward Lewis 46000 Center Oak Plaza Sterling, VA 20166 US
爱德华·刘易斯46000中心奥克广场斯特林，弗吉尼亚州，美国20166
EMail: ed.lewis@neustar.biz
EMail: ed.lewis@neustar.biz
Alfred Hoenes, Editor TR-Sys Gerlinger Str. 12 Ditzingen D-71254 Germany
Alfred Hoenes，编辑TR Sys Gerlinger Str.12 Ditzingen D-71254德国
EMail: ah@TR-Sys.de
EMail: ah@TR-Sys.de