权威名称服务器使用DNSSEC，以便递归服务器可以验证区域数据的完整性。然而，查询这些递归服务器的用户系统会执行完整性检查，旨在检测意外损坏而不是恶意。对于许多具有本地递归服务器的企业和家庭网络来说，这很好，但如果你在一个不受信任的网络上呢？如果您的ISP或政府拦截并更改DNS流量怎么办？如果您运行的本地网络是一个有价值的目标，并且希望在最后一步减少入侵者破坏DNS的机会，该怎么办？传统的解决方案是在客户端系统上运行一个验证解析器，但这为网络管理员提供了数十个解析器来进行故障排除，而不是几个中央解析器。许多人使用VPN，但这只会改变你信任的人。我们有两个新兴的安全传输客户端DNS的标准：基于TLS的DNS和基于HTTPS的DNS。
DNS over TLS，简称 DoT ，使用TCP端口853上的标准TLS。传统DNS可以以每种方式在单个数据包中管理简单查询，而DoT则需要多个数据包。然而，大多数用户不会注意到这种差异。
HTTPS over DNS，简称 DoH ，在端口443上使用TLS上的标准HTTP查询执行查询。名称服务器由URI标识，如 https://dns.google.com/dns-query 。对于外部观察者或网络管理员来说，DoH很难与常规HTTPS流量区分开来。用户可能会认为这是一个优势——毕竟，谁希望他们的ISP监视他们？不幸的是，这只会改变你信任的人。
DoH和DoT都从根本上改变了客户的行为。
传统上（Traditionally），操作系统管理DNS查找。像web浏览器这样的应用程序会要求操作系统查找DNS信息。操作系统查询递归服务器并向应用程序返回答案。通常，操作系统会维护一个答案缓存。
使用DoH和DoT，应用程序绕过操作系统，直接查询递归服务器。如果应用程序的DoH/DoT服务器无法访问或没有返回答案，它们可能会退回到操作系统的产品。操作系统的解析器将成为系统默认解析器，而应用程序可以有自己的首选解析器。
当应用程序使用与操作系统不同的名称服务器时，故障排除变得更加困难。虽然无法ping网站一直是一个可疑的诊断工具，但当应用程序执行自己的DNS查询时，它就更无关紧要了。这一变化让许多负责维护这些应用程序的系统管理员和网络操作员感到沮丧甚至愤怒。
在我写这篇文章的时候，操作系统可能支持也可能不支持直接的DoH或DoT查询，但我预计这将是一个越来越常见的功能。
DNS是使互联网正常工作所需的核心服务。公司在邮件和文件服务器旁边部署了自己的DNS服务器。然而，与许多其他核心服务一样，互联网公司意识到他们可以在经济上利用DNS查询数据。Cloudflare和谷歌等公司已经推出了公共DNS服务器，免费提供这项服务，以换取允许记录客户访问的每个网站并对这些数据进行商业利用。这将一项无聊但必要的服务变成了网络管理员和隐私倡导者的争论点。
问题归结为：谁可以访问你的数据，谁可以更改你的数据？
使用DoH和DoT，您的查询在传输过程中是私有的。但是，递归服务器运算符可以记录您的所有查询。反对威权政府的政治活动家必须决定，他们是希望自己的查询记录在政府运行的递归服务器上，还是由谷歌或Cloudflare记录。
同样，即使使用DNSSEC，递归服务器运营商也可以更改您得到的答案。如果递归服务器显示NXDOMAIN，客户端将获得NXDOMAIN。也许该响应没有签名，但客户端没有验证。谁会对你的询问进行最少的篡改？
如果你是一名负责组织安全和数据机密性的网络管理员，你绝对应该阻止DoH和DoT离开你的网络。强制客户端使用组织的递归名称服务器、代理服务器等。虽然DNS不是隧道协议，但技术一般的系统管理员可以通过DNS隧道SSH。一旦你有了SSH，你就拥有了一切。
信任问题是整个DNS的基础。完整性是DNSSEC背后的驱动力。你对信任的决定是你的责任。你最信任谁，或者，你最不信任谁？
自9.17起，BIND支持集成的DoH和DoT，该支持应向后移植到BIND 9.16中。它肯定会在BIND 9.18中。如果你还在使用旧版本的BIND，你会发现许多关于使用第三方软件提供前端代理的教程和食谱，这些代理允许客户端通过DoH和DoT访问你的域名服务器。我们将讨论BIND的本机支持，如9.17版本中提供的。虽然语法似乎已经稳定，但它仍然相对较新，因此可能会出现其他功能。
DoH和DoT都使用传输层安全性（Transport Layer Security —— TLS），因此需要X.509证书。应用程序必须识别签署证书的CA。如果你想使用自签名证书，你需要在应用程序或信任锚包中配置该证书，就像配置其他自签名证书一样。DNS是一种非交互式协议，不提供点击“忽略此警告并继续”的机会。
X.509证书有两个组件，一个证书文件和一个密钥文件。我已将文件 tls.cert 和 tls.key 放置在 namedb 目录中。在使用它们之前，我必须在 named.conf 中定义它们。
tls mysite { key-file "/etc/namedb/tls.key"; cert-file "/etc/namedb/tls.cert";};第一行定义了一个名为 mysite 的TLS证书。在稍后的配置中，我可以将这种文件组合称为“mysite”。我定义了密钥文件和证书文件的位置。如果您有中间证书，请使用完整链文件而不是证书文件。（所有应用程序必须始终提供所有X.509中间证书！）您可以将中间证书存储在单独的文件中，并为该文件提供 ca-file 选项，但链文件是最简单的。
如果密钥文件使用密码，则每次重新启动named时都必须提供密码。对于大多数组织来说，使用密码保护您的DoH或DoT带来的痛苦比它所能预防的要大。
TLS证书可以使用多种加密算法。最受欢迎的是RSA和ECDSA。我建议你选择一种你能用数据包嗅探器轻松解密的算法。应用程序为调试DoH和DoT提供了最少的支持。（代码比传统DNS复杂得多。）有时，查看问题所在的唯一方法是破解tcpdump或Wireshark。
在 named.conf 的选项部分使用 listen-on 或 listen-on-v6 语句配置DoT。在这里，我告诉named使用 mysite 中定义的证书，在主机上的任何IP地址的端口853上监听DNS over TLS。
xxxxxxxxxxlisten-on tls mysite { any ; } ;您可以添加一个 port 关键字来指定备用TCP端口，就像标准的 listen-on 语句一样。在这里，我们监听999端口上的DoT流量。
xxxxxxxxxxlisten-on 999 tls mysite { any ; } ;设置DoT侦听器并重新启动named后，使用dig的 +tls 选项对其进行测试。如果您在备用端口上运行DoT，请使用 -p 设置该端口。
xxxxxxxxxx$ dig mwl.io @ns3 +short +tls45.63.79.193DoT工作了。
与DoT非常相似，在 named.conf 的选项部分使用 listen-on 或 listen-on-v6 关键字配置HTTPS上的DNS。在这里，我告诉named使用 mysite 中定义的证书，在它可以连接到的任何地址的端口443上监听HTTPS上的域名。
xxxxxxxxxxlisten-on tls mysite http default { any ; } ;它看起来与DoT配置完全相同，添加了关键字 http default 。这些关键字定义了一个HTTP端点，即web服务器上的一个路径，在该路径上命名应接受DNS查询。默认端点（endpoint）是 /dns-query 。如果我的主机 ns3.mwl.io 提供了具有此配置的DoH查询，我将配置我的DoH客户端进行查询 https://ns3.mwl.io/dns-query 。您可以使用 http 关键字定义其他端点。
在将web浏览器指向新的DoH服务器之前，使用dig测试它。使用 +https 选项调用DoH。
xxxxxxxxxx$ dig mwl.io @dnssec-test +short +https如果被迫在同一台服务器上运行web服务器和DoH服务器，我可能会让BIND在备用端口上监听，并让web服务器代理查询它。在单个端口上复用应用程序会变得复杂，复杂情况会导致中断。将您的web服务器与DoH服务器分开。
现在让我们来看看作为信任链中的中间环节，甚至是信任锚。