Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
Network Working Group P. Vixie
Request for Comments: 2671 ISC
Category: Standards Track August 1999
Extension Mechanisms for DNS (EDNS0)
DNS的扩展机制（EDNS0）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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 clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.
域名系统的wire协议包括许多固定字段，这些字段的范围已经或即将用尽，不允许客户端向服务器公布其功能。本文档描述了允许协议增长的向后兼容机制。
1 - Rationale and Scope
1-理由和范围
1.1. DNS (see [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 is fixed. Many of DNS's protocol limits are too small for uses which are or which are desired to become common. There is no way for implementations to advertise their capabilities.
1.1. DNS（请参见[RFC1035]）指定消息格式，在这些消息中有用于编码选项、错误和名称压缩的标准格式。DNS消息的最大允许大小是固定的。DNS的许多协议限制太小，无法用于或希望成为常见的用途。实现无法宣传其功能。
1.2. Existing clients will not know how to interpret the protocol extensions detailed here. In practice, these clients will be upgraded when they have need of a new feature, and only new features will make use of the extensions. We must however take account of client behaviour in the face of extra fields, and design a fallback scheme for interoperability with these clients.
1.2. 现有客户端将不知道如何解释此处详述的协议扩展。实际上，当这些客户机需要一个新特性时，它们将被升级，并且只有新特性才会使用扩展。然而，我们必须考虑客户在面对额外字段时的行为，并设计一个与这些客户机互操作的后备方案。
2 - Affected Protocol Elements
2-受影响的协议要素
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags. The original reserved Z bits have been allocated to various purposes, and most of the RCODE values are now in use. More flags and more possible RCODEs are needed.
2.1. DNS消息头（请参见[RFC1035 4.1.1]）第二个完整的16位字分为4位操作码、4位RCODE和多个1位标志。原始保留Z位已分配用于各种用途，大多数RCODE值现在正在使用。需要更多的标志和更多可能的RCODE。
2.2. The first two bits of a wire format domain label are used to denote the type of the label. [RFC1035 4.1.4] allocates two of the four possible types and reserves the other two. Proposals for use of the remaining types far outnumber those available. More label types are needed.
2.2. wire格式域标签的前两位用于表示标签的类型。[RFC1035 4.1.4]分配四种可能类型中的两种，并保留其他两种。使用其余类型的建议数量远远超过现有的建议数量。需要更多的标签类型。
2.3. DNS Messages are limited to 512 octets in size when sent over UDP. While the minimum maximum reassembly buffer size still allows a limit of 512 octets of UDP payload, most of the hosts now connected to the Internet are able to reassemble larger datagrams. Some mechanism must be created to allow requestors to advertise larger buffer sizes to responders.
2.3. 通过UDP发送时，DNS消息的大小限制为512个八位字节。虽然最小最大重组缓冲区大小仍然允许512个八位字节的UDP有效负载，但现在连接到Internet的大多数主机都能够重组更大的数据报。必须创建一些机制，以允许请求者向响应者公布更大的缓冲区大小。
3 - Extended Label Types
3-扩展标签类型
3.1. The "0 1" label type will now indicate an extended label type, whose value is encoded in the lower six bits of the first octet of a label. All subsequently developed label types should be encoded using an extended label type.
3.1. “0 1”标签类型现在将指示扩展标签类型，其值编码在标签第一个八位字节的下六位。所有后续开发的标签类型都应使用扩展标签类型进行编码。
3.2. The "1 1 1 1 1 1" extended label type will be reserved for future expansion of the extended label type code space.
3.2. “1”扩展标签类型将保留，以便将来扩展扩展标签类型代码空间。
4 - OPT pseudo-RR
4-OPT伪RR
4.1. One OPT pseudo-RR can be added to the additional data section of either a request or a response. An OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data. OPT RRs shall never be cached, forwarded, or stored in or loaded from master files. The quantity of OPT pseudo-RRs per message shall be either zero or one, but not greater.
4.1. 可以向请求或响应的附加数据部分添加一个OPT pseudo RR。OPT被称为伪RR，因为它与特定的传输级别消息相关，而不与任何实际的DNS数据相关。OPT RRs不得缓存、转发、存储在主文件中或从主文件加载。每条消息的OPT伪RRs数量应为零或一，但不得大于零。
4.2. An OPT RR has a fixed part and a variable set of options expressed as {attribute, value} pairs. The fixed part holds some DNS meta data and also a small collection of new protocol elements which we expect to be so popular that it would be a waste of wire space to encode them as {attribute, value} pairs.
4.2. OPT RR有一个固定的部分和一组变量选项，这些选项表示为{attribute，value}对。固定部分包含一些DNS元数据和一小部分新协议元素，我们希望这些元素非常流行，因此将它们编码为{attribute，value}对将浪费布线空间。
4.3. The fixed part of an OPT RR is structured as follows:
4.3. OPT RR的固定部分结构如下：
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
Field Name Field Type Description
------------------------------------------------------
NAME domain name empty (root domain)
TYPE u_int16_t OPT
CLASS u_int16_t sender's UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
4.4. The variable part of an OPT RR is encoded in its RDATA and is structured as zero or more of the following:
4.4. 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 IANA.)
选项代码（由IANA指定）
OPTION-LENGTH Size (in octets) of OPTION-DATA.
OPTION-DATA的OPTION-LENGTH大小（以八位字节为单位）。
OPTION-DATA Varies per OPTION-CODE.
选项数据因选项代码而异。
4.5. The sender's UDP payload size (which OPT stores in the RR CLASS field) is the number of octets of the largest UDP payload that can be reassembled and delivered in the sender's network stack. Note that path MTU, with or without fragmentation, may be smaller than this.
4.5. 发送方的UDP有效负载大小（OPT存储在RR CLASS字段中）是可以在发送方的网络堆栈中重新组装和传递的最大UDP有效负载的八位字节数。请注意，路径MTU（带或不带碎片）可能小于此值。
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP reassembly buffer. Choosing 1280 on an Ethernet connected requestor would be reasonable. The consequence of choosing too large a value may be an ICMP message from an intermediate gateway, or even a silent drop of the response message.
4.5.1. 请注意，512八位UDP有效负载需要576八位IP重组缓冲区。在以太网连接的请求程序上选择1280是合理的。选择太大值的结果可能是来自中间网关的ICMP消息，甚至是响应消息的无声删除。
4.5.2. Both requestors and responders are advised to take account of the path's discovered MTU (if already known) when considering message sizes.
4.5.2. 建议请求者和响应者在考虑消息大小时考虑路径的已发现MTU（如果已知）。
4.5.3. The requestor's maximum payload size can change over time, and should therefore not be cached for use beyond the transaction in which it is advertised.
4.5.3. 请求者的最大有效负载大小可以随着时间的推移而改变，因此不应缓存以供在发布它的事务之外使用。
4.5.4. The responder's maximum payload size can change over time, but can be reasonably expected to remain constant between two sequential transactions; for example, a meaningless QUERY to discover a responder's maximum UDP payload size, followed immediately by an UPDATE which takes advantage of this size. (This is considered preferrable 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 payload size limit.)
4.5.4. 响应者的最大有效负载大小可以随时间变化，但可以合理预期在两个连续事务之间保持不变；例如，一个无意义的查询用于发现响应程序的最大UDP有效负载大小，然后立即进行利用此大小的更新。（如果有任何理由怀疑响应者实施了EDN，并且如果请求不符合默认的512有效负载大小限制，则认为这比直接使用TCP处理超大请求更可取。）
4.5.5. Due to transaction overhead, it is unwise to advertise an architectural limit as a maximum UDP payload size. Just because your stack can reassemble 64KB datagrams, don't assume that you want to spend more than about 4KB of state memory per ongoing transaction.
4.5.5. 由于事务开销，将架构限制作为最大UDP有效负载大小进行公告是不明智的。仅仅因为您的堆栈可以重新组装64KB的数据报，不要假设您希望在每个正在进行的事务中花费超过4KB的状态内存。
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) are structured as follows:
4.6. 扩展RCODE和标志（OPT存储在RR TTL字段中）的结构如下：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that EXTENDED-RCODE value "0" indicates that an unextended RCODE is in use (values "0" through "15").
扩展RCODE形成扩展12位RCODE的上8位。请注意，扩展RCODE值“0”表示未扩展的RCODE正在使用中（值“0”到“15”）。
VERSION Indicates the implementation level of whoever sets it. 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 minimize the responder and network load of discovering the greatest common implementation level between requestor and responder. A requestor's version numbering strategy should ideally be a run time configuration option.
VERSION表示设置它的人的实现级别。版本“0”表明完全符合本规范。鼓励请求者将其设置为能够表示事务的最低实现级别，以最小化响应者和发现请求者和响应者之间最大公共实现级别的网络负载。请求者的版本编号策略最好是运行时配置选项。
If a responder does not implement the VERSION level of the request, then it answers with RCODE=BADVERS. All responses will be limited in format to the
如果响应者没有实现请求的版本级别，那么它将使用RCODE=BADVERS进行响应。所有回复的格式仅限于
VERSION level of the request, but the VERSION of each response will 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, including RCODE=BADVERS.
请求的版本级别，但每个响应的版本将是响应程序的最高实现级别。通过这种方式，请求者将了解响应者的实现级别，作为每个响应的副作用，包括错误响应，包括RCODE=BADVERS。
Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification.
Z由发送方设置为零，接收方忽略，除非在后续规范中修改。
5 - Transport Considerations
5-运输考虑
5.1. 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.
5.1. 请求中存在OPT伪RR应被视为请求者完全实现给定版本的EDN，并且能够正确理解符合该特性规范的任何响应。
5.2. Lack of use of these features in a request must be taken as an indication that the requestor does not implement any part of this specification and that the responder may make no use of any protocol extension described here in its response.
5.2. 在请求中未使用这些功能必须视为表明请求者未实现本规范的任何部分，并且响应者可能未使用其响应中描述的任何协议扩展。
5.3. Responders who do not understand these protocol extensions are expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. Therefore use of extensions should be "probed" such that a responder who isn't known to support them be allowed a retry with no extensions if it responds with such an RCODE. If a responder's capability level is cached by a requestor, a new probe should be sent periodically to test for changes to responder capability.
5.3. 不了解这些协议扩展的响应者应发送带有RCODE NOTIMPL、FORMERR或SERVFAIL的响应。因此，应该“探测”扩展的使用，这样，如果不知道是否支持扩展的响应者使用这样的RCODE进行响应，则允许其在没有扩展的情况下重试。如果请求者缓存了响应者的能力级别，则应定期发送新的探测以测试响应者能力的更改。
6 - Security Considerations
6-安全考虑
Requestor-side specification of the maximum buffer size may open a new DNS denial of service attack if responders can be made to send messages which are too large for intermediate gateways to forward, thus leading to potential ICMP storms between gateways and responders.
如果响应者发送的消息太大，中间网关无法转发，从而导致网关和响应者之间潜在的ICMP风暴，则请求者端指定的最大缓冲区大小可能会引发新的DNS拒绝服务攻击。
7 - IANA Considerations
7-IANA考虑事项
The IANA has assigned RR type code 41 for OPT.
IANA为OPT分配了RR类型代码41。
It is the recommendation of this document and its working group that IANA create a registry for EDNS Extended Label Types, for EDNS Option Codes, and for EDNS Version Numbers.
本文件及其工作组建议IANA为EDNS扩展标签类型、EDNS选项代码和EDNS版本号创建一个注册表。
This document assigns label type 0b01xxxxxx as "EDNS Extended Label Type." We request that IANA record this assignment.
本文档将标签类型0b01xxxxxx指定为“EDNS扩展标签类型”。我们要求IANA记录此分配。
This document assigns extended label type 0bxx111111 as "Reserved for future extended label types." We request that IANA record this assignment.
本文档将扩展标签类型0bxx111111指定为“为将来的扩展标签类型保留”。我们要求IANA记录此分配。
This document assigns option code 65535 to "Reserved for future expansion."
本文件将选项代码65535指定为“保留供将来扩展”
This document expands the RCODE space from 4 bits to 12 bits. This will allow IANA to assign more than the 16 distinct RCODE values allowed in [RFC1035].
本文档将RCODE空间从4位扩展到12位。这将允许IANA分配超过[RFC1035]中允许的16个不同RCODE值。
This document assigns EDNS Extended RCODE "16" to "BADVERS".
本文件将EDNS扩展RCODE“16”分配给“BADVERS”。
IESG approval should be required to create new entries in the EDNS Extended Label Type or EDNS Version Number registries, while any published RFC (including Informational, Experimental, or BCP) should be grounds for allocation of an EDNS Option Code.
在EDNS扩展标签类型或EDNS版本号注册表中创建新条目需要IESG批准，而任何已发布的RFC（包括信息、实验或BCP）应作为分配EDNS选项代码的依据。
8 - Acknowledgements
8-致谢
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas Narten were each instrumental in creating and refining this specification.
Paul Mockapetris、Mark Andrews、Robert Elz、Don Lewis、Bob Halley、Donald Eastlake、Rob Austein、Matt Crawford、Randy Bush和Thomas Narten在创建和完善本规范方面都发挥了重要作用。
9 - References
9-参考文献
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
10 - Author's Address
10-作者地址
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
Paul Vixie互联网软件联合体950 Charter Street Redwood City，加利福尼亚州94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Phone: +1 650 779 7001
EMail: vixie@isc.org
11 - Full Copyright Statement
11-完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。