DNS — An Underrated Part of Your Digital Identity

大多数用户将 DNS 视为后台运行的技术细节。网络可以打开，网站可以加载——这意味着一切配置正确。因此，许多人只需设置一次 Google 公共 DNS (8.8.8.8) 或 Cloudflare (1.1.1.1)，甚至直接使用服务商提供的自动设置，之后便不再操心。对于日常上网来说，这种方式完全足够。但当涉及到代理、反检测浏览器、自动化、网络爬虫或信息安全研究时，DNS 就不再是次要设置了。它成为了你在线身份的一部分。

值得注意的是，DNS 是互联网最古老的机制之一。它的基础可以追溯到 20 世纪 80 年代初（关键的 RFC 1034 和 1035 可以追溯到 1987 年），当时隐私和反欺诈的概念还鲜为人知。经典的 DNS 请求以明文形式通过 UDP 协议发送到 53 端口——ISP 和沿途的任何中间节点都能看到它。这种“历史遗留问题”既催生了现代问题，也催生了解决这些问题的尝试，例如加密 DNS。了解这些背景有助于我们理解，为什么选择解析器不仅仅是一个表面功夫。

DNS 不仅仅是一本电话簿

DNS 常被比作互联网的电话簿：域名被转换成 IP 地址，浏览器随后连接到正确的服务器。这种解释固然正确，但过于简单。如今，DNS 的应用远不止于此，它还用于负载均衡、选择最近的 CDN 节点、路由、确保容错以及构建用户统计画像。地理 DNS 和基于延迟的路由就是很好的例子。同一个域名会根据请求者的身份和位置返回不同的 IP 地址。例如，一个托管在 CDN 上的大型网站，如果通过德国的解析器请求，会返回一个边缘服务器；而如果通过美国的解析器请求，则会返回另一个边缘服务器。AWS Route 53 或 Cloudflare 负载均衡等服务开箱即用地实现了这一点：它们会为记录设置非常短的 TTL（有时是 30-60 秒），以便快速切换流量并维持容错能力。正是这种使域名“弹性”的机制，将 DNS 转化为网络认为客户端所在位置的实时信号。

EDNS客户端子网（ECS，RFC 7871）值得单独提及。这是一种扩展，解析器会将客户端子网的一部分传递给权威服务器，以便CDN能够找到更近的节点。这听起来纯粹是技术术语，但其含义很简单：解析器甚至可以在主连接建立之前，就将连接的大致地理位置传递给外部服务器。不同的解析器在此方面的行为有所不同——我们将在下文中详细介绍。

这就是为什么现代反欺诈系统不仅分析 IP 地址，还会分析域名解析的执行方式。现代安全防护的核心理念很简单：系统几乎从不仅凭单一指标做出决策。它会评估多种信号的组合，并生成风险评分。一条异常的 DNS 记录本身并不能说明任何问题。但如果再加上时区不匹配（例如，系统显示欧洲/柏林，但浏览器语言为 en-US）、IP 地理位置、设备指纹（Canvas、WebGL、字体集）和网络特征等信息，那么分析结果就显得不那么可靠了。每个指标单独来看都不够有力，只有它们的组合才能提供足够的信息。

为什么公共 DNS 并非总是最佳选择

Google 公共 DNS 和 Cloudflare 都是非常优秀的服务。它们速度快、稳定性高，并且支持现代协议：DNSSEC、DNS over HTTPS 和 DNS over TLS。例如，Cloudflare 在数百个城市以任播网络的形式运行，独立测试也始终将其解析器评为全球速度最快的解析器之一。问题不在于它们的质量，而在于使用环境。

ECS 的行为恰恰体现了其中的关键区别。谷歌公共 DNS 会将截断的客户端子网发送给权威服务器（通过将地址的最低有效位置零），以便更精确地选择 CDN 节点。而 Cloudflare（地址为 1.1.1.1）出于隐私考虑，根本不发送 ECS。两者本身并无“好”或“坏”之分，但它们的情况却截然不同。使用谷歌，权威服务器可以大致了解你的地理位置；而使用 Cloudflare，服务器则无法获得此类信息，但路由到 CDN 的精度可能会降低。普通用户不会注意到这一点。但对于构建一致网络配置文件的用户而言，这又是一个与现有规则相符或相悖的参数。

还有一种更简单的解释。大多数家庭用户根本不会更改 DNS 设置，而是通过 ISP 的服务器访问网络，这些服务器的 DNS 服务器是通过 DHCP 自动分配的。因此，如果目标是看起来像某个特定网络的普通用户，那么 ISP 的 DNS 服务器通常比公共 DNS 服务器更自然。在这种情况下，公共 DNS 服务器（例如 8.8.8.8 或 1.1.1.1）是刻意配置的标志：它们通常被发烧友、管理员和企业网络用户选择，但普通移动用户不会使用。这并不意味着公共 DNS 服务器“不好”，它只是反映了你网络连接方式的不同。

稳定性比速度更重要

