7. Design Evolution (设计演进)

本文档的早期草案版本提出了一种基于升级的方法来建立 TLS 会话. 客户端将通过在 DNS 扩展机制 (Extensions Mechanisms for DNS, EDNS(0)) 标志字段中设置 "TLS OK" 位来表示其对 TLS 的兴趣. 服务器将通过设置 TLS OK 位进行响应来表示其接受.

由于我们假设客户端不希望在保护通道之前泄露任何信息, 我们提议使用客户端可以为此目的发送的 "虚拟查询" (dummy query). 建议的查询名称是 STARTTLS, 查询类型是 TXT, 查询类是 CH.

TLS OK 信令方法既有优点也有缺点. 一个重要的优点是客户端和服务器可以协商 TLS. 如果服务器太忙, 或不想向特定客户端提供 TLS 服务, 它可以对 TLS 探测作出否定响应. 一个附带的好处是服务器可以在实现和部署之前收集有关 DNS over TLS 采用情况的信息 (通过查询中的 TLS OK 位). 另一个预期的优点是期望 DNS over TLS 将在端口 53 上工作. 也就是说, 不需要 "浪费" 另一个端口并在中间设备上部署新的防火墙规则.

然而, 与此同时, 鉴于 EDNS0 标志字段多年来没有变化, 存在不确定性, 即中间设备是否会传递 TLS OK 位. 另一个缺点是 TLS OK 位可能使降级攻击变得容易, 并且无法与损坏的中间设备区分开来. 从性能的角度来看, 基于升级的方法的缺点是虚拟查询需要额外的 1xRTT 延迟.

在此提议之后, 单独提出了 DNS over DTLS. DNS over DTLS 声称可以在端口 53 上工作, 但仅仅是因为非 DTLS 服务器将 DNS-over-DTLS 查询解释为响应. 也就是说, 非 DTLS 服务器观察到 QR 标志设置为 1. 虽然这在技术上是可行的, 但似乎是不幸的, 甚至可能是不可取的.

DNS over TLS 和 DNS over DTLS 都可以受益于单个众所周知的端口, 并避免额外的延迟和被误解为响应的查询.