1. Introduction (简介)

如今, 几乎所有的 DNS 查询 [RFC1034] [RFC1035] 都以未加密的方式发送, 这使得它们容易被能够访问网络通道的攻击者窃听, 从而降低了查询者的隐私. 最近的新闻报道已经加剧了这些担忧, 近期的 IETF 工作已经规定了 DNS 的隐私考虑 [RFC7626].

之前的工作已经解决了 DNS 安全的某些方面, 但直到最近, 关于 DNS 客户端和服务器之间的隐私保护方面的工作还很少. DNS 安全扩展 (DNS Security Extensions, DNSSEC) [RFC4033] 通过定义对区域进行加密签名的机制来提供响应完整性 (response integrity), 允许最终用户 (或他们的第一跳解析器) 验证响应是否正确. 按照设计, DNSSEC 不保护请求和响应的隐私. 传统上, 要么隐私不被视为 DNS 流量的必需要求, 要么假定网络流量已经具有足够的隐私性; 然而, 由于最近的事件 [RFC7258], 这些观念正在演变.

其他已经提供在 DNS 客户端和服务器之间加密潜力的工作包括 DNSCurve [DNSCurve]、DNSCrypt [DNSCRYPT-WEBSITE]、Confidential DNS [CONFIDENTIAL-DNS] 和 IPSECA [IPSECA]. 除了本规范之外, DPRIVE 工作组还采纳了一个关于 DNS over Datagram Transport Layer Security (DTLS) 的提案 [DNSoD].

本文档描述了在一个众所周知的端口 (well-known port) 上使用 DNS over TLS, 并提供了性能考虑建议, 以最小化在 DNS 中使用 TCP 和 TLS 的开销.

启动 DNS over TLS 非常简单. 通过在一个众所周知的端口上建立连接, 客户端和服务器期望并同意协商一个 TLS 会话来保护通道. 部署将是渐进的. 并非所有服务器都支持 DNS over TLS, 并且该众所周知的端口可能会被某些防火墙阻止. 客户端需要跟踪哪些服务器支持 TLS, 哪些不支持. 客户端和服务器将遵循 [BCP195] 的 TLS 实现建议和安全考虑.

本文描述的协议适用于存根客户端 (stub clients) 和递归服务器 (recursive servers) 之间的查询和响应. 它可能同样适用于递归客户端和权威服务器之间的通信, 但该协议的这一应用超出了 DNS PRIVate Exchange (DPRIVE) 工作组当前章程的范围.

本文档在第4节中描述了两种配置文件 (profiles), 它们提供不同级别的隐私保证: 机会性隐私配置文件 (opportunistic privacy profile) 和带外密钥固定隐私配置文件 (out-of-band key-pinned privacy profile). 预计基于 [TLS-DTLS-PROFILES] 的未来文档将进一步描述 DNS over TLS 和 DNS over DTLS 的额外隐私配置文件.

本文档的早期草案版本描述了一种将 DNS-over-TCP 连接升级为 DNS-over-TLS 会话的技术, 本质上是 "DNS 的 STARTTLS". 为了简化协议, 本文档现在仅使用众所周知的端口来指定 TLS 使用, 省略了升级方法. 升级方法不再出现在本文档中, 现在专门专注于使用众所周知的端口进行 DNS over TLS.