8. Security Considerations (安全考虑)

使用 DNS over TLS 旨在解决窃听 DNS 消息能力所产生的隐私风险. 它不解决 DNS 中的其他安全问题, 并且存在许多可能影响其保护隐私成功的残余风险:

TLS 上存在已知攻击, 例如中间人攻击和协议降级攻击. 这些是对 TLS 的一般攻击, 而不是特定于 DNS over TLS 的攻击; 请参考 TLS RFC 以讨论这些安全问题. 客户端和服务器必须 (MUST) 遵守 [BCP195] 的 TLS 实现建议和安全考虑. 跟踪已知支持 TLS 的服务器的 DNS 客户端使客户端能够检测降级攻击. 对于没有连接历史且没有明显 TLS 支持的服务器, 根据其隐私配置文件和隐私要求, 客户端可以选择 (a) 在可用时尝试另一个服务器, (b) 继续而不使用 TLS, 或 (c) 拒绝转发查询.
中间设备 (Middleboxes) [RFC3234] 存在于某些网络中, 并且已知会干扰正常的 DNS 解析. 使用 DNS over TLS 的指定端口应避免此类干扰. 通常, 尝试 TLS 并失败的客户端可以回退到未加密的 DNS 或等待并稍后重试, 具体取决于其隐私配置文件和隐私要求.
在明文中执行的任何 DNS 协议交互都可以被中间人攻击者修改. 例如, 未加密的查询和响应可能在客户端和服务器之间通过端口 53 进行. 因此, 客户端可以 (MAY) 丢弃以明文方式发布的有关服务器功能的缓存信息.
本文档本身不指定抵抗已知流量分析或侧信道泄漏的思路. 即使使用加密消息, 一个位置良好的一方也可能能够从消息时序和大小的分析中收集某些细节. 客户端和服务器可以考虑使用填充方法来解决由于消息大小导致的隐私泄漏 [RFC7830]. 由于流量分析可以基于多种模式和多种分类器, 单纯的填充方案可能不足以缓解这种攻击. 然而, 填充将构成更复杂的流量分析攻击缓解措施的一部分, 这些缓解措施可能会随着时间的推移而发展. 在如何使用填充方面可以提供灵活性的实现者可能处于更好的位置, 以便在将来部署此类缓解措施.

如前所述, DNSSEC 和 DNS over TLS 是独立且完全兼容的协议, 每个协议解决不同的问题. 使用其中一个并不会削弱对另一个的需求或有用性.