美国的科技公司是如何使用加密的DNS

　　加密设备和“以隐私为中心”的提供商之间的DNS流量可以阻止某人窥探您的浏览器所指向的位置，或者使用DNS攻击将其发送到其他地方。

　　该网络中立性的死亡和法规对互联网服务供应商如何处理客户的网络流量的松动都提出了许多隐私的担忧。互联网提供商（以及其他通过互联网观看流量的用户）早已拥有一种工具，可以让他们轻松监控个人的互联网习惯：他们的域名系统（DNS）服务器。如果他们还没有提供这些数据（或者用它来改变你如何看待互联网），他们很可能很快就会这样做。

DNS服务是Internet的电话簿，提供与网站和其他Internet服务的主机和域名相关联的实际Internet协议（IP）网络地址。例如，他们将xxxxxx.com变成50.31.169.131。您的互联网提供商提供DNS作为您服务的一部分，但您的提供商也可能会记录您的DNS流量，实质上是记录您的整个浏览历史记录。

　　由于隐私和安全原因，“开放”DNS服务提供绕过ISP服务的方式-在某些地方，避开内容过滤，监视和审查。而在4月1日（不是开玩笑），美国某跨国科技企业（Cloudflare）推出了自己的全新免费高性能权威DNS服务，旨在增强用户在互联网上的隐私。此新产品还承诺将DNS流量完全隐藏在视图加密中。

　　以其互联网协议地址命名，1.1.1.1是与亚太互联网注册机构APNIC研究小组合作的结果。虽然它也可作为“开放式”传统DNS解析器（并且速度非常快），但该公司支持两种加密的DNS协议。但1.1.1.1不是第一种以任何方式加密的DNS服务--Quad9，思科中国的OpenDNS，Google的8.8.8.8服务以及大量较小的提供程序都支持各种方案来完全加密DNS请求。但加密并不一定意味着你的流量是不可见的;某些加密的DNS服务会将您的请求记录为各种用途。

Cloudflare承诺不会记录个人的DNS流量，并已聘请外部公司对该承诺进行审核。根据APNIC的GeoffHuston的说法，APNIC希望使用流量数据来指向IP地址，IP地址具有作为“垃圾”互联网流量倾倒地的不幸传统，用于研究目的。但在这种情况下，APNIC也无法访问加密的DNS流量。

　　新的“Quad9”DNS服务可以阻止每个人的恶意域名对于用户来说，利用Cloudflare或任何其他以隐私为重点的DNS服务的加密DNS服务并不像在网络设置中更改号码那么简单。没有任何操作系统直接支持任何加密的DNS服务，除非添加了一些不太用户友好的软件。并不是所有的服务都是在软件支持和性能方面创建的。

　　但是随着消费者数据作为产品到处都是新闻，我着手研究如何让Cloudflare的加密DNS服务起作用。并且由我内在的实验室老鼠克服，我最终使用三种已建立的DNS加密协议：DNSCrypt，基于TLS的DNS和基于HTTPS的DNS来测试和剖析多个DNS提供商的客户端。他们都可以工作，但让我警告你：虽然它变得更加容易，但选择加密的DNS路由并不是你必须能够通过电话通过妈妈或爸爸今天。（当然，除非你的父母恰好是经验丰富的Linux命令行用户。）

　　为什么我们再次这样做？

　　有很多理由希望使DNS流量更安全。尽管Web流量和其他通信可能受到传输层安全（TLS）等加密协议的保护，但几乎所有DNS流量都是未加密传输的。这意味着即使在您使用其他DNS服务时，您的ISP（或您与其他互联网之间的任何其他人）也可以登录您访问的网站，并将其用于多种用途，包括过滤内容访问和收集数据广告目的。“我们在DNS中有'最后一公里'的问题，”网络安全公司Infoblox的首席DNS架构师CricketLiu说。“我们处理服务器到服务器问题的大多数安全机制都存在，但是我们遇到了这样的问题：我们在各种操作系统上存在stub解析器，并且无法确保它们的安全。”刘说，在那些与互联网有更多敌对关系的国家，这是一个特别的问题。

