突然之间，没有初步通知，基于TLS的DNS
开始在
8.8.8.8上工作。 此前，Google宣布仅支持基于
HTTPS的DNS。自项目启动以来，IP地址为
1.1.1.1的 CloudFlare的公共解析器
已支持基于TLS的DNS。
为什么有必要
使用经典的DNS方案，提供商可以将其肮脏的爪子抓到您的DNS数据包中，浏览您请求的域，并根据需要交换响应。 诈骗者会这样做，替换被入侵路由器上的解析器，以将用户引导到伪造的服务器。
使用TLS / HTTPS上的DNS，请求将在加密隧道内发送，因此提供程序无法替换或查看请求。
随着X.509证书（
ESNI ）中的域名加密的出现，将不可能通过SNI（服务器名称指示，这是一个特殊字段，在第一个TLS数据包中传输域名）通过DPI进行阻止，现已被一些大型提供商使用。
如何运作
与TCP：853建立TLS连接，并使用系统根证书验证解析程序证书，就像浏览器中的HTTPS一样。 这样就无需手动添加任何键。 在隧道内部，执行常规DNS查询。 与通过HTTPS的DNS（将HTTP标头添加到请求和响应）相比，这产生的开销要少。
不幸的是，系统解析器目前仅在Android 9（Pie）中支持基于TLS的DNS。
Android 9的安装说明 。
对于其他系统，建议使用第三方守护程序，然后将系统解析器发送到localhost（127.0.0.1）。
在macOS上安装
让我们以
结点解析器为例，分析最新版本的macOS上基于TLS的DNS
安装方式
brew install knot-resolver
默认情况下，结将像常规递归解析器（如dnsmasq）一样工作。
编辑配置
nano /usr/local/etc/kresd/config
并添加到文件末尾：
policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
结果，我的配置如下所示：
扩大扰流板 -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))
了解有关主机名和TLS证书身份验证的更多信息。在这种情况下，
hostname参数是证书的公用名（CN）或主题替代名（SAN）。 即，为其颁发证书的域名。 它验证服务器证书的真实性。
这是连接到8.8.8.8:853时使用的证书的SAN值
dns.google 8888.google 8.8.4.4 8.8.8.8 2001:4860:4860:0:0:0:0:64 2001:4860:4860:0:0:0:0:6464 2001:4860:4860:0:0:0:0:8844 2001:4860:4860:0:0:0:0:8888
这些值均可用作主机名参数。 如果要部署自己的公共递归解析器，则不太可能设法为IP地址颁发X.509证书，因此必须在hostname参数中指定域名。
守护程序启动
sudo brew services start knot-resolver
您可以使用以下命令检查守护程序是否成功启动：
sudo lsof -i -P -n | grep kresd
kresd进程应侦听localhost上的端口53。
如果出现问题，请查看错误日志：
cat /usr/local/var/log/kresd.log
检查解析器操作
dig @127.0.0.1 habr.com
检查本地解析器是否正确响应。
安装为系统解析器
如果一切正常，则可以在网络适配器的属性中分配系统解析器：
UPDDNSCrypt，DNSSEC，TLS / HTTPS上的DNS有什么区别？
DNSCrypt可以在UDP和TCP上运行。 与端口443的连接。为了进行加密，使用了它自己的协议，该协议不同于HTTPS。 使用DPI可以轻松突出显示它。 它只是草稿，在引入基于TLS / HTTPS的DNS之前已经过测试，因为它没有RFC，也就是说，它不是正式的Internet标准。 很快，它很可能会完全被后者取代。
TLS上的DNS（DoT） -TCP连接在端口853上进行，常规DNS请求在隧道内传输。 提供程序认为这是一个DNS查询，但不能对其进行干扰。 在其他条件相同的情况下，在TLS上的DNS中，每个请求的开销应比在HTTPS上略少一些。
DNS over HTTP（DoH） -与端口443的TCP连接，类似于常规HTTPS。 内部是带有HTTP标头的其他请求格式。 但是，对于提供者，这样的请求将被视为普通的HTTPS连接。 我想这个协议是在阻止对外部服务器的DNS查询以屏蔽正常Web流量的情况下发明的。 而且，浏览器可以自行解析域，而不会产生异常流量。
实际上，基于HTTPS和基于TLS的DNS是一回事，请求格式略有不同。 这两个协议均被接受为标准并具有RFC。 最有可能的是，在不久的将来，我们将看到它们两者的质量分布。
DNSSEC是用于数字签名DNS记录的协议。 它与加密无关，因为所有请求均以明文形式传输。 它既可以在旧的经典DNS协议（即端口53上的UDP / TCP）上运行，也可以在TLS / HTTPS上的DNS内部运行。 DNSSEC的目的是对DNS记录进行身份验证。 域所有者可以将公共密钥添加到其域区域的根服务器，并在NS服务器向导上签名所有条目。 实际上，向每个DNS记录（例如A记录或MX记录）添加了另一个包含签名的RRSIG类型的记录。 递归解析器上的DNSSEC验证过程使您可以确定此记录是否真正由域所有者创建。
所有协议
dnscrypt.info/faq的更详细比较（其他协议段）