Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 8094 Cisco
Category: Experimental D. Wing
ISSN: 2070-1721
P. Patil
Cisco
February 2017
Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 8094 Cisco
Category: Experimental D. Wing
ISSN: 2070-1721
P. Patil
Cisco
February 2017
DNS over Datagram Transport Layer Security (DTLS)
数据报传输层安全性（DTLS）上的DNS
Abstract
摘要
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.
DNS查询和响应对DNS客户端及其服务器之间路径上的网络元素可见。这些查询和响应可能包含隐私敏感信息，这对保护隐私很有价值。
This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.
本文档建议在DNS中使用数据报传输层安全性（DTLS），以防止被动侦听器和某些主动攻击。由于延迟对DNS至关重要，本提案还讨论了减少DTLS往返和减少DTLS握手大小的机制。建议的机制在端口853上运行。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第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/rfc8094.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8094.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 ....................................................3
1.1. Relationship to TCP Queries and to DNSSEC ..................3
1.2. Document Status ............................................4
2. Terminology .....................................................4
3. Establishing and Managing DNS over DTLS Sessions ................5
3.1. Session Initiation .........................................5
3.2. DTLS Handshake and Authentication ..........................5
3.3. Established Sessions .......................................6
4. Performance Considerations ......................................7
5. Path MTU (PMTU) Issues ..........................................7
6. Anycast .........................................................8
7. Usage ...........................................................9
8. IANA Considerations .............................................9
9. Security Considerations .........................................9
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informative References ...................................11
Acknowledgements ..................................................13
Authors' Addresses ................................................13
1. Introduction ....................................................3
1.1. Relationship to TCP Queries and to DNSSEC ..................3
1.2. Document Status ............................................4
2. Terminology .....................................................4
3. Establishing and Managing DNS over DTLS Sessions ................5
3.1. Session Initiation .........................................5
3.2. DTLS Handshake and Authentication ..........................5
3.3. Established Sessions .......................................6
4. Performance Considerations ......................................7
5. Path MTU (PMTU) Issues ..........................................7
6. Anycast .........................................................8
7. Usage ...........................................................9
8. IANA Considerations .............................................9
9. Security Considerations .........................................9
10. References ....................................................10
10.1. Normative References .....................................10
10.2. Informative References ...................................11
Acknowledgements ..................................................13
Authors' Addresses ................................................13
The Domain Name System is specified in [RFC1034] and [RFC1035]. DNS queries and responses are normally exchanged unencrypted; thus, they are vulnerable to eavesdropping. Such eavesdropping can result in an undesired entity learning domain that a host wishes to access, thus resulting in privacy leakage. The DNS privacy problem is further discussed in [RFC7626].
[RFC1034]和[RFC1035]中指定了域名系统。DNS查询和响应通常未加密地交换；因此，他们很容易被窃听。这种窃听可能导致主机希望访问的不希望的实体学习域，从而导致隐私泄漏。DNS隐私问题将在[RFC7626]中进一步讨论。
This document defines DNS over DTLS, which provides confidential DNS communication between stub resolvers and recursive resolvers, stub resolvers and forwarders, and forwarders and recursive resolvers. DNS over DTLS puts an additional computational load on servers. The largest gain for privacy is to protect the communication between the DNS client (the end user's machine) and its caching resolver. DNS over DTLS might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) working group per its current charter. This document does not change the format of DNS messages.
本文档定义了DTLS上的DNS，它提供了存根解析程序和递归解析程序、存根解析程序和转发器以及转发器和递归解析程序之间的机密DNS通信。DTLS上的DNS会给服务器带来额外的计算负载。隐私的最大好处是保护DNS客户端（最终用户的机器）与其缓存解析器之间的通信。DTL上的DNS可能在递归客户端和权威服务器之间同等工作，但根据DNS专用交换（DPRIVE）工作组的当前章程，该协议的应用超出其范围。此文档不会更改DNS消息的格式。
The motivations for proposing DNS over DTLS are that:
建议DNS优于DTL的动机是：
o TCP suffers from network head-of-line blocking, where the loss of a packet causes all other TCP segments not to be delivered to the application until the lost packet is retransmitted. DNS over DTLS, because it uses UDP, does not suffer from network head-of-line blocking.
o TCP遭受网络线头阻塞，其中一个数据包的丢失导致所有其他TCP段在丢失的数据包被重新传输之前不会被传递到应用程序。DTLS上的DNS，因为它使用UDP，不会受到网络线路头阻塞的影响。
o DTLS session resumption consumes one round trip, whereas TLS session resumption can start only after the TCP handshake is complete. However, with TCP Fast Open [RFC7413], the implementation can achieve the same RTT efficiency as DTLS.
o DTLS会话恢复需要一次往返，而TLS会话恢复只能在TCP握手完成后启动。然而，使用TCP Fast Open[RFC7413]，实现可以实现与DTL相同的RTT效率。
Note: DNS over DTLS is an experimental update to DNS, and the experiment will be concluded when the specification is evaluated through implementations and interoperability testing.
注意：DTLS上的DNS是对DNS的实验性更新，当通过实现和互操作性测试评估规范时，实验将结束。
DNS queries can be sent over UDP or TCP. The scope of this document, however, is only UDP. DNS over TCP can be protected with TLS, as described in [RFC7858]. DNS over DTLS alone cannot provide privacy for DNS messages in all circumstances, specifically when the DTLS record size is larger than the path MTU. In such situations, the DNS server will respond with a truncated response (see Section 5).
DNS查询可以通过UDP或TCP发送。但是，本文档的范围仅限于UDP。TCP上的DNS可以使用TLS进行保护，如[RFC7858]中所述。仅DTLS上的DNS无法在所有情况下为DNS消息提供隐私，特别是当DTLS记录大小大于路径MTU时。在这种情况下，DNS服务器将以截断的响应进行响应（参见第5节）。
Therefore, DNS clients and servers that implement DNS over DTLS MUST also implement DNS over TLS in order to provide privacy for clients that desire Strict Privacy as described in [DTLS].
因此，通过DTLS实现DNS的DNS客户端和服务器也必须通过TLS实现DNS，以便为需要严格隐私的客户端提供隐私，如[DTLS]中所述。
DNS Security Extensions (DNSSEC) [RFC4033] provide object integrity of DNS resource records, allowing end users (or their resolver) to verify the legitimacy of responses. However, DNSSEC does not provide privacy for DNS requests or responses. DNS over DTLS works in conjunction with DNSSEC, but DNS over DTLS does not replace the need or value of DNSSEC.
DNS安全扩展（DNSSEC）[RFC4033]提供DNS资源记录的对象完整性，允许最终用户（或其解析程序）验证响应的合法性。但是，DNSSEC不为DNS请求或响应提供隐私。DTLS上的DNS与DNSSEC一起工作，但DTLS上的DNS不能取代DNSSEC的需要或价值。
This document is an Experimental RFC. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.
本文档是一个实验性RFC。判断方法是否在大规模上可用的一个关键方面是通过观察协议在大规模实际部署中的使用、可用性和操作行为。
This DTLS solution was considered by the DPRIVE working group as an option to use in case the TLS-based approach specified in [RFC7858] turns out to have some issues when deployed. At the time of writing, it is expected that [RFC7858] is what will be deployed, and so this specification is mainly intended as a backup.
DPRIVE工作组将此DTLS解决方案视为在[RFC7858]中规定的基于TLS的方法在部署时出现一些问题时使用的选项。在撰写本文时，预计将部署[RFC7858]，因此本规范主要用作备份。
The following guidelines should be considered when performance benchmarking DNS over DTLS:
在通过DTL对DNS进行性能基准测试时，应考虑以下准则：
1. DNS over DTLS can recover from packet loss and reordering, and does not suffer from network head-of-line blocking. DNS over DTLS performance, in comparison with DNS over TLS, may be better in lossy networks.
1. DTLS上的DNS可以从数据包丢失和重新排序中恢复，并且不会受到网络线路头阻塞的影响。与DNS over TLS相比，DNS over DTLS在有损网络中的性能可能更好。
2. The number of round trips to send the first DNS query over DNS over DTLS is less than the number of round trips to send the first DNS query over TLS. Even if TCP Fast Open is used, it only works for subsequent TCP connections between the DNS client and server (Section 3 in [RFC7413]).
2. 通过DTLS通过DNS发送第一个DNS查询的往返次数小于通过TLS发送第一个DNS查询的往返次数。即使使用了TCP Fast Open，它也只适用于DNS客户端和服务器之间的后续TCP连接（RFC7413中的第3节）。
3. If the DTLS 1.3 protocol [DTLS13] is used for DNS over DTLS, it provides critical latency improvements for connection establishment over DTLS 1.2.
3. 如果DTLS 1.3协议[DTLS13]用于DTLS上的DNS，它将为DTLS 1.2上的连接建立提供关键的延迟改进。
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]中的说明进行解释。
By default, DNS over DTLS MUST run over standard UDP port 853 as defined in Section 8, unless the DNS server has mutual agreement with its clients to use a port other than 853 for DNS over DTLS. In order to use a port other than 853, both clients and servers would need a configuration option in their software.
默认情况下，DTLS上的DNS必须在第8节中定义的标准UDP端口853上运行，除非DNS服务器与其客户端达成协议，将853以外的端口用于DTLS上的DNS。为了使用853以外的端口，客户端和服务器都需要在其软件中配置选项。
The DNS client should determine if the DNS server supports DNS over DTLS by sending a DTLS ClientHello message to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over DTLS. Such another port MUST NOT be port 53 but MAY be from the "first-come, first-served" port range (User Ports [RFC6335], range 1024-49151). This recommendation against the use of port 53 for DNS over DTLS is to avoid complications in selecting use or non-use of DTLS and to reduce risk of downgrade attacks.
DNS客户端应通过向服务器上的端口853发送DTLS ClientHello消息来确定DNS服务器是否支持DTLS上的DNS，除非其与其服务器相互同意使用端口853以外的端口进行DTLS上的DNS。这样的另一个端口不能是端口53，但可以来自“先到先服务”端口范围（用户端口[RFC6335]，范围1024-49151）。针对DNS over DTLS使用端口53的建议是为了避免选择使用或不使用DTLS时的复杂性，并降低降级攻击的风险。
A DNS server that does not support DNS over DTLS will not respond to ClientHello messages sent by the client. If no response is received from that server, and the client has no better round-trip estimate, the client SHOULD retransmit the DTLS ClientHello according to Section 4.2.4.1 of [RFC6347]. After 15 seconds, it SHOULD cease attempts to retransmit its ClientHello. The client MAY repeat that procedure to discover if DNS over DTLS service becomes available from the DNS server, but such probing SHOULD NOT be done more frequently than every 24 hours and MUST NOT be done more frequently than every 15 minutes. This mechanism requires no additional signaling between the client and server.
不支持DTL上的DNS的DNS服务器将不会响应客户端发送的ClientHello消息。如果没有收到来自该服务器的响应，并且客户端没有更好的往返估计，则客户端应根据[RFC6347]第4.2.4.1节重新传输DTLS ClientHello。15秒后，它应该停止尝试重新传输ClientHello。客户端可以重复该过程，以发现DNS服务器是否提供了DNS over DTLS服务，但此类探测的频率不应超过每24小时一次，也不应超过每15分钟一次。这种机制在客户端和服务器之间不需要额外的信令。
DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages. DNS clients MUST NOT send and DNS servers MUST NOT respond to cleartext DNS messages on any port used for DNS over DTLS (including, for example, after a failed DTLS handshake). There are significant security issues in mixing protected and unprotected data; therefore, UDP connections on a port designated by a given server for DNS over DTLS are reserved purely for encrypted communications.
DNS客户端和服务器不得使用端口853传输明文DNS消息。DNS客户端不得发送，DNS服务器不得响应DTLS上用于DNS的任何端口上的明文DNS消息（包括，例如，在DTLS握手失败后）。在混合受保护和未受保护的数据时存在重大安全问题；因此，给定服务器为DTL上的DNS指定的端口上的UDP连接仅保留用于加密通信。
The DNS client initiates the DTLS handshake as described in [RFC6347], following the best practices specified in [RFC7525]. After DTLS negotiation completes, if the DTLS handshake succeeds according to [RFC6347], the connection will be encrypted and would then be protected from eavesdropping.
DNS客户端按照[RFC7525]中规定的最佳实践，按照[RFC6347]中的说明启动DTLS握手。DTLS协商完成后，如果DTLS握手根据[RFC6347]成功，则连接将被加密，然后将受到保护以防窃听。
DNS privacy requires encrypting the query (and response) from passive attacks. Such encryption typically provides integrity protection as a side effect, which means on-path attackers cannot simply inject bogus DNS responses. However, to provide stronger protection from active attackers pretending to be the server, the server itself needs to be authenticated. To authenticate the server providing DNS privacy, DNS client MUST use the authentication mechanisms discussed in [DTLS]. This document does not propose new ideas for authentication.
DNS隐私要求对被动攻击的查询（和响应）进行加密。这种加密通常会提供完整性保护作为副作用，这意味着路径上的攻击者不能简单地注入伪造的DNS响应。但是，为了提供更强大的保护，防止主动攻击者冒充服务器，需要对服务器本身进行身份验证。要对提供DNS隐私的服务器进行身份验证，DNS客户端必须使用[DTLS]中讨论的身份验证机制。本文件并未对认证提出新的想法。
In DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, DNS messages are encrypted using the standard DTLS record encoding. When a DTLS user wishes to send a DNS message, the data is delivered to the DTLS implementation as an ordinary application data write (e.g., SSL_write()). A single DTLS session can be used to send multiple DNS requests and receive multiple DNS responses.
在DTLS中，所有数据都使用相同的记录编码和机制进行保护。当本文档中描述的机制生效时，DNS消息将使用标准DTLS记录编码进行加密。当DTLS用户希望发送DNS消息时，数据作为普通应用程序数据写入（例如SSL_write（））传递到DTLS实现。单个DTLS会话可用于发送多个DNS请求和接收多个DNS响应。
To mitigate the risk of unintentional server overload, DNS over DTLS clients MUST take care to minimize the number of concurrent DTLS sessions made to any individual server. For any given client/server interaction, it is RECOMMENDED that there be no more than one DTLS session. Similarly, servers MAY impose limits on the number of concurrent DTLS sessions being handled for any particular client IP address or subnet. These limits SHOULD be much looser than the client guidelines above because the server does not know, for example, if a client IP address belongs to a single client, is representing multiple resolvers on a single machine, or is representing multiple clients behind a device performing Network Address Translation (NAT).
为了降低无意中服务器过载的风险，DTLS上的DNS客户端必须注意尽量减少对任何单个服务器进行的并发DTLS会话的数量。对于任何给定的客户机/服务器交互，建议不超过一个DTLS会话。类似地，服务器可能会对为任何特定客户端IP地址或子网处理的并发DTLS会话的数量施加限制。这些限制应该比上面的客户机指南宽松得多，因为服务器不知道客户机IP地址是否属于单个客户机，是否在一台机器上表示多个解析器，或者是否在执行网络地址转换（NAT）的设备后面表示多个客户机。
In between normal DNS traffic, while the communication to the DNS server is quiescent, the DNS client MAY want to probe the server using DTLS heartbeat [RFC6520] to ensure it has maintained cryptographic state. Such probes can also keep alive firewall or NAT bindings. This probing reduces the frequency of needing a new handshake when a DNS query needs to be resolved, improving the user experience at the cost of bandwidth and processing time.
在正常DNS通信之间，当与DNS服务器的通信处于静止状态时，DNS客户端可能希望使用DTLS心跳[RFC6520]探测服务器，以确保其保持加密状态。这样的探测还可以使防火墙或NAT绑定保持活动状态。这种探测减少了需要解析DNS查询时需要新握手的频率，以带宽和处理时间为代价改善了用户体验。
A DTLS session is terminated by the receipt of an authenticated message that closes the connection (e.g., a DTLS fatal alert). If the server has lost state, a DTLS handshake needs to be initiated with the server. For the server, to mitigate the risk of unintentional server overload, it is RECOMMENDED that the default DNS over DTLS server application-level idle time be set to several seconds and not set to less than a second, but no particular value is
DTLS会话通过接收关闭连接的经过身份验证的消息（例如，DTLS致命警报）而终止。如果服务器已失去状态，则需要与服务器启动DTLS握手。对于服务器，为了降低意外服务器过载的风险，建议将默认DNS over DTLS服务器应用程序级别的空闲时间设置为几秒，而不要设置为小于一秒，但不指定特定值
specified. When no DNS queries have been received from the client after idle timeout, the server MUST send a DTLS fatal alert and then destroy its DTLS state. The DTLS fatal alert packet indicates the server has destroyed its state, signaling to the client that if it wants to send a new DTLS message, it will need to re-establish cryptographic context with the server (via full DTLS handshake or DTLS session resumption). In practice, the idle period can vary dynamically, and servers MAY allow idle connections to remain open for longer periods as resources permit.
明确规定。当空闲超时后未收到来自客户端的DNS查询时，服务器必须发送DTLS致命警报，然后销毁其DTLS状态。DTLS致命警报数据包表示服务器已破坏其状态，向客户端发出信号，表示如果要发送新的DTLS消息，则需要与服务器重新建立加密上下文（通过完全DTLS握手或DTLS会话恢复）。实际上，空闲时间可以动态变化，服务器可能允许空闲连接在资源允许的情况下保持更长时间的开放。
The DTLS protocol profile for DNS over DTLS is discussed in Section 11 of [DTLS]. To reduce the number of octets of the DTLS handshake, especially the size of the certificate in the ServerHello (which can be several kilobytes), DNS clients and servers can use raw public keys [RFC7250] or Cached Information Extension [RFC7924]. Cached Information Extension avoids transmitting the server's certificate and certificate chain if the client has cached that information from a previous TLS handshake. TLS False Start [RFC7918] can reduce round trips by allowing the TLS second flight of messages (ChangeCipherSpec) to also contain the (encrypted) DNS query.
DTLS上DNS的DTLS协议配置文件在[DTLS]的第11节中讨论。为了减少DTLS握手的八位字节数，特别是ServerHello中证书的大小（可以是几千字节），DNS客户端和服务器可以使用原始公钥[RFC7250]或缓存信息扩展[RFC7924]。如果客户端缓存了以前TLS握手中的信息，则缓存信息扩展可避免传输服务器的证书和证书链。TLS False Start[RFC7918]允许TLS第二段消息（ChangeCipherSpec）也包含（加密的）DNS查询，从而减少往返。
It is highly advantageous to avoid server-side DTLS state and reduce the number of new DTLS sessions on the server that can be done with TLS Session Resumption without server state [RFC5077]. This also eliminates a round trip for subsequent DNS over DTLS queries, because with [RFC5077] the DTLS session does not need to be re-established.
避免服务器端DTLS状态并减少服务器上新DTLS会话的数量是非常有利的，可以通过TLS会话恢复而无需服务器状态[RFC5077]。这也消除了后续DNS over DTLS查询的往返，因为使用[RFC5077]无需重新建立DTLS会话。
Since responses within a DTLS session can arrive out of order, clients MUST match responses to outstanding queries on the same DTLS connection using the DNS Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability (Section 7 of [RFC7766]).
由于DTLS会话中的响应可能会无序到达，因此客户端必须使用DNS消息ID匹配同一DTLS连接上未完成查询的响应。如果响应包含问题部分，则客户端必须匹配QNAME、QCLASS和QTYPE字段。客户端未能正确匹配对未完成查询的响应可能会对互操作性造成严重后果（RFC7766第7节）。
Compared to normal DNS, DTLS adds at least 13 octets of header, plus cipher and authentication overhead to every query and every response. This reduces the size of the DNS payload that can be carried. The DNS client and server MUST support the Extension Mechanisms for DNS (EDNS0) option defined in [RFC6891] so that the DNS client can indicate to the DNS server the maximum DNS response size it can reassemble and deliver in the DNS client's network stack. If the DNS client does set the EDNS0 option defined in [RFC6891], then the maximum DNS response size of 512 bytes plus DTLS overhead will be
与普通DNS相比，DTLS为每个查询和每个响应添加了至少13个八位字节的头，加上密码和身份验证开销。这减少了可承载的DNS有效负载的大小。DNS客户端和服务器必须支持[RFC6891]中定义的DNS扩展机制（EDNS0）选项，以便DNS客户端可以向DNS服务器指示其可以在DNS客户端的网络堆栈中重新组装和交付的最大DNS响应大小。如果DNS客户端设置了[RFC6891]中定义的EDNS0选项，则最大DNS响应大小为512字节加上DTLS开销
well within the Path MTU. If the Path MTU is not known, an IP MTU of 1280 bytes SHOULD be assumed. The client sets its EDNS0 value as if DTLS is not being used. The DNS server MUST ensure that the DNS response size does not exceed the Path MTU, i.e., each DTLS record MUST fit within a single datagram, as required by [RFC6347]. The DNS server must consider the amount of record expansion expected by the DTLS processing when calculating the size of DNS response that fits within the path MTU. The Path MTU MUST be greater than or equal to the DNS response size + DTLS overhead of 13 octets + padding size ([RFC7830]) + authentication overhead of the negotiated DTLS cipher suite + block padding (Section 4.1.1.1 of [RFC6347]). If the DNS server's response were to exceed that calculated value, the server MUST send a response that does fit within that value and sets the TC (truncated) bit. Upon receiving a response with the TC bit set and wanting to receive the entire response, the client behavior is governed by the current Usage Profile [DTLS]. For Strict Privacy, the client MUST only send a new DNS request for the same resource record over an encrypted transport (e.g., DNS over TLS [RFC7858]). Clients using Opportunistic Privacy SHOULD try for the best case (an encrypted and authenticated transport) but MAY fall back to intermediate cases and eventually the worst case scenario (clear text) in order to obtain a response.
在MTU的路径内。如果路径MTU未知，则应假定IP MTU为1280字节。客户端将其EDNS0值设置为不使用DTLS。DNS服务器必须确保DNS响应大小不超过路径MTU，即按照[RFC6347]的要求，每个DTLS记录必须适合单个数据报。DNS服务器在计算适合于路径MTU的DNS响应的大小时，必须考虑DTLS处理所期望的记录扩展量。路径MTU必须大于或等于DNS响应大小+13个八位字节的DTLS开销+填充大小（[RFC7830]）+协商DTLS密码套件的身份验证开销+块填充（[RFC6347]第4.1.1节）。如果DNS服务器的响应超过该计算值，则服务器必须发送符合该值的响应，并设置TC（截断）位。在接收到设置了TC位的响应并希望接收整个响应时，客户端行为受当前使用配置文件[DTLS]的控制。为了严格保密，客户端必须仅通过加密传输（例如，TLS上的DNS[RFC7858]）发送相同资源记录的新DNS请求。使用机会主义隐私的客户端应尝试最佳情况（加密和认证的传输），但可能会退回到中间情况，最终是最坏情况（明文）以获得响应。
DNS servers are often configured with anycast addresses. While the network is stable, packets transmitted from a particular source to an anycast address will reach the same server that has the cryptographic context from the DNS over DTLS handshake. But, when the network configuration or routing changes, a DNS over DTLS packet can be received by a server that does not have the necessary cryptographic context. Clients using DNS over DTLS need to always be prepared to re-initiate the DTLS handshake, and in the worst case this could even happen immediately after re-initiating a new handshake. To encourage the client to initiate a new DTLS handshake, DNS servers SHOULD generate a DTLS fatal alert message in response to receiving a DTLS packet for which the server does not have any cryptographic context. Upon receipt of an unauthenticated DTLS fatal alert, the DTLS client validates the fatal alert is within the replay window (Section 4.1.2.6 of [RFC6347]). It is difficult for the DTLS client to validate that the DTLS fatal alert was generated by the DTLS server in response to a request or was generated by an on- or off-path attacker. Thus, upon receipt of an in-window DTLS fatal alert, the client SHOULD continue retransmitting the DTLS packet (in the event the fatal alert was spoofed), and at the same time it SHOULD initiate DTLS session resumption. When the DTLS client receives an authenticated DNS response from one of those DTLS sessions, the other DTLS session should be terminated.
DNS服务器通常配置有选播地址。当网络稳定时，从特定源传输到选播地址的数据包将到达具有通过DTLS握手的DNS加密上下文的同一服务器。但是，当网络配置或路由更改时，不具备必要加密上下文的服务器可以接收DTLS上的DNS数据包。通过DTLS使用DNS的客户端需要随时准备重新启动DTLS握手，在最坏的情况下，这甚至可能在重新启动新握手后立即发生。为了鼓励客户端启动新的DTLS握手，DNS服务器应生成DTLS致命警报消息，以响应接收到的DTLS数据包，该数据包的服务器没有任何加密上下文。收到未经验证的DTLS致命警报后，DTLS客户端将验证该致命警报是否在重播窗口内（RFC6347第4.1.2.6节）。DTLS客户端很难验证DTLS致命警报是由DTLS服务器响应请求生成的，还是由路径上或路径外攻击者生成的。因此，在收到窗口内DTLS致命警报后，客户端应继续重新传输DTLS数据包（如果致命警报被伪造），同时应启动DTLS会话恢复。当DTLS客户端从其中一个DTLS会话接收到经过身份验证的DNS响应时，应终止另一个DTLS会话。
Two Usage Profiles, Strict and Opportunistic, are explained in [DTLS]. The order of preference for DNS usage is as follows:
[DTLS]中解释了严格和机会主义两种使用模式。DNS使用的优先顺序如下：
1. Encrypted DNS messages with an authenticated server
1. 使用经过身份验证的服务器加密DNS消息
2. Encrypted DNS messages with an unauthenticated server
2. 使用未经身份验证的服务器加密DNS消息
3. Plaintext DNS messages
3. 明文DNS消息
This specification uses port 853 already allocated in the IANA port number registry as defined in Section 6 of [RFC7858].
本规范使用[RFC7858]第6节中定义的IANA端口号注册表中已分配的端口853。
The interaction between a DNS client and a DNS server requires Datagram Transport Layer Security (DTLS) with a ciphersuite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS. The DNS client SHOULD use the TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling" to check the revocation status of the public key certificate of the DNS server. OCSP stapling, unlike OCSP [RFC6960], does not suffer from scale and privacy issues. DNS clients keeping track of servers known to support DTLS enables clients to detect downgrade attacks. To interfere with DNS over DTLS, an on- or off-path attacker might send an ICMP message towards the DTLS client or DTLS server. As these ICMP messages cannot be authenticated, all ICMP errors should be treated as soft errors [RFC1122]. If the DNS query was sent over DTLS, then the corresponding DNS response MUST only be accepted if it is received over the same DTLS connection. This behavior mitigates all possible attacks described in Measures for Making DNS More Resilient against Forged Answers [RFC5452]. The security considerations in [RFC6347] and [DTLS] are to be taken into account.
DNS客户端和DNS服务器之间的交互需要数据报传输层安全性（DTLS）和提供机密性保护的密码套件。必须遵守[RFC7525]中给出的指南，以避免攻击DTL。DNS客户端应使用TLS证书状态请求扩展（RFC6066第8节），通常称为“OCSP绑定”，以检查DNS服务器公钥证书的吊销状态。与OCSP[RFC6960]不同，OCSP装订不存在规模和隐私问题。DNS客户端跟踪已知支持DTL的服务器，使客户端能够检测降级攻击。要通过DTLS干扰DNS，路径上或路径外攻击者可能会向DTLS客户端或DTLS服务器发送ICMP消息。由于无法对这些ICMP消息进行身份验证，所有ICMP错误都应视为软错误[RFC1122]。如果DNS查询是通过DTLS发送的，则只有通过相同的DTLS连接接收到相应的DNS响应时，才必须接受该响应。此行为缓解了“使DNS对伪造答案更具弹性的措施[RFC5452]中描述的所有可能攻击。应考虑[RFC6347]和[DTLS]中的安全注意事项。
A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv4 address sharing and with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such mitigation might involve rate limiting handshakes from a certain subnet or more advanced DoS/DDoS techniques beyond the scope of this document.
恶意客户端可能试图与服务器执行大量DTLS握手。由于客户端不是由协议唯一标识的，并且可能会与IPv4地址共享和IPv6临时地址混淆，因此服务器需要减轻此类攻击的影响。此类缓解措施可能涉及限制来自特定子网的握手速率，或本文档范围之外的更高级的DoS/DDoS技术。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[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>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://www.rfc-editor.org/info/rfc5077>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, <http://www.rfc-editor.org/info/rfc5452>.
[RFC5452]Hubert，A.和R.van Mook，“使DNS对伪造答案更具弹性的措施”，RFC 5452，DOI 10.17487/RFC5452，2009年1月<http://www.rfc-editor.org/info/rfc5452>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<http://www.rfc-editor.org/info/rfc6520>.
[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>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, DOI 10.17487/RFC7830, May 2016, <http://www.rfc-editor.org/info/rfc7830>.
[RFC7830]Mayrhofer，A.，“EDNS（0）填充选项”，RFC 7830，DOI 10.17487/RFC7830，2016年5月<http://www.rfc-editor.org/info/rfc7830>.
[DTLS] Dickinson, S., Gillmor, D., and T. Reddy, "Authentication and (D)TLS Profile for DNS-over-(D)TLS", Work in Progress, draft-ietf-dprive-dtls-and-tls-profiles-08, January 2017.
[DTLS]Dickinson，S.，Gillmor，D.，和T.Reddy，“通过-（D）TLS的DNS认证和（D）TLS配置文件”，正在进行的工作，草稿-ietf-dprive-DTLS-and-TLS-profiles-082017年1月。
[DTLS13] Rescorla, E. and H. Tschofenig, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, draft-rescorla-tls-dtls13-00, October 2016.
[DTLS13]Rescorla，E.和H.Tschofenig，“数据报传输层安全（DTLS）协议版本1.3”，正在进行的工作，草稿-Rescorla-tls-DTLS13-00，2016年10月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <http://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<http://www.rfc-editor.org/info/rfc6960>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<http://www.rfc-editor.org/info/rfc7250>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<http://www.rfc-editor.org/info/rfc7413>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <http://www.rfc-editor.org/info/rfc7626>.
[RFC7626]Bortzmeyer，S.，“DNS隐私注意事项”，RFC 7626，DOI 10.17487/RFC7626，2015年8月<http://www.rfc-editor.org/info/rfc7626>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <http://www.rfc-editor.org/info/rfc7766>.
[RFC7766]Dickinson，J.，Dickinson，S.，Bellis，R.，Mankin，A.，和D.Wessels，“TCP上的DNS传输-实施要求”，RFC 7766，DOI 10.17487/RFC7766，2016年3月<http://www.rfc-editor.org/info/rfc7766>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <http://www.rfc-editor.org/info/rfc7858>.
[RFC7858]Hu，Z.，Zhu，L.，Heidemann，J.，Mankin，A.，Wessels，D.，和P.Hoffman，“DNS传输层安全规范（TLS）”，RFC 7858，DOI 10.17487/RFC7858，2016年5月<http://www.rfc-editor.org/info/rfc7858>.
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <http://www.rfc-editor.org/info/rfc7918>.
[RFC7918]Langley，A.，Modadugu，N.，和B.Moeller，“传输层安全（TLS）错误启动”，RFC 7918，DOI 10.17487/RFC7918，2016年8月<http://www.rfc-editor.org/info/rfc7918>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <http://www.rfc-editor.org/info/rfc7924>.
[RFC7924]Santesson，S.和H.Tschofenig，“传输层安全（TLS）缓存信息扩展”，RFC 7924DOI 10.17487/RFC79242016年7月<http://www.rfc-editor.org/info/rfc7924>.
Acknowledgements
致谢
Thanks to Phil Hedrick for his review comments on TCP and to Josh Littlefield for pointing out DNS over DTLS load on busy servers (most notably root servers). The authors would like to thank Simon Josefsson, Daniel Kahn Gillmor, Bob Harold, Ilari Liusvaara, Sara Dickinson, Christian Huitema, Stephane Bortzmeyer, Alexander Mayrhofer, Allison Mankin, Jouni Korhonen, Stephen Farrell, Mirja Kuehlewind, Benoit Claise, and Geoff Huston for discussions and comments on the design of DNS over DTLS. The authors would like to give special thanks to Sara Dickinson for her help.
感谢Phil Hedrick对TCP的评论，感谢Josh Littlefield指出繁忙服务器（最显著的是根服务器）上的DNS超过DTL负载。作者要感谢Simon Josefsson、Daniel Kahn Gillmor、Bob Harold、Ilari Liusvaara、Sara Dickinson、Christian Huitema、Stephane Bortzmeyer、Alexander Mayrhofer、Allison Mankin、Jouni Korhonen、Stephen Farrell、Mirja Kuehlewind、Benoit Claise和Geoff Huston对DTLS上DNS设计的讨论和评论。作者要特别感谢Sara Dickinson的帮助。
Authors' Addresses
作者地址
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Dan Wing
丹荣
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com
Prashanth Patil Cisco Systems, Inc.
Prashanth Patil思科系统公司。
Email: praspati@cisco.com
Email: praspati@cisco.com