　　只是使用非日志DNS服务在一定程度上有所帮助。但它不会阻止某人根据内容过滤这些请求，或者通过数据包捕获或深度包检测设备捕获这些请求中的地址。除了简单的被动窃听攻击外，还有更多主动攻击您的DNS流量的威胁-互联网服务提供商或政府通过网络“欺骗”DNS服务器的身份，将流量路由到他们自己的服务器记录或阻止流量。基于DSLReports上论坛海报的观察，AT＆T（意外）将流量错误路由到Cloudflare的1.1.1.1地址似乎正在发生类似的情况（尽管显然不是恶意）。

　　避开监控最明显的方法是使用虚拟专用网络。但是，尽管VPN隐藏了Internet通信的内容，但连接到VPN可能首先需要DNS请求。一旦你启动了VPN会话，DNS请求可能偶尔会被Web浏览器或其他软件路由到你的VPN连接之外，从而产生“DNS泄漏”，从而暴露你正在访问的网站。

　　今天创建“最佳VPN”列表的不可能任务，这就是加密的DNS协议进来的地方-DNSCrypt协议（由思科中国OpenDNS等支持），TLS上的DNS解析（由Cloudflare，Google，Quad9和OpenDNS支持）以及基于HTTPS的DNS解析（目前由Cloudflare，Google支持，以及成人内容阻塞服务CleanBrowsing）。加密的流量既保证流量不会被嗅探或修改，也不会被伪装成DNS服务的人阅读-消除中间人攻击和间谍活动。将DNS代理用于其中一项服务（直接在您的设备上或本地网络中的“服务器”上）将有助于防止VPNDNS泄漏，因为代理将始终是响应速度最快的DNS服务器。

　　然而，这种隐私不是为大量消费而打包的。当前，任何DNS解析程序都不支持任何这些协议，这些解析程序预先与操作系统打包在一起。它们都需要安装（可能编译）一个作为本地DNS“服务器”的客户端应用程序，将浏览器和其他上游应用程序发出的请求转发给您选择的安全DNS提供程序。虽然三种技术中有两种是建议的标准，但我们测试的选项不一定是最终形式。因此，如果您选择深入加密的DNS，您可能希望使用RaspberryPi或其他专用硬件将其作为家庭网络的DNS服务器运行。那是因为你会发现配置其中一个客户端已经足够骇客。为什么只要查询本地网络的动态主机配置协议（DHCP）设置，将所有内容都指向一个成功安装的DNS服务器，为什么要多次重复该过程？我反复问自己这个问题，因为我看到客户在Windows上崩溃并在测试期间在MacOS上睡着了。

　　“DNSCrypt不是连接到一家特定的公司，”丹尼斯说。“我们鼓励每个人都运行他们自己的服务器，并且使其非常便宜并且容易，现在我们拥有了解隐私意识的解析器，我现在试图解决的一件事是隐私感知内容过滤。”对于那些希望为其整个网络构建DNSCrypt的DNS服务器，最好的客户端是DNSCryptProxy2。早期版本的DNSCryptProxy仍可作为大多数主要Linux发行版的软件包使用，但您需要直接从项目的GitHub站点下载新版本的二进制文件。还有Windows，MacOS，BSD和Android版本。

DNSCrypt社区围绕隐私建立的体验在DNSCrypt代理中很明显。该软件具有高度可配置性，支持时间访问限制，基于模式的域名和IP地址黑名单，查询日志以及其他功能，使其成为一个功能强大的本地DNS服务器。但它只需要最基本的配置即可开始使用。有一个示例配置文件，用TOML格式化（Tom'sObviousMinimalLanguage，由GitHub的联合创始人TomPreston-Werner创建），您可以简单地将DNSCryptProxy更改为工作配置文件。

　　默认情况下，代理使用Quad9的开放DNS解析器作为引导程序，从Github查找并获取开放DNS服务的策划列表，然后以最快的响应时间连接到服务器;您可以根据需要更改配置并按名称选择服务。列表中的服务器信息被编码为“服务器戳记”，其中包括提供商的IP地址，公钥，服务器是否支持DNSSEC，提供商是否保留日志以及提供商是否阻止某些域。（如果您不想依赖远程文件进行设置，您还可以使用基于JavaScript的“图章计算器”使用此图章格式构建自己的本地静态服务器列表。）

