有关Cloudflare Radar 的新DNS见解的一些 TXT 和 A PTR to

这不是玩笑——Cloudflare 的 1.1.1.1 解析器 于 2018 年愚人节 发布。在过去的七年里，这一高性能和隐私意识的服务已经发展到平均每天处理来自全球大约 250 个位置（国家/地区）的 1.9 万亿次查询。对这些流量进行汇总分析，为我们提供对互联网活动的独特见解，不仅仅是简单的 Web 流量趋势，我们目前使用 1.1.1.1 数据分析来支持 Radar 的 域名 页面以及 Radar 域名排名 。

2022 年 12 月， Cloudflare 加入了 AS112 项目，该项目帮助互联网处理被错误引导的DNS查询。2023 年 3 月，我们在 Radar 上推出了 AS112 统计 页面，深入介绍这种被错误引导的流量的流量趋势和查询类型。为了扩展该页面上的基本分析，并在 Domains 页面上所用的解析器数据分析的基础上，今天我们很高兴地在Cloudflare Radar 上推出了一个专门的DNS页面，以就 1.1 平台上的总流量和使用趋势提供更深入的了解。 1.1 解析器流量除了关注全球、地区和自治系统 (ASN) 流量趋势外，我们还提供有关协议使用情况、查询和响应特征以及DNSSEC使用的观点。

针对这个新页面分析的流量可能来自手动配置其设备或本地路由器以使用 1.1.1.1 作为解析器的用户、将 1.1.1.1 设置为其订阅用户的默认解析器的 ISP、将 1.1.1.1 作为默认解析器的 ISP。连接到自己的解析器的上游，或已在其设备上安装 Cloudflare 的 1.1.1.1/WARP 应用 的用户。流量分析基于匿名DNS查询日志，符合 Cloudflare 的隐私政策，以及我们的 1.1.1.1 公共 DNS 解析器隐私承诺。

下面，我们将浏览 Radar 新DNS页面的各个部分，回顾其中包含的图表以及它们所提供指标的重要性。这些图表中显示的数据和趋势将根据聚合查询的位置或网络来源，以及所选的时间范围而有所不同。

流量趋势

与许多 Radar 指标一样，DNS页面以流量趋势开头，显示全球水平（默认）或选定位置或自治系统 (ASN)的标准化查询量。与其他 Radar 基于流量的图表类似，可以使用日期选择器调整显示的时间段，对于默认选择（过去 24 小时、过去 7 天等），还可以与前一时间段的流量进行比较。绘制了。

对于位置级别视图（例如 拉脱维亚 ，以下示例中），图表旁边会显示按查询量列出的前五个 ASN。表格显示网络在所选位置的查询份额，并深入了解哪些提供商的用户产生了最多 1.1.1.1 流量。

选择一个国家/地区后，除了显示该位置的汇总流量图表外，还会显示与该国家/地区相关的国家代码顶级域（ccTLD）的查询量。图表中包含的一条线显示该 ccTLD 的全球查询量，以及基于来自关联位置的查询显示查询量。安圭拉的 ccTLD 是 .ai并且受到越来越多专注于 AI 的公司的欢迎。虽然大多数地区的 ccTLD 的全球查询量与“本地”查询量之间存在差距，但安圭拉的。（.ai 的流量来自安圭拉的域在图表底部由深蓝色的线显示。）同样，其他“热门”ccTLD （例如 .io( 英属印度洋领地 ), .fm（密克罗尼西亚联邦），以及 .co（哥伦比亚）。与全球查询量相比，其他地点的“本地” ccTLD 查询量较高会导致较小的差距。

根据来自给定位置或 ASN 的信号强度（即流量大小），此数据也可用于证实报告的互联网中断或关闭，或报告的 1.1.1.1 阻止操作。例如，下图显示了据报道委内瑞拉提供商 CANTV阻止其用户访问 1.1.1.1的结果。Supercable 的流量下降幅度情况类似，据报道，另一家委内瑞拉提供商 Supercable 也几乎在同一时间阻止了对 Cloudflare 解析器的访问。

单个域页面（例如 cloudflare.com 、 域）长期以来一直使用等值区统计图和随附的表格，显示域按位置的受欢迎程度，基于每个位置该域的DNS查询占比。全球概述页面的底部有一个类似的视图，基于每个位置对全球 1.1.1.1 进行的查询占全球总数的份额。

查询和响应特征

流量趋势总是有趣且值得跟踪的，但对 1.1.1.1 查询和相关响应的特征分析可以提供对底层传输协议采用情况、记录类型受欢迎程度、可缓存性和安全性的洞察。

