在DNS社区中，DoH一直存在争议，遭到著名人士的强烈反对。当DoT标准已经成为一种选择时，甚至对于IETF DoH标准的存在都提出了疑问。
Firefox内置了DoH支持
Firefox内置了DoH支持并配置了Cloudflare DNS，并将其设置默认为美国的所有用户的默认配置。这将有可能导致破坏组织或专用网络的本地网络策略。Firefox宣布了一个金丝雀域名，它可以在本地将其阻止，以防止Firefox默认使用DoH，从而使整个工作容易遭受降级攻击。人们对将 DoH作为DNS基础结构集中化的一种方式提出了严重的担忧。只有少数公共DoH和DoT服务提供商，因此它尝试集中化DNS基础结构。向少数DNS供应商发送所有您的DNS流量并不能真正改善您的整体隐私，每个用户需要自行决定这是一个折衷。DNS是网络中的一个重要控制平面
从本质上讲，它可使网络管理员可以根据域名来阻止内容，从而使其成为军械库中非常有用的工具。它被广泛用于提供内容过滤服务，父级控制以及阻止已知的恶意软件命令和控制。它是如此流行，以至于很多人在家庭网络上安装了本地运行的DNS服务器，以使用阻止列表来阻止Internet广告。默认情况下，使用DoH的应用程序或设备将绕过网络管理员配置的所有本地控制措施。应用程序使用DoH的理由是，它允许用户绕过审查，并提供安全性和隐私性。但是，未经用户同意，这可能不是用户期望的。
但是（but），使用DoT或DoH的用户真的受到保护吗？
首先让我们以技术术语了解默认的基于UDP / TCP的DNS（Do53），DoH和DoT协议。Do53是整个DNS基础结构使用的核心协议，默认情况下，所有DNS查询都使用UDP协议，因为它对于简单的请求/响应查询更为有效。
通常仅在预期响应足够大而不适用于UDP时才使用TCP，Do53不提供任何安全性或保密性，因为网络路径上的任何人都可以看到所有DNS请求，甚至操纵响应实际上是在进行中间人攻击。这已被许多危害路由器的恶意软件攻击所利用。并更改DNS设置以使用攻击者的DNS服务器进一步传播或进一步危害用户。当用户在Web浏览器中输入不存在的域名时，许多ISP也试图劫持DNS以显示广告。
DoT协议实际上只是在TLS内通过TCP传输的DNS-over-TCP 。因此，它提供了核心协议的所有功能以及路径安全性和私密性。DoT使用默认的TCP 853端口，因此很容易被任何网络防火墙阻止。
DoH使用HTTPS协议以有线格式发送和接收DNS数据
这意味着DoH服务器实际上是一个标准Web服务器，后端Web应用程序读取DNS请求并将其代理到已配置的DNS服务器。使用内置Web服务器的DNS服务器也可以直接支持DoH。与DoT一样，DoH也提供路径安全性和隐私性。由于DoH使用与HTTPS使用的相同的TCP 443端口，因此几乎不可能用网络防火墙阻止它，因为防火墙无法区分正常的HTTPS流量和DoH。由于DoT和DoH都使用TLS来确保安全性，因此它们在网络上本质上看起来相似。实际上，如果将DoT配置在端口443而不是其默认端口853上，那么使用网络防火墙进行阻止也将变得困难。因此，DoH的唯一好处似乎是，它允许使用标准Web服务器托管服务，在该服务器中，相同的IP地址和端口与多个其他HTTPS网站共享。
尽管DoT和DoH都声称提供安全性和隐私性，但还存在很多问题
DoT和DoH都仅提供从客户端到递归DNS服务器的安全性，因此它们不提供任何端到端的安全性，所以客户端实质上是信任配置的递归DNS服务器。即使对DNS请求进行了加密，由于TLS，您仍在泄漏所访问网站的域名服务器名称指示（SNI）扩展名。SNI本质上允许在单个IP地址上运行的Web服务器托管多个HTTPS网站。SNI扩展名包括您访问的网站的域名，以便Web服务器可以使用为该域名配置的正确SSL / TLS证书。因此，可以将SNI可靠地用作与基于DNS的过滤相结合的阻止网站的选项。
SNI扩展已升级到加密SNI（ESNI），它将加密TLS请求中的整个SNI扩展。但是实际上，即使ESNI在所有Web服务器和Web浏览器上普遍可用，也需要很多年的时间，大量的HTTPS网站为其域名配置ESNI。现在已有3年多的历史了，任何网站都可以使用免费的SSL / TLS证书，但是仍然有许多网站未部署HTTPS。
即使对DNS请求进行了加密并使用了TLS ESNI扩展名，大多数网站仍然可以通过其托管的IP地址来识别。因此，所有这些措施提供的隐私仍然不足。
DNSSEC呢？
DNSSEC旨在提供安全性，以便递归DNS服务器可以在响应客户端请求之前验证响应。它不提供端到端的安全性，因为客户端从不真正执行验证并且完全依赖于配置的递归DNS服务器。DNSSEC的另一个问题是，它没有被广泛部署，只有一小部分域名配置了它。互联网上最流行的网站仍然没有部署DNSSEC，这使得DNSSEC对于大多数最终用户而言并没有真正的用处。考虑到所有这些技术问题，很明显DoT和DoH都不真正安全地被人们用来绕过审查制度。任何对隐私有严重担忧的人最好使用Tor浏览器或使用体面的VPN服务。
-------------------------------------------------
DNS之父炮轰IETF正式采用DNS-over-HTTPS标准
设计DNS的架构师之一保罗•维克西（Paul Vixie）认为这简直就是一场灾难。网络管理员需要能够查看和分析DNS活动，DoH却阻止这么做。
需要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在去年首次讨论这项互联网草案时，该功能还没有出现在列表上。“大致上来说，通过扫描请求，服务器可以推断下一个请求会是什么，因而更快地发送给用户。”
----------------------
近期，互联网工程任务组（IETF）正式采用了 DNS-over-HTTPS 标准，并重新引发了关于它是否对网络基础设施构成威胁的争论。
前一阵子，IETF 提议将其提升为 8484 级别 RFC。这个想法是为了保证 DNS 查询的机密性和完整性，正如 Mozilla 的联合作者 Patrick
McManus 所说的那样，这源于政府和不怀好意的人干涉或窥探 DNS 请求。
加密保证了机密性，因为 RFC 8484 不是通过 UDP 发送纯文本 DNS 请求，而是通过 HTTPS 发送，并由 TLS
提供安全性保护。完整性保护源于服务器的公钥，从而保证没有人欺骗 DNS 服务器。
这听起来很不错，但是一些程序员和 IETF 的贡献者 Logan Velvindron 指出，并不是所有人都对 RFC 感到高兴。
DNS 的架构师 Paul Vixie 认为这不是一场灾难，“RFC 8484 是互联网安全集群。”他表示，DoH 与 DNS
的基本架构不兼容，因为它将控制平面（信令）消息移动到了数据平面（消息转发），这是禁忌。他在推特上辩称，网络管理员需要能够查看和分析 DNS 活动，DoH
可以防止这种情况发生。“DoH 是企业和其他专用网络的支路。但 DNS 是控制平面的一部分，网络运营商必须能够监控和过滤它。尽量使用 DoT，而不是
DoH。”
DoT 是基于 TLS 的 DNS，RFC 7858，是 DoH 的一个独立标准，致力于实现相同的完整性和隐私目标。
网络还是用户更重要？
虽然 DoT 实现了这些目标，但它仍然受到 DoH 拒绝的干扰：DoT 有自己的 853 端口，因此可以被阻止，用户的 DoT
请求（但不是该请求的内容或响应）可以从网络上看到。
另一方面，DoH 与其他 HTTPS 数据流共享 443 端口。
一位网络工程师在采访中称，DoH 删除了一个可用于区分 DNS 与其他流量的鉴别器，这对于任何想要干扰 DNS 流量的人来说都是一个问题。
“攻击者”不必阻止基于 TLS 的 DNS 主机，而必须阻止服务于 DoH 的整个主机——这可能意味着需要阻止 CDN、搜索引擎或者像 Cloudflare
这样的公司。
从这个角度来看，DoH 得到了一个强有力的支持：如果作为 DoT 发送加密的 DNS 请求，那么就可以被检测到，但是如果使用与 HTTPS
流量相同的端口则不会。
但是，有一些合法的安全应用程序可用于检查和干扰 DNS 操作，一个系统管理员保护企业网络免受域名攻击仅存在将恶意软件提供给受损端点。
争议四起
正如 Mozilla 的 Daniel Steinberg 所写的那样，无论采用哪种方法，争议存在的主要原因是 DNS
世界几十年来一直未能采取行动保护用户隐私。
“对我而言，DoH 部分是必要的，因为 'DNS 世界 ' 未能向大众提供安全和安全的名称查找，这就是应用程序 ' 一层一层 ' 仍可以保护用户的一种方式。”这与
DNS 隐私专家 Sara Dickinson （DoT 测试平台 Stubby 的作者）在 7 月份接受欧洲国家顶级域名注册机构委员会采访时所说的遥相呼应。
她说，这个行业通过缓慢的反应把 DoH 带回了自己。“浏览器只是直接进入，因为如果他们已经从 DNS 获得他们需要的东西，他们可能不太愿意沿着 DoH
路线走。但是，他们只是没有得到他们需要的东西，我认为他们有点觉得他们永远不会。“
DoT-versus-DoH 可能会被用户或提供商选择解决，因为两者都在部署，正如 DNS 隐私项目所记录的那样。
除了协议紧张之外，Velvindron 还通过电子邮件指出，通过扫描请求，服务器可以推断下一个请求将会是什么，并更快地将其提供给用户。
原文：https://www.theregister.co.uk/2018//10/23/paulvixieslapsdohasdnsprivacyfeaturebecomesastandard/