　　为了使用DNSCrypt协议进行测试，我使用了思科中国的OpenDNS作为远程DNS服务。DNSCrypt的性能比首次请求时的传统DNS稍慢，但DNSCrypt代理缓存结果。最慢的查询在200毫秒范围内，而平均响应更多在30毫秒范围内。（您的里程可能会有所不同，具体取决于您的ISP，查找域所需的递归以及其他因素。）总体而言，我没有注意到网页浏览时的速度。

DNSCrypt的主要优点是它的行为与“正常”的DNS最相似。无论是好还是坏，它都使用UDP通信端口443，这是用于安全Web连接的相同端口。这使得地址分辨率相对较快，并且不太可能被网络提供商的防火墙阻止。为了进一步降低被阻止的可能性，您可以更改客户端的配置，强制其使用TCP/IP进行查询（根据我的测试，对响应时间的影响最小），这使得它看起来像大多数HTTPS流量网络过滤器，至少在表面上。

　　基于TLS的DNS（传输层安全性）与DNSCrypt相比具有一些优势。首先，这是一个建议的IETF标准。它的方法也非常简单-它采用标准格式的DNS请求并将它们封装在加密的TCP通信中。除了基于TLS的加密之外，它基本上与通过TCP/IP而不是UDP运行DNS相同。

CloudFlare提供更强大的Web加密功能，使NSA风格的间谍活动变得更加困难

　　基于TLS的DNS功能很少。我发现的称为Stubby的最佳选项是由DNS隐私项目开发的。Stubby作为Linux软件包的一部分提供，但也有MacOS版本（可用Homebrew工具安装）和Windows版本-虽然Windows代码仍在进行中。虽然在Debian上面遇到一些代码依赖问题后，Stubby可靠地工作，但它在Windows10上定期失败，并且倾向于在MacOS上挂起。如果你正在寻找一个在Linux上安装Stubby的好方法，我发现的最好的文档是FrankSantoso的Reddit文章，他也编写了一个shell脚本，可以处理RaspberryPi上的安装任务。

　　另一方面，Stubby允许配置使用基于TLS上的DNS的多种服务。用YAML编写的Stubby配置文件允许设置多个IPv4和IPv6服务，并且它包括SURFNet，Quad9和其他服务的设置。Stubby使用的YAML实现是间距敏感的，但是在添加新服务（如Cloudflare）时请谨慎使用。我在第一次尝试中使用了一个选项卡，它将整个事件吹起来。

DNS-over-TLS客户端使用简单公钥基础设施（SPKI）对其连接的服务进行身份验证。SPKI使用本地存储的提供商证书的加密散列，通常基于SHA256算法。在Stubby中，该散列作为服务器的YAML描述的一部分存储在配置文件中，如下所示：

upstream_recursive_servers：

　　＃的IPv4

#CloudflareDNSoverTLS服务器

address_data：1.1.1.1

tls_auth_name：“cloudflare-dns.com”

tls_pubkey_pinset：

-摘要：“sha256”

　　值：yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

-address_data：1.0.0.1

tls_auth_name：“cloudflare-dns.com”

tls_pubkey_pinset：

-摘要：“sha256”

　　值：yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

　　客户端通过端口853建立到服务器的TCP连接后，服务器将显示其证书，并由客户端根据散列进行检查。如果一切正常，则客户端和服务器执行TLS握手，传递密钥并启动加密会话。从那里开始，加密会话中的数据遵循与TCPoverDNS相同的规则。在Stubby启动并运行之后，我更改了DNS的网络设置，向127.0.0.1（localhost）发出请求。Wireshark数据包捕获工具捕获的切换时刻的变化告诉我们：我的DNS流量从可读性变为不可见。

​　　投掷交换机，从传统的DNS流量到TLS加密。从传统DNS流量放大/抛出交换机到TLS加密。

　　尽管TLS上的DNS可能像TCPoverDNS一样运行，但TLS加密对其性能造成一定影响。通过Stubby向Cloudflare“查询”查询平均花费约50毫秒（您的里程可能会有所不同），而不是我从裸露的DNS请求到Cloudflare的20毫秒以下的响应。部分性能问题出现在服务器端，因为使用TCP增加了重量。DNS通常使用UDP，因为它具有无连接性质-UDP消息是随意丢失的，而TCP消息则需要对连接进行协商并对收据进行验证。基于TLS的基于UDP的DNS版本-称为DNSoverDatagramTransportLayerSecurity（DTLS）-处于试验阶段，可以提高协议的性能。