1987 年 11 月发布的 RFC 1035 指出： “互联网支持在服务器端口 53（十进制）上使用TCP [RFC-793] 的名称服务器访问，以及在UDP端口 53（十进制）上使用UDP [RFC-768] 的数据报访问。”在随后的三年多时间里， UDP一直是DNS查询的主要传输协议，在有限数量的用例中，例如在响应太大而无法放入单个UDP数据包时，回退到TCP 。然而，随着隐私成为一个远得多的问题，2016 年的DNS over TLS (DoT) 和 2018 年的DNS over HTTPS (DoH) 规范使加密查询成为可能。Cloudflare 的 1.1.1.1 解析器自 推出 以来一直支持这两种隐私保护协议。DNS传输协议图显示了对 1.1.1.1 的查询通过这四种协议的分布情况。（在您的设备或路由器上设置 1.1.1.1 ，默认使用DNS over UDP，尽管最新版本的 Android 会支持 DoT 和 DoH。1.1.1.1 应用 默认使用DNS over HTTPS，用户也可以 将其浏览器配置 为使用DNS over HTTPS。）

请注意，Cloudflare 的解析器还为 Mozilla 和其他大型平台提供通过 DoH 和 Oblivious DoH (ODoH) 的查询，但这种流量目前不包含在我们的分析中。因此，DoH 采用在此图中并未得到充分体现。

在 2 月 19 日至 2 月 26 日全球范围内汇总，传输协议的分布比例为UDP、 9.6% DoT 、 2.0% TCP和 1.7% DoH。然而，在某些地方，如果用户更具隐私意识，这些比率可能会发生变化。例如，下图显示了同一时间段内埃及的分布情况。在该国家， UDP和TCP 的份额显着低于全球水平，而 DoT 和 DoH 的份额显着高于全球水平，这表明该国的用户可能比全球平均水平更加关注其DNS查询的隐私性，或者Android 设备上 1.1.1.1 用户的较大集中度，他们已手动设置了使用 DoT 的 1.1.1.1。（ 2024 年 Cloudflare Radar 年度回顾发现，Android 在埃及拥有 85% 的移动设备流量份额，因此该国的移动设备使用非常倾向于 Android。）

RFC 1035 还定义了许多标准和互联网特定的资源记录类型，它们返回有关已提交查询名称的关联信息。 最常见的记录类型是 A 和 AAAA ，它们分别返回主机名的 IPv4 和 IPv6 地址（假设它们存在）。下面的DNS查询类型图表显示，在全球范围内，这两种记录类型占 1.1.1.1 收到的查询的 80% 左右。在图中显示的其他记录中，HTTPS 记录可用于表示 HTTP/3 和 HTTP/2 支持，PTR 记录在反向DNS记录中使用，以根据给定IP地址查找域名，NS 记录表示权威性域名的 DNS 记录

从 1.1.1.1 到客户端的每个响应中，都会发送一个响应代码。六个可能的值最初在 RFC 1035 中定义 ，列表在 RFC 2136 和 RFC 2671 中 进一步扩展 。NOERROR，顾名思义，意味着查询没有遇到错误。其他一些条件，如 NXDOMAIN 、 SERVFAIL 、 REFUSED 和 NOTIMP 定义尝试解析尝试解析所请求的查询名称时遇到的特定错误条件。响应代码可能由 1.1.1.1 本身生成（如 REFUSED ），或者可能来自上游权威性域名服务器（如 NXDOMAIN ）。

从下面的DNS响应代码图可以看出，全球范围内的绝大多数查询在解析过程中都没有遇到错误( NOERROR )，而且遇到错误时，大多数是 NXDOMAIN (没有这样的记录)。值得注意的是，NOERROR 还包括空响应，这种情况在没有查询名称和查询类型的记录，但有查询名称和某些其他查询类型的记录时会发生。

由于DNS是许多其他协议的第一步依赖，特定类型的查询数量可用于间接衡量这些协议的采用情况。但为了有效衡量采用情况，我们还应该考虑查询中得到有用响应的比例，这些查询通过DNS 记录采用图表表示。

下面的例子显示，对A记录的查询在接近 88% 的时间内获得有用的响应。由于 IPv4 是 成熟的协议，其余的 12% 很可能是对没有A 记录的有效主机名的查询（例如（例如只有 MX 记录的电子邮件域）。但同一张图表还显示，在 IPv6 方面，采用仍然存在很大差距。

当 Cloudflare 的DNS 解析器从上游权威性域名服务器获得响应时，它会在指定的时间内缓存该响应，下面将详细介绍。通过缓存这些响应，它可以更有效地为相同名称的后续查询提供服务。DNS缓存率图表深入了解从缓存提供响应的频率。如下所示，在全球范围内，超过 80% 的查询会有已经缓存的响应。这些比率将因地点或 ASN 的不同而异，因为查询模式因地理位置和网络而异。

