Internet Engineering Task Force (IETF) J. Damas
Request for Comments: 6891 Bond Internet Systems
STD: 75 M. Graff
Obsoletes: 2671, 2673
Category: Standards Track P. Vixie
ISSN: 2070-1721 Internet Systems Consortium
April 2013
Internet Engineering Task Force (IETF) J. Damas
Request for Comments: 6891 Bond Internet Systems
STD: 75 M. Graff
Obsoletes: 2671, 2673
Category: Standards Track P. Vixie
ISSN: 2070-1721 Internet Systems Consortium
April 2013
Extension Mechanisms for DNS (EDNS(0))
DNS的扩展机制（EDN（0））
Abstract
摘要
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.
域名系统的wire协议包括许多固定字段，这些字段的范围已经或即将用尽，不允许请求者向响应者公布其功能。本文档描述了允许协议增长的向后兼容机制。
This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.
本文档根据几个实现中的部署经验反馈，更新DNS（EDNS（0））规范的扩展机制（并淘汰RFC 2671）。它还淘汰了RFC 2673（“域名系统中的二进制标签”），并增加了在DNS中使用扩展标签的注意事项。
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/rfc6891.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6891.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5
4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11
6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5
4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5
4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6
5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6
6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9
6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10
6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10
6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11
6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11
6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11
7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16
DNS [RFC1035] specifies a message format, and within such messages there are standard formats for encoding options, errors, and name compression. The maximum allowable size of a DNS message over UDP not using the extensions described in this document is 512 bytes. Many of DNS's protocol limits, such as the maximum message size over UDP, are too small to efficiently support the additional information that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS Security (DNSSEC) signatures). Finally, RFC 1035 does not define any way for implementations to advertise their capabilities to any of the other actors they interact with.
DNS[RFC1035]指定消息格式，在这些消息中有用于编码选项、错误和名称压缩的标准格式。不使用本文档中描述的扩展名的UDP上DNS消息的最大允许大小为512字节。DNS的许多协议限制（例如UDP上的最大消息大小）太小，无法有效支持DNS中可以传输的附加信息（例如，多个IPv6地址或DNS安全（DNSSEC）签名）。最后，RFC1035没有为实现定义任何向与之交互的任何其他参与者宣传其功能的方式。
[RFC2671] added extension mechanisms to DNS. These mechanisms are widely supported, and a number of new DNS uses and protocol extensions depend on the presence of these extensions. This memo refines and obsoletes [RFC2671].
[RFC2671]向DNS添加了扩展机制。这些机制得到广泛支持，许多新的DNS使用和协议扩展依赖于这些扩展的存在。本备忘录对[RFC2671]进行了改进和淘汰。
Unextended agents will not know how to interpret the protocol extensions defined in [RFC2671] and restated here. Extended agents need to be prepared for handling the interactions with unextended clients in the face of new protocol elements and fall back gracefully to unextended DNS.
未扩展的代理将不知道如何解释[RFC2671]中定义并在此处重述的协议扩展。扩展代理需要准备好在面对新的协议元素时处理与未扩展客户端的交互，并优雅地退回到未扩展DNS。
EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, for instance, the stub resolver communicating with the recursive resolver or the recursive resolver communicating with an authoritative server.
EDNS是DNS的逐跳扩展。这意味着在DNS解析过程中，EDN的使用在每对主机之间进行协商，例如，与递归解析程序通信的存根解析程序或与权威服务器通信的递归解析程序。
[RFC2671] specified extended label types. The only such label proposed was in [RFC2673] for a label type called "Bit-String Label" or "Binary Labels", with this latest term being the one in common use. For various reasons, introducing a new label type was found to be extremely difficult, and [RFC2673] was moved to Experimental. This document obsoletes [RFC2673], deprecating Binary Labels. Extended labels remain defined, but their use is discouraged due to practical difficulties with deployment; their use in the future SHOULD only be considered after careful evaluation of the deployment hindrances.
[RFC2671]指定的扩展标签类型。[RFC2673]中提出的唯一此类标签是一种称为“位字符串标签”或“二进制标签”的标签类型，最新术语是常用术语。由于各种原因，引入新的标签类型被认为是极其困难的，因此[RFC2673]被转移到了实验阶段。本文档废弃了[RFC2673]，不推荐使用二进制标签。扩展标签仍有定义，但由于部署的实际困难，不鼓励使用扩展标签；只有在仔细评估部署障碍后，才应考虑将来使用它们。
"Requestor" refers to the side that sends a request. "Responder" refers to an authoritative, recursive resolver or other DNS component that responds to questions. Other terminology is used here as defined in the RFCs cited by this document.
“请求者”指发送请求的一方。“响应者”是指一个权威的递归解析器或其他DNS组件，用于响应问题。此处使用本文件引用的RFC中定义的其他术语。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
EDNS provides a mechanism to improve the scalability of DNS as its uses get more diverse on the Internet. It does this by enabling the use of UDP transport for DNS messages with sizes beyond the limits specified in RFC 1035 as well as providing extra data space for additional flags and return codes (RCODEs). However, implementation experience indicates that adding new RCODEs should be avoided due to the difficulty in upgrading the installed base. Flags SHOULD be used only when necessary for DNS resolution to function.
随着DNS在Internet上的使用越来越多样化，EDNS提供了一种机制来提高DNS的可伸缩性。它通过允许对大小超过RFC 1035中规定的限制的DNS消息使用UDP传输以及为附加标志和返回码（RCODE）提供额外的数据空间来实现这一点。然而，实施经验表明，由于难以升级安装基数，应避免添加新的RCODE。仅当DNS解析需要运行时才应使用标志。
For many uses, an EDNS Option Code may be preferred.
对于许多用途，EDNS选项代码可能是首选。
Over time, some applications of DNS have made EDNS a requirement for their deployment. For instance, DNSSEC uses the additional flag space introduced in EDNS to signal the request to include DNSSEC data in a DNS response.
随着时间的推移，DNS的一些应用程序已经要求部署EDN。例如，DNSSEC使用EDNS中引入的附加标志空间来向请求发送信号，以在DNS响应中包含DNSSEC数据。
Given the increase in DNS response sizes when including larger data items such as AAAA records, DNSSEC information (e.g., RRSIG or DNSKEY), or large TXT records, the additional UDP payload capabilities provided by EDNS can help improve the scalability of the DNS by avoiding widespread use of TCP for DNS transport.
考虑到当包含较大的数据项（如AAAA记录、DNSSEC信息（如RRSIG或DNSKEY）或较大的TXT记录）时DNS响应大小的增加，EDNS提供的额外UDP有效负载功能可以通过避免广泛使用TCP进行DNS传输来帮助提高DNS的可伸缩性。
The DNS message header's second full 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see Section 4.1.1 of [RFC1035]). Some of these flag values were marked for future use, and most of these have since been allocated. Also, most of the RCODE values are now in use. The OPT pseudo-RR specified below contains extensions to the RCODE bit field as well as additional flag bits.
DNS消息头的第二个完整16位字分为4位操作码、4位RCODE和多个1位标志（见[RFC1035]第4.1.1节）。其中一些标志值已标记以供将来使用，其中大部分已分配。此外，大多数RCODE值现在正在使用中。下面指定的OPT伪RR包含对RCODE位字段的扩展以及其他标志位。
The first 2 bits of a wire format domain label are used to denote the type of the label. [RFC1035] allocates 2 of the 4 possible types and reserves the other 2. More label types were defined in [RFC2671]. The use of the 2-bit combination defined by [RFC2671] to identify extended label types remains valid. However, it has been found that deployment of new label types is noticeably difficult and so is only
wire格式域标签的前2位用于表示标签的类型。[RFC1035]分配4种可能类型中的2种，并保留其他2种。[RFC2671]中定义了更多标签类型。使用[RFC2671]定义的2位组合来标识扩展标签类型仍然有效。然而，已经发现部署新标签类型非常困难，因此只有
recommended after careful evaluation of alternatives and the need for deployment.
在仔细评估替代方案和部署需求后推荐。
Traditional DNS messages are limited to 512 octets in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold.
通过UDP[RFC1035]发送时，传统DNS消息的大小限制为512个八位字节。在这个512字节的限制下，适应DNS中可以传输的越来越多的数据变得越来越困难。例如，包含DNSSEC记录通常需要比512字节消息所能容纳的响应大得多的响应。
EDNS(0) specifies a way to advertise additional features such as larger response size capability, which is intended to help avoid truncated UDP responses, which in turn cause retry over TCP. It therefore provides support for transporting these larger packet sizes without needing to resort to TCP for transport.
EDNS（0）指定了一种公布附加功能的方法，例如更大的响应大小功能，其目的是帮助避免截断UDP响应，从而导致通过TCP重试。因此，它支持传输这些较大的数据包，而无需借助TCP进行传输。
The first octet in the on-the-wire representation of a DNS label specifies the label type; the basic DNS specification [RFC1035] dedicates the 2 most significant bits of that octet for this purpose.
DNS标签的在线表示中的第一个八位字节指定标签类型；基本DNS规范[RFC1035]将该八位字节的2个最高有效位专用于此目的。
[RFC2671] defined DNS label type 0b01 for use as an indication for extended label types. A specific extended label type was selected by the 6 least significant bits of the first octet. Thus, extended label types were indicated by the values 64-127 (0b01xxxxxx) in the first octet of the label.
[RFC2671]定义了DNS标签类型0b01，用作扩展标签类型的指示。由第一个八位组的6个最低有效位选择特定的扩展标签类型。因此，扩展标签类型由标签第一个八位字节中的值64-127（0b01xxxxxx）表示。
Extended label types are extremely difficult to deploy due to lack of support in clients and intermediate gateways, as described in [RFC3363], which moved [RFC2673] to Experimental status; and [RFC3364], which describes the pros and cons. As such, proposals that contemplate extended labels SHOULD weigh this deployment cost against the possibility of implementing functionality in other ways.
如[RFC3363]中所述，由于客户端和中间网关中缺乏支持，扩展标签类型极难部署，这将[RFC2673]移至实验状态；和[RFC3364]，其中描述了优点和缺点。因此，考虑扩展标签的建议应该权衡部署成本和以其他方式实现功能的可能性。
Finally, implementations MUST NOT generate or pass Binary Labels in their communications, as they are now deprecated.
最后，实现不能在其通信中生成或传递二进制标签，因为它们现在已被弃用。
An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the additional data section of a request.
OPT伪RR（有时称为meta RR）可以添加到请求的附加数据部分。
The OPT RR has RR type 41.
OPT RR具有RR类型41。
If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective responses.
如果收到的请求中存在OPT记录，则符合要求的响应者必须在其各自的响应中包含OPT记录。
An OPT record does not carry any DNS data. It is used only to contain control information pertaining to the question-and-answer sequence of a specific transaction. OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files.
OPT记录不携带任何DNS数据。它仅用于包含与特定事务的问答顺序相关的控制信息。OPT RRs不得缓存、转发、存储在主文件中或从主文件加载。
The OPT RR MAY be placed anywhere within the additional data section. When an OPT RR is included within any DNS message, it MUST be the only OPT RR in that message. If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned. The placement flexibility for the OPT RR does not override the need for the TSIG or SIG(0) RRs to be the last in the additional section whenever they are present.
OPT RR可放置在附加数据段内的任何位置。当任何DNS消息中包含OPT RR时，它必须是该消息中唯一的OPT RR。如果收到具有多个OPT RR的查询消息，则必须返回FORMERR（RCODE=1）。OPT RR的放置灵活性不会覆盖TSIG或SIG（0）RRs在附加部分中的最后一个（无论何时出现）需求。
An OPT RR has a fixed part and a variable set of options expressed as {attribute, value} pairs. The fixed part holds some DNS metadata, and also a small collection of basic extension elements that we expect to be so popular that it would be a waste of wire space to encode them as {attribute, value} pairs.
OPT RR有一个固定的部分和一组变量选项，这些选项表示为{attribute，value}对。固定部分包含一些DNS元数据，以及一个基本扩展元素的小集合，我们希望这些元素非常流行，将它们编码为{attribute，value}对将浪费布线空间。
The fixed part of an OPT RR is structured as follows:
OPT RR的固定部分结构如下：
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
+------------+--------------+------------------------------+
| Field Name | Field Type | Description |
+------------+--------------+------------------------------+
| NAME | domain name | MUST be 0 (root domain) |
| TYPE | u_int16_t | OPT (41) |
| CLASS | u_int16_t | requestor's UDP payload size |
| TTL | u_int32_t | extended RCODE and flags |
| RDLEN | u_int16_t | length of all RDATA |
| RDATA | octet stream | {attribute,value} pairs |
+------------+--------------+------------------------------+
OPT RR Format
OPT RR格式
The variable part of an OPT RR may contain zero or more options in the RDATA. Each option MUST be treated as a bit field. Each option is encoded as:
OPT RR的可变部分在RDATA中可能包含零个或多个选项。每个选项必须视为一个位字段。每个选项编码为：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTION-CODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | |
/ OPTION-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
OPTION-CODE Assigned by the Expert Review process as defined by the DNSEXT working group and the IESG.
由DNSEXT工作组和IESG定义的专家评审程序指定的选项代码。
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATA的OPTION-LENGTH大小（以八位字节为单位）。
OPTION-DATA Varies per OPTION-CODE. MUST be treated as a bit field.
选项数据因选项代码而异。必须将其视为位字段。
The order of appearance of option tuples is not defined. If one option modifies the behaviour of another or multiple options are related to one another in some way, they have the same effect regardless of ordering in the RDATA wire encoding.
未定义选项元组的出现顺序。如果一个选项修改另一个选项的行为，或者多个选项以某种方式相互关联，则无论RDATA导线编码中的顺序如何，它们都具有相同的效果。
Any OPTION-CODE values not understood by a responder or requestor MUST be ignored. Specifications of such options might wish to include some kind of signaled acknowledgement. For example, an option specification might say that if a responder sees and supports option XYZ, it MUST include option XYZ in its response.
必须忽略响应者或请求者无法理解的任何选项代码值。此类选项的规范可能希望包括某种信号确认。例如，选项规范可能会说，如果响应者看到并支持选项XYZ，则必须在其响应中包含选项XYZ。
The extended RCODE and flags, which OPT stores in the RR Time to Live (TTL) field, are structured as follows:
扩展的RCODE和标志存储在RR生存时间（TTL）字段中，其结构如下：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms the upper 8 bits of extended 12-bit RCODE (together with the 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 indicates that an unextended RCODE is in use (values 0 through 15).
EXTENDED-RCODE构成扩展12位RCODE的上8位（以及[RFC1035]中定义的4位）。请注意，EXTENDED-RCODE值0表示正在使用未扩展的RCODE（值0到15）。
VERSION Indicates the implementation level of the setter. Full conformance with this specification is indicated by version '0'. Requestors are encouraged to set this to the lowest implemented level capable of expressing a transaction, to minimise the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy MAY ideally be a run-time configuration option. If a responder does not implement the VERSION level of the request, then it MUST respond with RCODE=BADVERS. All responses MUST be limited in format to the VERSION level of the request, but the VERSION of each response SHOULD be the highest implementation level of the responder. In this way, a requestor will learn the implementation level of a responder as a side effect of every response, including error responses and including RCODE=BADVERS.
VERSION表示setter的实现级别。版本“0”表示完全符合本规范。鼓励请求者将其设置为能够表示事务的最低实现级别，以最小化响应者和发现请求者和响应者之间最大公共实现级别的网络负载。请求者的版本编号策略在理想情况下可能是运行时配置选项。如果响应程序未实现请求的版本级别，则必须使用RCODE=BADVERS进行响应。所有响应的格式必须限制为请求的版本级别，但每个响应的版本应该是响应者的最高实现级别。通过这种方式，请求者将了解响应者的实现级别作为每个响应的副作用，包括错误响应和RCODE=BADVERS。
DO DNSSEC OK bit as defined by [RFC3225].
执行[RFC3225]定义的DNSSEC OK位。
Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification.
Z由发送方设置为零，接收方忽略，除非在后续规范中修改。
The OPT record MUST NOT be cached.
不能缓存OPT记录。
If a requestor detects that the remote end does not support EDNS(0), it MAY issue queries without an OPT record. It MAY cache this knowledge for a brief time in order to avoid fallback delays in the future. However, if DNSSEC or any future option using EDNS is required, no fallback should be performed, as these options are only signaled through EDNS. If an implementation detects that some servers for the zone support EDNS(0) while others would force the use of TCP to fetch all data, preference MAY be given to servers that support EDNS(0). Implementers SHOULD analyse this choice and the impact on both endpoints.
如果请求者检测到远程端不支持EDN（0），它可能会发出没有OPT记录的查询。它可能会在短时间内缓存这些知识，以避免将来的回退延迟。但是，如果需要使用EDN的DNSSEC或任何未来选项，则不应执行回退，因为这些选项仅通过EDN发出信号。如果实现检测到区域的某些服务器支持EDN（0），而其他服务器将强制使用TCP获取所有数据，则可能会优先选择支持EDN（0）的服务器。实施者应该分析这种选择以及对两个端点的影响。
The requestor's UDP payload size (encoded in the RR CLASS field) is the number of octets of the largest UDP payload that can be reassembled and delivered in the requestor's network stack. Note that path MTU, with or without fragmentation, could be smaller than this.
请求者的UDP有效负载大小（在RR CLASS字段中编码）是最大UDP有效负载的八位字节数，可在请求者的网络堆栈中重新组装和交付。请注意，路径MTU（带或不带碎片）可能小于此值。
Values lower than 512 MUST be treated as equal to 512.
小于512的值必须视为等于512。
The requestor SHOULD place a value in this field that it can actually receive. For example, if a requestor sits behind a firewall that will block fragmented IP packets, a requestor SHOULD NOT choose a value that will cause fragmentation. Doing so will prevent large responses from being received and can cause fallback to occur. This knowledge may be auto-detected by the implementation or provided by a human administrator.
请求者应该在这个字段中放置一个它实际上可以接收的值。例如，如果请求者位于防火墙后面，防火墙将阻止碎片化的IP数据包，则请求者不应选择会导致碎片化的值。这样做将防止收到大量响应，并可能导致回退。这种知识可以由实现自动检测，也可以由人工管理员提供。
Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over Ethernet would be reasonable.
请注意，512八位UDP有效负载需要576八位IP重组缓冲区。通过以太网在1280和1410字节之间选择IP（v4或v6）是合理的。
Where fragmentation is not a concern, use of bigger values SHOULD be considered by implementers. Implementations SHOULD use their largest configured or implemented values as a starting point in an EDNS transaction in the absence of previous knowledge about the destination server.
在不考虑碎片的情况下，实现者应该考虑使用更大的值。在以前不了解目标服务器的情况下，实现应将其最大的配置值或实现值用作EDNS事务的起点。
Choosing a very large value will guarantee fragmentation at the IP layer, and may prevent answers from being received due to loss of a single fragment or to misconfigured firewalls.
选择一个非常大的值将保证IP层的碎片化，并且可能会由于单个碎片丢失或防火墙配置错误而阻止接收应答。
The requestor's maximum payload size can change over time. It MUST NOT be cached for use beyond the transaction in which it is advertised.
请求者的最大有效负载大小可以随时间变化。不得将其缓存以供在其发布的事务之外使用。
The responder's maximum payload size can change over time but can reasonably be expected to remain constant between two closely spaced sequential transactions, for example, an arbitrary QUERY used as a probe to discover a responder's maximum UDP payload size, followed immediately by an UPDATE that takes advantage of this size. This is considered preferable to the outright use of TCP for oversized requests, if there is any reason to suspect that the responder implements EDNS, and if a request will not fit in the default 512-byte payload size limit.
响应者的最大有效负载大小可以随时间变化，但可以合理地预期在两个紧密间隔的连续事务之间保持不变，例如，用作探测的任意查询发现响应者的最大UDP有效负载大小，然后立即进行利用此大小的更新。如果有任何理由怀疑响应者实施了EDN，并且如果请求不符合默认的512字节有效负载大小限制，则认为这比完全使用TCP处理超大请求更可取。
Due to transaction overhead, it is not recommended to advertise an architectural limit as a maximum UDP payload size. Even on system stacks capable of reassembling 64 KB datagrams, memory usage at low levels in the system will be a concern. A good compromise may be the use of an EDNS maximum payload size of 4096 octets as a starting point.
由于事务开销，不建议将架构限制作为最大UDP有效负载大小公布。即使在能够重新组装64 KB数据报的系统堆栈上，系统中较低级别的内存使用也会引起关注。一个很好的折衷方案可能是使用4096个八位字节的EDNS最大有效负载大小作为起点。
A requestor MAY choose to implement a fallback to smaller advertised sizes to work around firewall or other network limitations. A requestor SHOULD choose to use a fallback mechanism that begins with a large size, such as 4096. If that fails, a fallback around the range of 1280-1410 bytes SHOULD be tried, as it has a reasonable chance to fit within a single Ethernet frame. Failing that, a requestor MAY choose a 512-byte packet, which with large answers may cause a TCP retry.
请求者可以选择实施回退到较小的广告大小，以绕过防火墙或其他网络限制。请求者应该选择使用一种从大容量开始的回退机制，例如4096。如果失败，应尝试1280-1410字节范围内的回退，因为它有合理的机会适应单个以太网帧。否则，请求者可能会选择一个512字节的数据包，该数据包的答案较大，可能会导致TCP重试。
Values of less than 512 bytes MUST be treated as equal to 512 bytes.
小于512字节的值必须视为等于512字节。
In a network that carries DNS traffic, there could be active equipment other than that participating directly in the DNS resolution process (stub and caching resolvers, authoritative servers) that affects the transmission of DNS messages (e.g., firewalls, load balancers, proxies, etc.), referred to here as "middleboxes".
在承载DNS流量的网络中，可能存在直接参与DNS解析过程（存根和缓存解析程序、权威服务器）以外的活动设备，这些设备影响DNS消息的传输（例如防火墙、负载平衡器、代理等），此处称为“中间箱”。
Conformant middleboxes MUST NOT limit DNS messages over UDP to 512 bytes.
一致性中间件不得将UDP上的DNS消息限制为512字节。
Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction.
仅将请求转发给递归解析程序的中间盒不得修改或删除任意方向的OPT记录内容。
Middleboxes that have additional functionality, such as answering queries or acting as intelligent forwarders, SHOULD be able to process the OPT record and act based on its contents. These middleboxes MUST consider the incoming request and any outgoing requests as separate transactions if the characteristics of the messages are different.
具有附加功能（如回答查询或充当智能转发器）的中间盒应能够处理OPT记录并根据其内容进行操作。如果消息的特性不同，这些中间框必须考虑传入请求和任何传出请求作为单独的事务。
A more in-depth discussion of this type of equipment and other considerations regarding their interaction with DNS traffic is found in [RFC5625].
[RFC5625]中对此类设备及其与DNS流量交互的其他考虑因素进行了更深入的讨论。
The presence of an OPT pseudo-RR in a request should be taken as an indication that the requestor fully implements the given version of EDNS and can correctly understand any response that conforms to that feature's specification.
请求中存在OPT伪RR应被视为表明请求者完全实现了给定版本的EDN，并且能够正确理解符合该功能规范的任何响应。
Lack of presence of an OPT record in a request MUST be taken as an indication that the requestor does not implement any part of this specification and that the responder MUST NOT include an OPT record in its response.
请求中不存在OPT记录必须视为请求者未实施本规范任何部分的指示，且响应者不得在其响应中包含OPT记录。
Extended agents MUST be prepared for handling interactions with unextended clients in the face of new protocol elements and fall back gracefully to unextended DNS when needed.
扩展代理必须准备好在面对新的协议元素时处理与未扩展客户端的交互，并在需要时优雅地退回到未扩展的DNS。
Responders that choose not to implement the protocol extensions defined in this document MUST respond with a return code (RCODE) of FORMERR to messages containing an OPT record in the additional section and MUST NOT include an OPT record in the response.
选择不实施本文档中定义的协议扩展的响应者必须使用FORMERR返回码（RCODE）对附加部分中包含OPT记录的消息进行响应，并且不得在响应中包含OPT记录。
If there is a problem with processing the OPT record itself, such as an option value that is badly formatted or that includes out-of-range values, a FORMERR MUST be returned. If this occurs, the response MUST include an OPT record. This is intended to allow the requestor to distinguish between servers that do not implement EDNS and format errors within EDNS.
如果处理OPT记录本身时出现问题，例如选项值格式错误或包含超出范围的值，则必须返回FORMERR。如果发生这种情况，响应必须包括OPT记录。这是为了允许请求者区分未实现EDN的服务器和EDN中的格式错误。
The minimal response MUST be the DNS header, question section, and an OPT record. This MUST also occur when a truncated response (using the DNS header's TC bit) is returned.
最小响应必须是DNS头、问题部分和OPT记录。当返回截断响应（使用DNS头的TC位）时，也必须发生这种情况。
Requestor-side specification of the maximum buffer size may open a DNS denial-of-service attack if responders can be made to send messages that are too large for intermediate gateways to forward, thus leading to potential ICMP storms between gateways and responders.
如果响应者发送的消息太大，中间网关无法转发，从而导致网关和响应者之间潜在的ICMP风暴，则请求者端指定的最大缓冲区大小可能会引发DNS拒绝服务攻击。
Announcing very large UDP buffer sizes may result in dropping of DNS messages by middleboxes (see Section 6.2.6). This could cause retransmissions with no hope of success. Some devices have been found to reject fragmented UDP packets.
宣布非常大的UDP缓冲区大小可能会导致中间盒丢弃DNS消息（请参阅第6.2.6节）。这可能导致重新传输没有成功的希望。已发现一些设备拒绝分段UDP数据包。
Announcing UDP buffer sizes that are too small may result in fallback to TCP with a corresponding load impact on DNS servers. This is especially important with DNSSEC, where answers are much larger.
宣布UDP缓冲区大小过小可能会导致退回到TCP，并对DNS服务器产生相应的负载影响。这对于DNSSEC尤其重要，因为DNSSEC的答案要大得多。
The IANA has assigned RR type code 41 for OPT.
IANA为OPT分配了RR类型代码41。
[RFC2671] specified a number of IANA subregistries within "DOMAIN NAME SYSTEM PARAMETERS":
[RFC2671]在“域名系统参数”中指定了许多IANA子地区：
o DNS EDNS(0) Options
o DNS EDNS（0）选项
o EDNS Version Number
o EDNS版本号
o EDNS Header Flags
o EDNS头标志
Additionally, two entries were generated in existing registries:
此外，在现有登记处生成了两个条目：
o EDNS Extended Label Type in the DNS Label Types registry
o DNS标签类型注册表中的EDNS扩展标签类型
o Bad OPT Version in the DNS RCODES registry
o DNS RCODES注册表中的OPT版本错误
IANA has updated references to [RFC2671] in these entries and subregistries to this document.
IANA已更新了本文件这些条目和子区域中对[RFC2671]的引用。
[RFC2671] created the DNS Label Types registry. This registry is to remain open.
[RFC2671]创建了DNS标签类型注册表。此注册表将保持打开状态。
The registration procedure for the DNS Label Types registry is Standards Action.
DNS标签类型注册表的注册过程是标准操作。
This document assigns option code 65535 in the DNS EDNS0 Options registry to "Reserved for future expansion".
本文档将DNS EDNS0选项注册表中的选项代码65535指定为“保留供将来扩展”。
The current status of the IANA registry for EDNS Option Codes at the time of publication of this document is
本文件发布时，EDNS选项代码IANA注册表的当前状态为
o 0-4 assigned, per references in the registry
o 为注册表中的每个引用分配0-4个
o 5-65000 Available for assignment, unassigned
o 5-65000可分配，未分配
o 65001-65534 Local/Experimental use
o 65001-65534本地/实验使用
o 65535 Reserved for future expansion
o 65535保留供将来扩展
[RFC2671] expands the RCODE space from 4 bits to 12 bits. This allows more than the 16 distinct RCODE values allowed in [RFC1035]. IETF Review is required to add a new RCODE.
[RFC2671]将RCODE空间从4位扩展到12位。这允许超过[RFC1035]中允许的16个不同RCODE值。需要IETF审查以添加新的RCODE。
This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS RCODES registry.
本文档将EDNS扩展RCODE 16分配给DNS RCODE注册表中的“BADVERS”。
[RFC2671] called for the recording of assignment of extended label types 0bxx111111 as "Reserved for future extended label types"; the IANA registry currently contains "Reserved for future expansion". This request implied, at that time, a request to open a new registry for extended label types, but due to the possibility of ambiguity, new text registrations were instead made within the general DNS Label Types registry, which also registers entries originally defined by [RFC1035]. There is therefore no Extended Label Types registry, with all label types registered in the DNS Label Types registry.
[RFC2671]要求将扩展标签类型0bxx111111的分配记录为“为将来的扩展标签类型保留”；IANA注册表当前包含“保留以备将来扩展”。当时，该请求意味着请求为扩展标签类型打开一个新的注册表，但由于可能存在歧义，在通用DNS标签类型注册表中进行了新的文本注册，该注册表也注册了[RFC1035]最初定义的条目。因此，没有扩展标签类型注册表，所有标签类型都注册在DNS标签类型注册表中。
This document deprecates Binary Labels. Therefore, the status for the DNS Label Types registration "Binary Labels" is now "Historic".
本文档不推荐使用二进制标签。因此，DNS标签类型注册“二进制标签”的状态现在为“历史”。
IETF Standards Action is required for assignments of new EDNS(0) flags. Flags SHOULD be used only when necessary for DNS resolution to function. For many uses, an EDNS Option Code may be preferred.
新EDN（0）标志的分配需要IETF标准行动。仅当DNS解析需要运行时才应使用标志。对于许多用途，EDNS选项代码可能是首选。
IETF Standards Action is required to create new entries in the EDNS Version Number registry. Within the EDNS Option Code space, Expert Review is required for allocation of an EDNS Option Code. Per this document, IANA maintains a registry for the EDNS Option Code space.
需要IETF标准行动在EDNS版本号注册表中创建新条目。在EDNS选项代码空间内，EDNS选项代码的分配需要专家审查。根据本文档，IANA为EDNS选项代码空间维护一个注册表。
OPT Option Codes are assigned by Expert Review.
OPT选项代码由专家评审分配。
Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided.
选项代码的分配应自由，但应避免重复功能。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
[RFC3225]Conrad，D.“指示DNSSEC的分解器支持”，RFC 3225，2001年12月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]克劳福德，M.，“域名系统中的二进制标签”，RFC2673，1999年8月。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 33632002年8月。
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", RFC 3364, August 2002.
[RFC3364]Austein，R.，“互联网协议版本6（IPv6）的域名系统（DNS）支持权衡”，RFC 3364，2002年8月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 56252009年8月。
Following is a list of high-level changes to RFCs 2671 and 2673.
以下是RFCs 2671和2673的高级更改列表。
o Support for the OPT record is now mandatory.
o 现在必须支持OPT记录。
o Extended label types remain available, but their use is discouraged as a general solution due to observed difficulties in their deployment on the Internet, as illustrated by the work with the "Binary Labels" type.
o 扩展标签类型仍然可用，但不鼓励将其作为一般解决方案使用，因为在Internet上部署时遇到了困难，如使用“二进制标签”类型所示。
o RFC 2673, which defined the "Binary Labels" type and is currently Experimental, is requested to be moved to Historic.
o RFC 2673定义了“二进制标签”类型，目前处于试验阶段，要求将其移动到历史位置。
o Made changes in how EDNS buffer sizes are selected, and provided recommendations on how to select them.
o 对如何选择EDNS缓冲区大小进行了更改，并提供了有关如何选择它们的建议。
Authors' Addresses
作者地址
Joao Damas Bond Internet Systems Av Albufera 14 S.S. Reyes, Madrid 28701 ES
霍奥·达马斯·邦德互联网系统Av Albufera 14 S.S.雷耶斯，马德里28701 ES
Phone: +1 650.423.1312
EMail: joao@bondis.org
Phone: +1 650.423.1312
EMail: joao@bondis.org
Michael Graff
迈克尔·格拉夫
EMail: explorer@flame.org
EMail: explorer@flame.org
Paul Vixie Internet Systems Consortium 950 Charter Street Redwood City, California 94063 US
Paul Vixie互联网系统联合体950 Charter Street Redwood City，加利福尼亚州94063美国
Phone: +1 650.423.1301
EMail: vixie@isc.org
Phone: +1 650.423.1301
EMail: vixie@isc.org