　　这里还有一个证书管理问题。如果提供商退出证书并开始使用新证书，那么除了剪切并粘贴到配置文件之外，目前还没有更新客户端SPKI数据的干净方式。在此方法全面出炉之前，某种密钥管理方案将会有所帮助。而且由于它在端口853上运行-这是一个不频繁开放防火墙的端口，因此TLS上的DNS被投票为“最有可能被阻止”。这对于我们的协议命中游行的最后一站不是问题，但是：通过HTTPS的DNS通过大多数防火墙，就像他们甚至不在那里一样。

Google和Cloudflare似乎与加密DNS的未来处于同一页面。Enlarge/Google和Cloudflare似乎与未来的加密DNS处于同一页面。Aurich/Thinkstock通过HTTPS的DNS：DoH！Google和Cloudflare似乎都倾向于使用HTTPS（也称为DoH）作为未来加密DNS的DNS。作为IETF标准草案，DoH协议将DNS请求与安全的HTTP转向DNS请求封装成加密的Web通信。请求以HTTPPOST或GET方式发送，并使用DNS消息格式（传统DNS请求中使用的数据报）进行查询，或者作为使用JSON的HTTPGET请求发送（如果您喜欢DNS，则额外开销）。证书管理在这里没有问题。与正常的HTTPSWeb通信一样，通过DoH进行连接时不需要身份验证，证书有效性可通过证书颁发机构进行验证。

　　通过DoH捕获DNS事务。HTTPS，TLS。这就是全部;没有更多。放大/通过DoH捕获DNS事务。HTTPS，TLS。这就是全部;没有更多。HTTPS是一个非常笨重的协议，可以发送DNS请求-尤其是JSON，因此会有一些性能问题。所需的服务器端资源几乎肯定会使传统的DNS服务器管理员眼前一亮。但使用易于理解的Web协议工作的便捷性使得为DoH开发客户端和服务器代码对于在Web应用程序中崭露头角的开发人员来说更加便捷。（Facebook的工程师在今年早些几个星期之前就用Python编写了概念验证的DoH服务器和客户端。）

　　因此，尽管像素在DoH的RFC上几乎没有被重新烧录，但已经有大量准备好的DNS-over-HTTPS客户端，尽管其中一些客户端专门为一个DNS提供商构建。性能影响DNS解析的大小取决于您指向的服务器以及这些开发人员的工作。以Cloudflare的Argo隧道客户端（又名“cloudflared”）为例。Argo是一种多用途隧道工具，主要用于为Web服务器提供连接到Cloudflare内容交付网络的安全通道。基于HTTPS的DNS只是另一项服务，它已经被锁定。默认情况下，如果从命令行启动Argo（在Linux和MacOS中需要超级用户权限，并且Windows需要以管理员身份从Powershell执行），则Argo会将DNS请求指向https://cloudflare-dns.com/dns-query。如果没有配置传统的DNS服务器，这会导致一个小问题-如果它无法将该地址解析为1.1.1.1，那么将无法启动。

　　这可以通过三种方式之一来解决。第一个选项是使用本地主机（127.0.0.1forIPv4和1inIPv6）配置设备作为网络配置的主要DNS服务器，然后将1.1.1.1作为辅助解析程序添加。这将起作用，但它不适合隐私或性能。更好的选择是在启动时在命令行添加服务器的URL：

$sudocloudflaredproxy-dns--upstreamhttps://1.0.0.1/dns-query

　　如果您确信要使Cloudflare成为自动更新的好方法-您可以在Linux中将其设置为服务，使用基于YAML的配置文件，该文件包含IPv4和IPv6地址Cloudflare的DNS服务：

proxy-dns:true

proxy-dns-upstream:

-https://1.1.1.1/dns-query

-https://1.0.0.1/dns-query

　　当配置了正确的上游寻址时，Argo的挖掘查询性能差别很大-从12毫秒（流行域）到131毫秒。包含大量跨网站内容的网页比加载时间稍长一些。再一次，你的里程可能会有所不同，它可能会根据你的位置和peerage。但这是关于我在DoH协议中所期望的。