如上一段所述， 当权威性域名服务器向 1.1.1.1 发送响应时，其中的每条记录都包含有关其应缓存多长时间/应被视为有效的时间的信息。这条信息就是生存时间 (TTL)，由于响应可能包含多个记录，这些 TTL 中最小的一个（“最小” TTL）定义了 1.1.1.1 可以将整个响应缓存多长时间。 。从每个 1.1.1.1 的随着时间推移，缓存趋于零，此时 1.1.1.1 需要变回权威性域名服务器。TTL值相对较低的主机名表明，这些记录可能在某种程度上是动态的，可能是由于相关资源的流量管理所致； TTL值较长表明关联资源更加稳定，预计不会经常更改。

DNS最小TTL图表显示了五种流行的DNS 记录类型的TTL值的汇总分布，细分为七个范围，从不到一分钟到超过一周不等。例如，在 2 月第三周，A 和 AAAA 响应集中有较低的 TTL，超过 80% 低于五分钟。相比之下，NS 和 MX 反应在 15 分钟到一小时和一小时到一天的时间内更集中。由于 MX 和 NS 记录很少更改，因此通常为它们配置较高的 TTL。这允许它们被缓存更长时间，以实现更快的DNS解析。

DNS 安全

DNS安全扩展 (DNSSEC) 为DNS添加了额外的身份验证层，以确定DNS响应的完整性和真实性。这可确保后续的 HTTPS 请求不会路由到欺骗性域。向 1.1.1.1 发送查询时，DNS客户端可以通过在查询中设置一个特定的标志（“DO”位）来表明它能够感知DNSSEC，这让我们的解析器知道可以在响应中返回DNSSEC数据。DNSSEC客户端意识图谱详细分析了 1.1.1.1 理解DNSSEC并可能要求验证响应的查询各客户端与不需要的客户端之间的比例。（请注意，默认情况下，1.1.1.1 尝试通过始终验证来自权威名称服务器的DNSSEC响应而不将无效响应转发给客户端来保护客户端，除非客户端通过设置“CD”（检查禁用）位明确告诉它不要这样做在查询中）。

遗憾的是，如下图所示，Cloudflare 的解析器看到的查询中有近 90% 是由不能感知DNSSEC 的客户端发出的。这种客户端意识普遍缺乏的原因可能有几个。在客户端端，默认情况下不会为大多数用户启用DNSSEC ，启用DNSSEC需要额外的工作，即使对于精通技术和具有安全意识的用户而言也是如此。权威方面，对于域名所有者来说，支持DNSSEC需要额外的运营维护和知识，一个错误可能导致您的域名从互联网上消失，造成重大（包括财务）问题。

端到端安全图表示，在考虑客户端的DNSSEC能力和加密的使用（使用 DoT 或 DoH）时，不受篡改的DNS交互比例。这表明全球层面上更大的不平衡，并凸显了进一步采用加密和DNSSEC的重要性。

为了进行DNSSEC验证，所请求的查询名称必须是启用了DNSSEC的域的一部分， DNSSEC验证状态图表示查询的比例，而不是安全和无效标签下的情况。对没有DNSSEC的域的查询标记为 不安全，将DNSSEC验证不适用的查询（例如各种错误）标记为其他标签。尽管近 93% 的通用顶级域（TLD）和 65% 的国家/地区代码顶级域（ccTLD）都用DNSSEC签名（截至 2025 年 2 月），但单个（子）域的采用率明显滞后，因为图表如下图所示，超过 80% 的查询被标记为不安全。

总结

DNS是互联网不可或缺的组成部分。虽然大多数互联网用户并不认为DNS超出了其将易于记忆的主机名转换为IP地址的作用，但从隐私到性能到安全性，还要进行很多工作才能实现这一点。Cloudflare Radar 上的新DNS页面致力于让您了解全球、国家和网络层面的幕后活动情况。

虽然上面显示的图表取自DNS页面，但所有底层数据都可通过API获得，并且可以使用 Radar 的Data Explorer 和 AI Assistant进行更详细的跨位置、网络和时间段的探索。一如既往，Radar 和 Data Assistant 图表可下载以分享，并可嵌入到自己的博客文章、网站或仪表板中使用。

如果您在社交媒体上分享我们的DNS图表，请务必标记我们：@CloudflareRadar 和 @1111Resolver (X)、noc.social/@cloudflareradar (Mastodon) 以及 radar.cloudflare.com (Bluesky)。如有疑问或意见，可以通过社交媒体联系我们，或通过电子邮件联系我们。