“一致性”一词在专业领域中的使用越来越频繁。它指的是网络配置文件中的所有元素都保持一致。例如，如果一个IP地址属于一家德国移动运营商，那么可以合理预期其时区为德国时区（Europe/Berlin），系统区域设置采用德语或英语，并且DNS解析通过与该网络合理连接的基础设施进行，而不是通过将请求物理路由到其他大洲的任播节点。

想象一下一个典型的差异：IP 地址属于一家德国移动运营商，浏览器时区设置为欧洲/柏林，但 DNS 请求却发送到 8.8.8.8，实际访问的网络却是通过谷歌的美国服务器，而且界面语言设置为 en-US。这些因素本身并不令人担忧。但它们组合在一起，就构成了一种难以用正常用户行为解释的异常情况。每个偏差单独来看都无关紧要，但每个新的差异都会增加用户行为异常的可能性。在这种情况下，解析速度几乎可以忽略不计：10-20 毫秒的提升并不值得牺牲一致性。

务实的方法

DNS 选择不应该从“哪个服务器速度最快”这个问题开始，而应该从“这个系统应该如何呈现给用户？”这个问题开始。然后，决策通常会根据代理类型而细分。

对于移动和住宅（ISP）代理服务器而言，最自然的方式是通过相应提供商的基础设施进行域名解析——或者至少是通过隧道另一端的解析器进行解析，而不是从用户的实际计算机进行解析。关键原则是 DNS 解析应该通过代理服务器进行，​​而不是绕过代理服务器。这样，请求的地理位置和 ECS 提示（如果传输）都将与主流量源的 IP 地址匹配。

对于数据中心服务器而言，整个配置的内部一致性比试图模拟家庭互联网连接更为重要。数据中心使用 Cloudflare 或自有解析器并不令人意外——但如果所有节点都能表现一致、可预测且无泄漏，这本身就是一个稳定，或者说，可以说是“乏味”的局面。这里没有通用的解决方案：正确的答案并非取决于速度等级，而是取决于系统必须支持的特性。

DNS泄漏和现代浏览器

DNS 泄漏通常是指 DNS 请求的路径与主流量不同。例如，HTTP 请求会经过代理服务器，而 DNS 请求则直接通过本地 ISP 发送。这会导致额外的不一致：网站在连接中“看到”的是一个 IP 地址，而沿途的权威 DNS 服务器看到的请求来源却完全不同。这种泄漏的一个典型来源是使用 SOCKS5 协议时的名称解析位置。即使在 curl 层面上，这种差异也很明显：socks5:// 协议强制客户端在本地解析域名（请求绕过代理服务器），而 socks5h:// 协议则将域名传递给代理服务器，由代理服务器在其端进行解析。浏览器中的逻辑也相同：在 Firefox 中，这是由 network.proxy.socks_remote_dns 参数控制的。如果禁用此参数，域名将在本地解析，即使代理配置正确，也会导致泄漏。这个小小的配置细节会彻底改变 DNS 泄漏的位置。

由于现代浏览器越来越多地使用基于 HTTPS 的 DNS (DNS over HTTPS)，情况变得更加复杂。Firefox 于 2020 年率先为美国用户默认启用 DoH；同年，Chrome 也添加了安全 DNS 模式。Chrome 在这方面非常谨慎：它不会更改您的 DNS 提供商，而只会在现有解析器支持 DoH 的情况下将其升级到加密版本。然而，对于通过代理访问的用户来说，这存在一个弊端：如果浏览器自动切换到 Cloudflare 的 DoH 端点而非您的实际连接，即使 HTTP 请求是通过代理发送的，DNS 也可能绕过隧道泄露。此外，浏览器并非唯一拥有自身名称解析机制的平台：Android 9 及更高版本支持私有 DNS（基于 TLS 的 DNS），Windows 11 在系统层面支持 DoH，而各个应用程序也以各自的方式实现解析。因此，如今仅仅检查操作系统设置是不够的；了解每个应用程序的具体行为至关重要。还要注意不要将 DNS 泄漏与 WebRTC 泄漏混淆：后者不会泄露名称，而是通过 STUN 泄露本地和公共 IP 地址——这是一个单独的通道，也应该关闭。

主要结论

近年来，反欺诈技术发生了显著变化。过去，主要关注点是IP地址及其信誉。如今，用户的整个数字身份都会被分析：浏览器、设备、语言、时区、路由、解析器行为、DNS泄漏以及其他数十种信号。本质上，这是一种概率模型，它将一些弱特征组合成单一评估——而引入任何新的差异几乎总是会造成比快速解析器节省的几毫秒更大的损失。

这就消除了寻找“完美DNS”的意义。从整体上考虑系统才是更有意义的做法。此外，过于理想化、不切实际的配置有时反而比标准配置更令人怀疑：真实用户并非完美无缺。好的配置不必做到完全透明——它应该看起来合乎逻辑、自然流畅，并且各个组成部分之间不应相互矛盾。这种方法——注重一致性而非追求个别“最佳”参数——通常从长远来看更具可持续性：声誉会随着时间的推移而建立，而始终保持一致性的配置方案才能经受住时间的考验。