8. 安全注意事项 (Security Considerations)
使用 DNS-over-TLS 的设计目标是应对能够窃听 DNS 消息所带来的隐私风险.它不处理 DNS 中的其他安全问题, 并且仍有若干残余风险可能影响其保护隐私的效果:
-
TLS 存在已知攻击, 例如中间人攻击和协议降级攻击.这些是针对 TLS 的通用攻击, 并非 DNS-over-TLS 所特有; 有关这些安全问题的讨论, 请参阅 TLS RFC.客户端和服务器必须遵循 [BCP195] 中的 TLS 实现建议和安全注意事项.DNS 客户端跟踪已知支持 TLS 的服务器, 可以使客户端检测降级攻击.对于没有连接历史且没有明显 TLS 支持的服务器, 客户端可以根据其隐私配置文件和隐私需求选择 (a) 在可用时尝试另一台服务器, (b) 在没有 TLS 的情况下继续, 或 (c) 拒绝转发该查询.
-
某些网络中存在中间盒 (middlebox) [RFC3234], 且已知它们会干扰正常的 DNS 解析.为 DNS-over-TLS 使用指定端口应当可以避免此类干扰.一般而言, 尝试 TLS 但失败的客户端可以根据其隐私配置文件和隐私需求, 回退到未加密 DNS, 或等待并稍后重试.
-
任何以明文执行的 DNS 协议交互都可能被中间人攻击者修改.例如, 客户端和服务器之间可能通过端口 53 进行未加密的查询和响应.因此, 客户端可以丢弃关于以明文通告的服务器能力的缓存信息.
-
本文档本身并未指定用于抵抗已知流量分析或侧信道泄露的方案.即使消息已加密, 位置有利的一方仍可能通过分析消息时序和大小来获取某些细节.客户端和服务器可以考虑使用填充方法来处理因消息大小造成的隐私泄露 [RFC7830].由于流量分析可以基于多种模式和多种分类器, 仅靠简单填充方案可能不足以缓解此类攻击.然而, 填充将成为更复杂缓解措施的一部分, 而这些针对流量分析攻击的缓解措施很可能会随着时间推移而发展.能够在填充使用方式上提供灵活性的实现者, 可能更有利于在未来支持部署此类缓解措施.
如前所述, DNSSEC 和 DNS-over-TLS 是相互独立且完全兼容的协议, 各自解决不同的问题.使用其中一个并不会降低另一个的必要性或有用性.