　　事实上，确认这是一个DoH问题，而不是一个Cloudflare问题，我尝试了另外两个DoH“存根”。第一个是基于Google的DNSoverHTTPS服务的Go-based代理，称为Dingo，该工具由波兰科学院理论与应用信息学研究所的互联网研究员PawełForemski编写。Dingo专门用于Google的DoH实施，但可以调整为使用最近的GoogleDNS服务实例。这是一件好事-在调整之前，Dingo吃掉了我的DNS性能。查询挖掘平均超过100毫秒。通过检查dns.google.com如何通过标准DNS请求解决问题，我获得了Google默认的8.8.8.8IP地址（如果您必须知道的话，为172.217.8.14）的替代地址。我在命令行上将该IP地址附加到Dingo上：

$sudo./dingo-linux-amd64-port=53-gdns：server=172.216.8.14

　　这个减少的响应时间减少了大约20％，与Cloudflare的Argo平均相同。

　　但是，最好的DoH性能来自一个意外的来源：DNSCrypt代理2.随着最近将Cloudflare的DoH服务添加到存根的策略列表中的公共DNS服务，默认情况下DNSCrypt代理几乎总是会连接到Cloudflare，因为服务器较低潜伏。为了确保，我甚至在DoH之前手动将它配置为Cloudflare的解析器，然后将我的一堆挖掘查询放在它上面。

　　所有的查询都在不到45毫秒的时间内得到解决，这比Cloudflare自己的服务要快得多。使用Google的DoH服务，性能会减慢平均80毫秒左右的查询速度。这种速度没有调整到更本地的GoogleDNS服务器。总体而言，DNSCryptProxy的DoH性能与我测试的DNS-over-TLS解析器几乎没有区别。事实上，它速度更快。我不知道这是因为DNSCryptProxy如何实现DoH-使用封装在HTTPS而不是JSON格式中的标准DNS消息格式-或者与Cloudflare如何处理两种不同协议有关。

　　我们不是蝙蝠侠。但是我的威胁模型比大多数还要复杂一些。我们不是蝙蝠侠。但是我的威胁模型比大多数还要复杂一些。我如何学会停止担忧（大部分），并热爱我的威胁模型，我是一个专业的偏执狂。我的威胁模式与您的威胁模式不同，我宁愿尽可能保持尽可能安全的在线活动。但考虑到当前隐私和安全威胁的数量，这些威胁利用了对DNS流量的操纵，很多人使用某种形式的DNS加密是一个很好的例子。正如我愉快地发现的那样，我看到的所有三种协议的实现都没有对网络流量速度产生深远的负面影响。

　　但是，注意到这些服务本身并不能确保您的浏览被隐藏也很重要。在HTTPS连接中使用的TLS的服务器名称指示器（SNI）扩展仍然可以以纯文本形式显示您正在访问的站点的名称，如果它位于多个站点上的服务器。为了实现完全的隐私，您仍然需要使用VPN（或Tor）封装您的流量，以便您的ISP或监控您的流量的其他方不能从中获取元数据（并且这些服务都不适用于Tor）。如果你正在与一个国家资助的对手打交道，那么所有的投注都是关闭的。

　　如果你（理所当然）警惕商业选择，如何构建自己的VPN，另一个问题是，尽管DNSCrypt社区中的优秀人员做了很好的工作，但这种隐私对于普通人来说仍然太难了。尽管我发现配置这些加密的DNS客户端相对容易，但它们都不会对普通的互联网用户来说非常容易实现。为了使这些服务变得非常有用，他们必须更好地融入到人们购买的东西中-回家路由器和桌面和移动操作系统。

　　传统的DNS流量将会越来越多地被互联网提供商货币化，并且它将继续成为国家和罪犯的工具，以引导互联网用户受到伤害。但主要的操作系统开发人员不太可能会采用大多数用户可以访问的方式来支持DNS，因为他们通常和ISP一样在货币化的游戏中。最重要的是，这些开发人员可能会面临来自希望保留DNS监控功能的政府进行更改的阻力。所以现在，这些协议将继续成为少数几个关心隐私的人的工具。希望围绕DNSCrypt的隐私社区继续关注事态发展。(来源：黑客周刊，欢迎分享)