当前位置：首页 > 解决方案 > IDC资讯 > 行业新闻

       CloudFlare的任务是帮助建立一个更好的互联网，今天我们将发布DNS解析器1.1.1.1——一个递归的DNS服务。通过此服务，我们正在通过构建一个更快、更安全和以隐私为中心的公共DNS解析器，从而解决互联网的基础问题。DNS解析器1.1.1.1面向公众开放供所有人使用，它是Cloudflare发布的第一款以消费者为中心的服务。

      我们使用以下IPv 4地址作为解析器：1.1.1.1和1.0.0.1，很容易记住吧。这些地址已由APNIC提供给Cloudflare，用于联合研究和此项服务。您可以通过APNIC博客了解更多相关的工作进展。

DNS解析器1.1.1.1由Cloudflare的Global Anycast Network提供服务.

背景：快速回顾解析器在DNS中的作用

        我们在DNSimple的朋友已经为任何人提供了这个惊人的DNS教程，以填补他们在DNS工作原理上的空白。它们以非常丰富的方式解释了所有有关解析器、根域名服务器等等。

        解析域名时，查询会从您的终端系统（即Web浏览器）传输到递归DNS服务。如果DNS记录不在服务器的本地缓存中，递归器将查询权限DNS层次结构，以查询您要查找的IP地址信息。递归是DNS解析器1.1.1.1所扮演的角色。它必须快速且安全地进行解析！

DNS解析器的目标，1.1.1.1

        我们使用公共解析器的目标很简单：CloudFlare希望在提高用户隐私保护标准的同时，运行全球速度最快的公共解析器。为了加速互联网，我们已经在全球各地建立数据中心，以减少从用户到信息内容的距离(即延迟)。最终我们希望每个人都至少在我们的一个地点的10毫秒之内获得服务。

       仅在三月份，我们就启用了全球31个新的数据中心(伊斯坦布尔, 雷克雅未克, 利雅得, 澳门, 巴格达, 休斯顿，印第安纳波利斯，蒙哥马利，匹兹堡，萨克拉门托, 墨西哥城, 特拉维夫, 德班，路易港, 宿务, 爱丁堡, 里加、塔林、维尔纽斯, 卡尔加里，萨斯卡通，温尼伯, 杰克逊维尔，孟菲斯，塔拉哈西, 波哥大, 卢森堡市，基希讷乌)，就像我们网络中的其他城市一样，新网站在第一天就会运行DNS解析器1.1.1.1！

         我们的快速高度分布式网络旨在为任何协议提供服务，并且我们目前是互联网上速度最快的权威DNS提供商，拥有超过700万的互联网属性。另外，我们已经为13个根域名服务器中的两个提供了任播服务。下一个合乎逻辑的步骤是为用户提供更快的递归DNS服务。我们的递归程序可以利用与我们共存的权限服务器，从而加快查找所有域名的速度。

       虽然DNSSEC确保了解析器和权限服务器之间数据的完整性，但它不会保护您的“last mile”的隐私。DNS解析器1.1.1.1支持新兴的DNS隐私标准-DNS-over-TLS和DNS over-HTTPS，它们都提供last mile的加密功能，以保护您的DNS查询不被篡改。

使我们的解析器具有隐私意识

       从历史上看，递归将完整的域名发送给任何中介机构，因为它找到了通向根或权限DNS的路径。这意味着如果你要访问www.Cloudflre.com，根服务器和.com服务器都将使用完整的域名(即万维网，cloudflare，以及COM)，即使根服务器只需要将递归重定向到 .com(独立于完全限定的域名中的其他任何内容)。通过DNS访问所有这些个人浏览信息的方便性给许多人带来了严重的隐私问题。尽管并非所有的解决方案都得到了广泛的调整或部署，但已经有几个解析器的软件包解决了这个问题。

        DNS解析器1.1.1.1在第一天提供了所有已定义和建议的DNS隐私保护机制，供在根解析程序和递归解析程序之间使用。对于那些不熟悉的人，根解析器是操作系统中与递归解析器对话的组件。通过仅使用RFC7816中定义的DNS查询名称最小化，DNS解析器1.1.1.1可减少泄露给中间DNS服务器（如根和TLD）的信息。这意味着DNS解析器1.1.1.1仅向权威机构发送足够的域名，以告知解析器在哪里询问下一个问题。

         DNS解析器1.1.1.1也支持端口853(TLS上的DNS)上启用隐私的TLS查询，因此我们可以将查询隐藏在监听网络中。此外，通过提供实验DoH((DNS over HTTPS)协议，我们加强了隐私和一些终端用户的未来速度，因为浏览器和其他应用程序现在可以将DNS和HTTPS流量融合到一个单独的连接中。

         使用DNS攻击负缓存，如RFC 8198中所述，我们可以进一步减少全球DNS系统的负载。该技术首先尝试使用现有的解析器负面缓存，负面缓存在一段时间内保持负面（或不存在）信息。对于使用DNSSEC签名的区域和缓存中的NSEC记录，解析器可以在不执行任何进一步查询的情况下确定请求的名称是否不存在。所以如果你输入wwwwwww.xxxx.wwww.xxx，第二个查询会很快地回答为“no”(DNS世界中的NXDOMAIN)。积极的负缓存只适用于DNSSEC签名区域，其中包括根和今天签署的1544个TLD中的1400个。

         我们尽可能使用DNSSEC验证，因为这样可以确保答案准确无误。签名验证的成本很低，我们从攻击负缓存中获得的潜在节省远远超过了弥补这一点。我们希望用户信任给出的答案，从而执行所有可能的检查，以避免给用户提供错误的答案。

        然而，DNSSEC是非常无情的。权限DNS运营商在DNSSEC配置中的错误可能会导致配置不当的域无法解析。为了解决这个问题，Cloudflare将在被检测到的DNSSEC错误上配置“Negative Trust Anchors”，并在配置被权威操作人员纠正后删除它们。通过暂时禁用特定错误配置域的DNSSEC验证，恢复对终端使用者的访问，从而限制了DNSSEC域名被破坏的影响。

我们是怎么构建的？

        最初，我们考虑建立自己的解析器，但由于复杂性和上市考虑，我们没有采用。然后，我们查看了市场上的所有开源解析器；从一份长长的清单中，我们将我们的选择缩小到了两个或三个，以适应大多数项目目标。最后，我们决定围绕CZ NIC的Knot Resolver构建系统。它是当前的解析器，最初是在两年半前发布的。通过选择Knot Resolver，我们也增加了软件的多样性。关键在于它有更多我们想要的核心特性，采用类似于OpenResty的模块化架构。Knot Resolver正在积极使用和开发中。