DNS 之父炮轰 IETF 正式采用 DNS-over-HTTPS 标准：“一群疯子接管了精神病院！”

需要DNS查询隐私的那些人能够提供架构方面的纯粹性吗？

互联网工程任务组（IETF）已正式采用了DNS-over-HTTPS（DoH）作为标准，因此重新引发了关于该标准是否对互联网基础设施构成威胁的争论。

上周晚些时候，IETF批准了这项提案，将该提案提升到意见征求稿（RFC，另译请求注释）级别，命名为RFC 8484。

正如提案的共同起草人、Mozilla的帕特里克•麦克马纳斯（Patrick McManus）在2017年12月向IT外媒The Register解释的那样，其想法是为了保证DNS查询的机密性和完整性，因为国家政府和不法分子都会干扰或窥视DNS请求。

加密提供了机密性，就因为RFC 8484通过HTTPS发送明文格式的DNS请求，由传输层安全（TLS）保驾护航，而不是通过UDP发送请求。完整性保护来自使用服务器的公钥，以保证没有人欺骗DNS服务器。

那些机制听起来像很好，但是毛里求斯的程序员、IETF工作的贡献者洛根•维尔文德龙（Logan Velvindron）却向The Register指出，不是每个人都对该RFC感到高兴。

设计DNS的架构师之一保罗•维克西（Paul Vixie）认为这简直就是一场灾难。周五，他发推文称：“就互联网安全而言，RFC 8484就是一团糟。不好意思，扫你们的兴了。一群疯子接管了精神病院。”

维克西表示，DoH与DNS的基本架构不相兼容，因为前者将控制平面（信令）消息转移到了数据平面（消息转发），而这是一大禁忌。

他在推文上声称，网络管理员需要能够查看和分析DNS活动，DoH却阻止这么做。 “DoH是企业网络及其他专用网络的过顶旁路（over the top bypass）。但DNS是控制平面的一部分，网络运营商必须能够监控和过滤它。使用DoT，千万不要使用DoH。”

DoT是DNS over TLS，即RFC 7858，这是一项有别于DoH的标准，致力于实现完整性和隐私方面的同样目标。

网络和用户，哪个更重要？

虽说DoT实现了上述目标，但它还是受制于DoH抵御得了的干扰：DoT有独享的端口853，因此可以被阻止，而用户的DoT请求（但不是该请求的内容或响应）从网络上是可以看到的。

另一方面，DoH与其他HTTPS流量共享端口443。

The Register采访了一位网络工程师，由于这场争论非常激烈，他不愿透露姓名。

他表示，DoH去除了一个可用于区分DNS与其他流量的鉴别符（discriminator），而这对于任何想要干扰DNS流量的人来说是个问题。

“攻击者”不是阻止通过TLS阻止DNS的主机，而是必须阻止服务DoH的整个主机――这可能意味着阻止CDN、搜索引擎或者像Cloudflare这样的公司。

从这个角度来看，DoH得到了一个强有力的人权论点的支持：如果激进分子以DNS的方式发送请求，怀有敌意的政府就能发觉激进分子在使用加密的DNS，但是如果他们使用与HTTPS流量同样的端口，就发觉不了。

然而，有一些合法的安全应用软件用于检查和干扰DNS操作――比如依赖OpenDNS（现在被东家改名为Cisco Umbrella）的父母来清除孩子看到的内容中的不良内容，或者系统管理员保护企业网络、远离完全为了向已中招的端点发送恶意软件而存在的域名。

自怨自艾

正如Mozilla的丹尼尔•斯坦伯格（Daniel Steinberg）在上周末所写的那样，无论哪种方法占上风，争议存在的主要原因是，几十年来DNS界一直未能采取行动来保护用户隐私。

“在我看来，DoH在一定程度上是必不可少的，因为‘DNS界’未能向大众发布和部署非常安全的查询，这是‘高一层’的应用程序仍可以保护我们用户的一种方式。”

这与DNS隐私专家萨拉•迪金森（Sara Dickinson，DoT测试平台Stubby的开发者）在7月份接受欧洲国家顶级域名注册机构委员会采访时的说法不谋而合。她当时说，正是由于业界迟迟没有反应，才会有今天的DoH。“浏览器径直进入，因为如果浏览器已经从DNS获得了它们所需的东西，可能不太迫切走DoH这条路子。然而，浏览器没有得到它们所需的东西；我认为浏览器有点觉得永远得不到所需的。”

正如DNS隐私项目所记述的那样，DoT与 DoH之争同样完全有可能由用户或提供商的选择来解决，因为两者都正在部署中。

除了协议方面的紧张局势外，维尔文德龙还通过电子邮件指出，最终的RFC集成了一项功能（服务器推送），The Register在去年首次讨论这项互联网草案时，该功能还没有出现在列表上。“大致上来说，通过扫描请求，服务器可以推断下一个请求会是什么，因而更快地发送给用户。”