7. 设计演进 (Design Evolution)

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

由于我们假定客户端不希望在信道受到保护之前透露 (泄露) 任何信息, 因此我们曾提议客户端可以为此发送一个 "dummy query".提议的查询名为 STARTTLS, 查询类型为 TXT, 查询类为 CH.

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

然而, 与此同时, 由于 EDNS0 标志字段多年来一直未发生变化, 中间盒是否会放行 TLS OK 比特仍存在不确定性.另一个缺点是, TLS OK 比特可能使降级攻击变得容易, 且无法与故障中间盒造成的问题区分开来.从性能角度看, 基于升级的方法还有一个缺点: dummy query 需要额外的 1xRTT 延迟.

在该提案之后, DNS over DTLS 被单独提出.DNS over DTLS 声称它可以在端口 53 上工作, 但这只是因为非 DTLS 服务器会把 DNS-over-DTLS 查询解释为响应.也就是说, 非 DTLS 服务器看到 QR 标志被设置为 1.虽然这在技术上可行, 但看起来并不理想, 甚至可能并不可取.

DNS over TLS 和 DNS over DTLS 都可以从单一知名端口中受益, 并避免额外延迟以及查询被误解为响应的问题.

---