1. 简介 (Introduction)

如今, 几乎所有 DNS 查询 [RFC1034] [RFC1035] 都以未加密方式发送, 这使得能够访问网络信道的攻击者可以对其进行窃听, 从而降低查询方的隐私性.近期新闻报道加剧了这些担忧, IETF 最近的工作也已经为 DNS 指定了隐私注意事项 [RFC7626].

此前的工作已经处理了 DNS 安全的一些方面, 但直到最近, 关于 DNS 客户端与服务器之间隐私的工作仍然很少.DNS 安全扩展 (DNS Security Extensions, DNSSEC) [RFC4033] 通过定义对区域进行密码学签名的机制来提供响应完整性, 使最终用户 (或其第一跳解析器) 能够验证应答是否正确.按照设计目标, DNSSEC 不保护请求和响应的隐私.传统上, 人们要么不认为隐私是 DNS 流量的一项需求, 要么假定网络流量已经足够私密; 然而, 近期事件正在改变这些认知 [RFC7258].

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

本文档描述在知名端口上使用 DNS-over-TLS, 并给出性能方面的建议, 以尽量降低 DNS 使用 TCP 和 TLS 时产生的开销.

DNS-over-TLS 的发起过程非常直接.通过在知名端口上建立连接, 客户端和服务器预期并同意协商 TLS 会话来保护该信道.部署将是渐进式的.并非所有服务器都会支持 DNS-over-TLS, 且该知名端口可能被某些防火墙阻断.客户端需要跟踪哪些服务器支持 TLS, 哪些服务器不支持.客户端和服务器将遵循 [BCP195] 中的 TLS 实现建议和安全注意事项.

本文档描述的协议适用于存根客户端 (stub client) 与递归服务器之间的查询和响应.它也可能同样适用于递归客户端与权威服务器之间, 但根据 DNS PRIVate Exchange (DPRIVE) 工作组当前章程, 该协议的这一应用不在范围内.

本文档在第 4 节描述了两种配置文件 (profile), 它们提供不同级别的隐私保障: 机会式隐私配置文件 (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 会话的技术, 本质上是 "STARTTLS for DNS".为了简化协议, 本文档现在只使用知名端口来指定 TLS 的使用, 省略了升级方法.升级方法已不再出现在本文档中, 本文档现在专门聚焦于为 DNS-over-TLS 使用知名端口.

---