Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 7830 nic.at GmbH
Category: Standards Track May 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Mayrhofer
Request for Comments: 7830 nic.at GmbH
Category: Standards Track May 2016
ISSN: 2070-1721
The EDNS(0) Padding Option
EDNS（0）填充选项
Abstract
摘要
This document specifies the EDNS(0) "Padding" option, which allows DNS clients and servers to pad request and response messages by a variable number of octets.
本文档指定了EDNS（0）“填充”选项，该选项允许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/rfc7830.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7830.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The "Padding" Option . . . . . . . . . . . . . . . . . . . . 3
4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. The "Padding" Option . . . . . . . . . . . . . . . . . . . . 3
4. Usage Considerations . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
The Domain Name System (DNS) [RFC1035] was specified to transport DNS messages in cleartext form. Since this can expose significant amounts of information about the Internet activities of an end user, the IETF has undertaken work to provide confidentiality to DNS transactions (see the DPRIVE working group). Encrypting the DNS transport is considered one of the options to improve the situation.
指定域名系统（DNS）[RFC1035]以明文形式传输DNS消息。由于这会暴露终端用户互联网活动的大量信息，IETF已着手为DNS交易保密（见DPRIVE工作组）。加密DNS传输被认为是改善这种情况的选项之一。
However, even if both DNS query and response messages were encrypted, metadata could still be used to correlate such messages with well-known unencrypted messages, hence jeopardizing some of the confidentiality gained by encryption. One such property is the message size.
然而，即使DNS查询和响应消息都经过加密，元数据仍然可以用于将此类消息与众所周知的未加密消息关联起来，从而危及通过加密获得的一些机密性。消息大小就是这样一个属性。
This document specifies the Extensions Mechanisms for DNS (EDNS(0)) "Padding" option, which allows DNS clients and servers to artificially increase the size of a DNS message by a variable number of bytes, hampering size-based correlation of the encrypted message.
本文档指定了DNS的扩展机制（EDNS（0））“填充”选项，该选项允许DNS客户端和服务器人为地将DNS消息的大小增加可变字节数，从而妨碍加密消息基于大小的关联。
The terms "Requestor" and "Responder" are to be interpreted as specified in [RFC6891].
术语“请求者”和“响应者”应按照[RFC6891]中的规定进行解释。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The EDNS(0) [RFC6891] specifies a mechanism to include new options in DNS packets, contained in the RDATA of the OPT meta-RR. This document specifies the "Padding" option in order to allow clients and servers to pad DNS packets by a variable number of bytes. The "Padding" option MUST occur at most, once per OPT meta-RR (and hence, at most once per message).
EDNS（0）[RFC6891]指定了在包含在OPT meta RR的RDATA中的DNS数据包中包含新选项的机制。本文档指定了“Padding”选项，以允许客户端和服务器按可变字节数填充DNS数据包。“Padding”选项必须最多出现一次，每个OPT meta RR出现一次（因此，每个消息最多出现一次）。
The figure below specifies the structure of the option in the RDATA of the OPT RR:
下图指定了OPT RR的RDATA中选项的结构：
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (PADDING) ... (PADDING) ... /
+- - - - - - - - - - - - - - - -
0 8 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| OPTION-LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| (PADDING) ... (PADDING) ... /
+- - - - - - - - - - - - - - - -
Figure 1
图1
The OPTION-CODE for the "Padding" option is 12.
“填充”选项的选项代码为12。
The OPTION-LENGTH for the "Padding" option is the size (in octets) of the PADDING. The minimum number of PADDING octets is 0.
“Padding”选项的OPTION-LENGTH是填充的大小（以八位字节为单位）。填充八位字节的最小数目为0。
The PADDING octets SHOULD be set to 0x00. Other values MAY be used, for example, in cases where there is a concern that the padded message could be subject to compression before encryption. PADDING octets of any value MUST be accepted in the messages received.
填充八位字节应设置为0x00。例如，在担心填充消息可能在加密之前受到压缩的情况下，可以使用其他值。接收的消息中必须接受任何值的填充八位字节。
This document does not specify the actual amount of padding to be used, since this depends on the situation in which the option is used. However, padded DNS messages MUST NOT exceed the number of octets specified in the Requestor's Payload Size field encoded in the RR Class Field (see Sections 6.2.3 and 6.2.4 of [RFC6891]).
本文档未指定要使用的实际填充量，因为这取决于使用选项的情况。但是，填充的DNS消息不得超过在RR类字段中编码的请求者有效负载大小字段中指定的八位字节数（参见[RFC6891]第6.2.3节和第6.2.4节）。
Responders MUST pad DNS responses when the respective DNS query included the "Padding" option, unless doing so would violate the maximum UDP payload size.
当相应的DNS查询包含“填充”选项时，响应者必须填充DNS响应，除非这样做会违反最大UDP负载大小。
Responders MAY pad DNS responses when the respective DNS query indicated EDNS(0) support of the Requestor and the "Padding" option was not included.
当相应的DNS查询指示请求者的EDNS（0）支持且未包括“填充”选项时，响应者可以填充DNS响应。
Responders MUST NOT pad DNS responses when the respective DNS query did not indicate EDNS(0) support.
当相应的DNS查询未指示EDN（0）支持时，响应者不得填充DNS响应。
IANA has assigned Option Code 12 for "Padding" in the "DNS EDNS0 Option Codes (OPT)" registry.
IANA已为“DNS EDNS0选项代码（OPT）”注册表中的“填充”分配了选项代码12。
IANA has updated the respective registration record by changing the Reference field to RFC 7830 and the Status field to "Standard".
IANA将参考字段更改为RFC 7830，将状态字段更改为“标准”，从而更新了相应的注册记录。
Padding DNS packets obviously increases their size, and will therefore lead to increased traffic.
填充DNS数据包显然会增加其大小，因此会导致流量增加。
The use of the EDNS(0) padding only provides a benefit when DNS packets are not transported in cleartext. Further, it is possible that EDNS(0) padding may make DNS amplification attacks easier. Therefore, implementations MUST NOT use this option if the DNS transport is not encrypted.
EDNS（0）填充的使用仅在DNS数据包未以明文传输时提供好处。此外，EDNS（0）填充可能使DNS放大攻击更容易。因此，如果DNS传输未加密，则实现不得使用此选项。
Padding length might be affected by lower-level compression. Therefore (as described in Section 3.3 of [RFC7525]), implementations and deployments SHOULD disable compression at the Transport Layer Security (TLS) level.
填充长度可能会受到较低级别压缩的影响。因此（如[RFC7525]第3.3节所述），实施和部署应在传输层安全性（TLS）级别禁用压缩。
The payload of the "Padding" option could (like many other fields in the DNS protocol) be used as a covert channel.
“Padding”选项的有效负载（与DNS协议中的许多其他字段一样）可以用作隐蔽通道。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <http://www.rfc-editor.org/info/rfc6891>.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS的扩展机制（EDNS（0）），STD 75，RFC 6891，DOI 10.17487/RFC68911913年4月<http://www.rfc-editor.org/info/rfc6891>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
Acknowledgements
致谢
This document was inspired by a discussion with Daniel Kahn Gillmor during IETF 93, as an alternative to the proposed padding on the TLS layer. Allison Mankin, Andreas Gustafsson, Christian Huitema, Jinmei Tatuya, and Shane Kerr suggested text for this document.
本文件的灵感来源于IETF 93期间与Daniel Kahn Gillmor的讨论，作为TLS层上拟议填充的替代方案。Allison Mankin、Andreas Gustafsson、Christian Huitema、Jinmei Tatuya和Shane Kerr建议本文件的文本。
Author's Address
作者地址
Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Vienna 1010 Austria
Alexander Mayrhofer nic.at GmbH卡尔斯普拉茨1/2/9奥地利维也纳1010
Email: alex.mayrhofer.ietf@gmail.com
Email: alex.mayrhofer.ietf@gmail.com