聚焦源代码安全，网罗国内外最新资讯！
编译：360代码卫士团队
互联网工程任务组 (IETF) 宣布正式采用 DNS-over-HTTPS (DoH) 标准。这一消息重新点燃关于 web 基础架构所面临的风险问题，简言之：DoH 还是 DoT (DNS-over-TLS)？这确实是个问题。
IETF 在上周晚些时候已经将 DoH 标准提升为“请求评议 (RFC)”级别 (RFC 8484)。DoH 标准旨在确保 DNS 查询的机密性和完整性，正如合著者 Mozilla 公司的 Patrick McManus 在2017年12月解释得那样，这么做是因为各国政府和恶意人员等人干扰或窥探 DNS 请求。
加密带来机密性，原因是 RFC 8484 不再将明文 DNS 请求经由 UDP 协议发送，而是通过受 TLS 保护的 HTTPS 协议发送。完整性保护通过使用服务器公钥来保证没有人能够欺骗 DNS 服务器。
虽然这些理念听起来很不错，但毛里求斯程序员兼 IETF 工作的贡献者 Logan Velvindron 表示，并未所有人都对 RFC 8484 满意。
DoT 还是 DoH？
DoT (RFC7858) 是不同于 DoH 的另外一套标准，目的也是为了实现完整性和隐私性。
DNS 之父 Paul Vixie 毫不掩饰自己的不满。他认为 DoH 标准简直是一场灾难。上周五，他更是在推特上发文怒斥：“RFC 8484 让互联网安全一团糟。不好意思给你们泼冷水了。真是一群疯子接管了疯人院。”
Vixie 表示，DoH 和 DNS 的基本架构并不兼容，因为它将控制平面（信令）信息转为数据平面（信息转发），而这是一大禁忌。他辩称，网络管理员需要能够看见并分析 DNS 活动，而 DoH 标准阻止这么做。DoH 过度绕过企业和其它私密网络。但 DNS 是控制平面的一部分，网络运营人员必须能够监控并过滤它。
他强调，要用 DoT，千万不要用 DoH。
网络第一还是用户第一？
尽管如此，但 DoT 标准仍然会遭受 DoH 所抵御的干扰：DoT 有自己独特的端口853，因此能够遭拦截，而且用户发出的 DoT 请求（而非请求内容或响应）在网络上是可见的。而 DoH 标准和其它 HTTPS 流量共享端口443。
一名为避免“惹火烧身”的网络工程师匿名表示，DoH 标准清除了可被用于区分 DNS 流量和其它流量的一个鉴别器，从而为想要干扰 DNS 请求的人群制造了困难。“攻击者”必须拦截整个提供 DoH 的主机（而非拦截对 DoT 实施拦截的主机），如拦截 CDN、搜索引擎或诸如 Cloudflare 这样的公司。
而这一点在保护人权方面优势突出：某激进人士如果以 DoT 标准发送请求，那么怀有敌意的政府就会检测到他/她在使用加密的 DNS，而如果使用同样的端口发送的是 HTTPS 流量，就不会检测到。
然而，同时存在有权监察并干扰 DNS 活动的合法安全应用。这些应用就像父母一样，通过 OpenDNS（现已被新东家更名为 Cisco Umbrella）来审查孩子查看的内容；或者像企业系统管理员一样，防御在受攻陷端点上释放恶意软件的域名。
罪魁祸首：DNS 保护隐私不力
其实，正如 Mozilla 公司的员工 Daniel Steinberg 在上周末所写的那样，DoT 和 DoH 之争的缘起是：几十年来，DNS 界未能保护用户隐私的安全。
他写道，“对于我而言，DoH 的存在有其必要性，因为‘DNS 界’未能为大众推出并部署安全的域名查询服务，而它是应用‘更进一层’保护用户的一种方式。”
这种说法和 DNS 隐私专家 Sara Dickinson （DoT 测试平台 Stubby 的作者）在7月份与欧洲国家顶级域名注册委员会 (CENTR) 访谈中的说法吻合。Dickinson 表示，DNS 的缓慢响应催生了 DoH，“浏览器就那么径直走了进来，因为如果它们已经从 DNS 那里获得想要的东西，就可能没有那么迫切地走 DoH 这条路径。然而，它们显然没有得到想要的，而且我有点觉得它们永远都不会得到。”
DoT 和 DoH 标准之争可能会由用户或提供商解决，因为从 DNS 隐私项目文档来看，这两种标准均已部署。
除了协议之争外，Velvindron 认为，最终的 RFC 将被整合至服务器推送功能（去年首次讨论草案时，并未提到该功能）中，“通过扫描请求，服务器能够推测到下一个请求是什么并更快地推给用户。”
推荐阅读
原文链接
https://www.theregister.co.uk/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy_feature_becomes_a_standard/
本文由360代码卫士编译，不代表360观点，转载请注明 “转自360代码卫士www.codesafe.cn”。