Skip to content
←

필사 모드: DNS 深度剖析 — 名字背后隐藏的基础设施

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 免费 DNS 再度点燃的关注

2026 年上半年,GeekNews 和 Hacker News 上 DNS 再次成为话题。起因是一家 CDN 厂商宣布将自家的 Anycast DNS 服务免费开放。开发者们一边发出「DNS 都免费送了?那这家公司靠什么赚钱」的疑问,一边也抛出了更根本的问题 ——「DNS 一开始为什么就需要这么复杂的基础设施」。

对大多数开发者来说,DNS 不过是「把域名转换成 IP」的东西。在浏览器里敲下地址,某个地方就像变魔术一样解析出来并连上服务器。但这场魔术的背后,是散布在全球各地的数万台服务器、精细的缓存层、路由技巧,以及安全扩展交织在一起。DNS 是互联网上最古老、却也最被低估的分布式系统。

本文将深入剖析隐藏在名字背后的基础设施 —— 一个名字变成 IP 的短短一瞬间究竟发生了什么、为什么需要 Anycast、DNSSEC 守护的是什么,以及 DoH 与 DoT 如何改变隐私。

DNS 的层级结构

DNS 不是一台巨型服务器,而是一套委派的层级结构。最顶端是根,往下如树状展开。

                    . (根)
                    |
        +-----------+-----------+
        |           |           |
       com         org          kr
        |           |           |
     example     wikipedia    co.kr
        |
      www.example.com

关键在于要从右往左读这个名字。www.example.com 其实背后还藏着一个点,完整形式是 www.example.com.,最后那个点就是根。每一层只知道「谁知道」下一层。

  • 根服务器:知道 com、org、kr 这类顶级域(TLD)由谁管理。
  • TLD 服务器:知道 example.com 的权威服务器在哪里。
  • 权威服务器(authoritative):知道 www.example.com 的实际 IP。

正是这套委派结构,让任何单一组织都不需要管理互联网上的全部名字。每一层只负责自己的区域(zone),其余的向下委派出去。

解析过程 — 递归与权威

解析一个名字的过程,是两类服务器协作完成的:递归解析器(recursive resolver)和权威服务器(authoritative server)。

递归解析器是代替你去找答案的跑腿人。你的设备、运营商,或是公共解析器扮演这个角色。权威服务器则是持有某个区域最终答案的服务器。

首次解析 www.example.com 时,实际流程如下。

客户端 --> 递归解析器
                  |
                  |-- 1. 问根服务器:com 由谁管理?
                  |<-- com TLD 服务器地址
                  |
                  |-- 2. 问 com TLD 服务器:example.com 归谁?
                  |<-- example.com 权威服务器地址
                  |
                  |-- 3. 问权威服务器:www.example.com 的 IP 是?
                  |<-- 最终 IP 地址
                  |
客户端 <-- 递归解析器(最终答案)

这个过程叫作迭代查询(iterative query)。递归解析器从根开始,一步步往下走,逐层收窄答案范围。从客户端的角度看,只需要问解析器一次就能拿到最终答案,所以是递归查询。

重要的是,这整套流程大部分时候会被缓存省略掉。解析器通常早已知道根和 TLD 的信息,所以实际上往往只执行最后一步。

记录类型 — DNS 承载的信息

DNS 并不只保存 IP 地址。不同的记录类型存储着各自不同的信息。

记录用途值的形式示例
A名字对应 IPv4 地址93.184.216.34
AAAA名字对应 IPv6 地址2606:2800:220:1:248:1893:25c8:1946
CNAME指向另一个名字的别名www 指向 example.com
MX指定邮件服务器优先级与邮件主机
TXT任意文本(验证等用途)SPF、DKIM 等策略
NS该区域的权威服务器名称服务器主机名
SOA区域的管理信息序列号、刷新周期等

其中 CNAME 常被误解。CNAME 是一种别名声明,意思是「这个名字其实就是那个名字」。所以解析器遇到 CNAME 时,必须再去解析它指向的目标名字。另外,CNAME 原则上不能放在区域最顶层(apex),因此许多 DNS 提供商会提供绕开这一限制的特殊记录。

TXT 记录原本是给自由文本用的,如今却成了邮件认证(SPF、DKIM、DMARC)和域名归属验证的核心手段。这正是 DNS 从单纯的地址簿演变为策略分发通道的典型例子。

TTL 与缓存 — 让 DNS 变快的关键

如果 DNS 每次都要从根开始解析,互联网早就瘫痪了。让 DNS 变得实用的关键在于缓存,而支配缓存的正是 TTL(Time To Live)。

每条记录都附带一个 TTL 值,表示「这个答案可以被缓存多少秒」。如果 TTL 是 3600,解析器就会在一小时内重复使用这个答案,期间不再向权威服务器询问。

设置 TTL 是一种权衡。

  • 长 TTL:缓存命中率高,速度快,权威服务器负载低。但改了 IP 之后,要传播到全世界会花很长时间。
  • 短 TTL:变更传播得快。但查询变得频繁,负载增加,也会略微变慢。

在实务中,这个权衡要根据情况调整。比如在服务器迁移之前,会提前把 TTL 调短,等切换完成后再调回长值。这样可以把切换瞬间的停机时间降到最低。

缓存发生在多个层级:浏览器缓存、操作系统缓存、递归解析器缓存。所以即便改了记录,也会出现「为什么还是解析到旧 IP」的情况。多数时候是因为某处的缓存还在等 TTL 过期。

Anycast — 一个 IP,数十个服务器

这里就要请出免费 DNS 新闻背后的核心技术 —— Anycast 了。在普通的路由(unicast)中,一个 IP 指向一台服务器。Anycast 则不同:同一个 IP 地址,由全球多个地点的服务器同时对外宣告。

        同一个 IP 地址由多处同时宣告

  首尔用户 ---> [首尔节点]  \
  伦敦用户 ---> [伦敦节点]   >  都是同一个 IP
  纽约用户 ---> [纽约节点]  /

  路由会把每个用户送到「最近」的节点

互联网路由(BGP)会自动把每个用户送到网络意义上最近的节点。首尔用户去首尔节点,伦敦用户去伦敦节点。用户甚至不需要知道自己连的是哪个节点。

Anycast 给 DNS 带来三个好处。

  • 降低延迟:地理上更近的节点响应,速度更快。
  • 负载分散:流量自然而然地分散到多个节点。
  • 可用性与 DDoS 防御:即便某个节点宕机或遭受攻击,路由也会把用户导向其他节点。

这就是根服务器和大型公共解析器都使用 Anycast 的原因。虽然常说「13 个根服务器」,但实际上借助 Anycast,全球各地有着数百个物理实例。

GeoDNS — 因地点而异的答案

如果说 Anycast 是「从最近的地方给出同一个答案」,那么 GeoDNS 给出的则是「因地点而异的不同答案」。它会查看递归解析器的位置(或客户端子网信息),返回针对该地区优化过的 IP。

比如,给亚洲用户返回亚洲数据中心的 IP,给欧洲用户返回欧洲数据中心的 IP。CDN 把用户导向最近边缘节点的核心机制,正是这个 GeoDNS。

Anycast 和 GeoDNS 常常一起使用,但作用在不同的层。Anycast 在路由层实现地域性,GeoDNS 在 DNS 响应层实现地域性。把两者结合起来,既能就近处理 DNS 查询本身,也能把返回的内容 IP 引导到就近的地方。

DNSSEC — 保护答案免遭伪造

DNS 的根本弱点在于信任。递归解析器收到的答案究竟是真的来自权威服务器,还是被中间人伪造的,原始的 DNS 无从判断。缓存投毒(cache poisoning)攻击正是利用了这一点。攻击者只要在解析器缓存里植入一个假答案,用户即便敲对了真正的网址,也会被引导到假服务器上。

DNSSEC 用数字签名解决了这个问题。每个 DNS 响应都附带权威服务器的签名,由解析器负责验证。签名链从根一路向下延伸,所以只要信任根,就能信任整条链。

  根签名 --> TLD 签名 --> 域名签名 --> 记录
     |            |             |
   信任锚点    链式验证       链式验证

需要注意的是,DNSSEC 只保证完整性与真实性。也就是说,它证明的是「这个答案没有被伪造」,但并不保证「这次查询内容没有被窃听」。响应本身依然以明文往返。隐私的问题要靠其他技术来解决。

隐私 — DoH 与 DoT

传统的 DNS 查询以未加密的明文往返,这带来了严重的隐私问题。你访问了哪些网站,网络路径上的任何一方(运营商、公共 Wi-Fi 提供者、政府)都能一览无余。即便网页流量本身用 HTTPS 加密,「你要连到哪里去」这件事,一直是从 DNS 这里泄露出去的。

为了解决这个问题,出现了两种标准。

  • DoT(DNS over TLS):在专用端口上用 TLS 加密 DNS 查询。能看出这是 DNS 流量,但看不到内容。
  • DoH(DNS over HTTPS):把 DNS 查询包装成 HTTPS 请求。与普通网页流量难以区分,提供更强的隐蔽性。

两种方式的差异整理如下。

项目DoTDoH
传输方式专用端口,TLS承载于 HTTPS 之上
可识别性可识别为 DNS混入网页流量
管理侧控制相对容易困难(有争议)
主要使用场景操作系统/网络层浏览器层

DoH 强化了隐私,但也引发了争议。企业或学校原本靠网络策略屏蔽特定网站的做法,在 DoH 面前变得力不从心。隐私与管理控制之间的张力,至今仍是一个正在进行中的讨论。

性能与可用性 — DNS 为何是第一道瓶颈

谈到网页性能时,DNS 常常被遗忘,但它其实是每一次连接的第一道关卡。打开页面时浏览器最先做的事就是 DNS 解析,一旦这一步慢了,后面的一切都会被拖延。

有几种提升性能的实务技巧。

  • 合适的 TTL:太短会因查询频繁而变慢,太长又会失去灵活性。
  • 使用 Anycast 解析器:在就近节点完成解析,往返时间更短。
  • 连接复用与预取:利用浏览器预先解析域名的 DNS 预取(prefetch)。
  • 精简 CNAME 链:别名层层叠加会增加解析步骤。

在可用性方面,DNS 很容易成为单点故障。DNS 一旦挂掉,即便服务器完好无损,也没人能连上来。因此重要的服务会把名称服务器分散到不同的提供商那里做冗余,即使某一家出故障,名字解析也能继续进行。

CDN 与 DNS 的关系

在现代 Web 中,DNS 与 CDN 密不可分。CDN 把用户送到最近边缘服务器的第一步,正是 DNS。当用户解析一个域名时,CDN 的 GeoDNS 或 Anycast 会返回对该用户而言最优的边缘节点地址。

正是这套结构,让 CDN 能把内容放在离用户很近的地方,而 DNS 则负责把用户引导到那些就近的内容上。前面提到的免费 DNS 服务之所以成为话题,原因也在这里。免费提供 DNS 的 CDN 厂商,把 DNS 当作入口,借此把用户引流到自家的 CDN 与增值服务当中。「免费 DNS」的经济学就是这样解释的。

DNS 数据包的真实面貌 — 传输的是什么

要理解 DNS 的运作,看看实际传输的内容会很有帮助。DNS 查询与响应大多以非常小的数据包在 UDP 上传输。这种轻量性正是 DNS 保持快速的关键,但同时也是其弱点的来源。

一个典型的查询包含以下要素。

+---------------------------+
| 事务 ID(16 位)            |  <- 用于匹配查询与响应
+---------------------------+
| 标志位(查询/响应、递归)   |
+---------------------------+
| 问题部分                  |  <- 名字 + 类型(A、AAAA...)
+---------------------------+
| 应答部分                  |  <- 记录(仅响应中出现)
+---------------------------+
| 权威部分                  |
+---------------------------+
| 附加部分                  |
+---------------------------+

这里的事务 ID 很关键。解析器发送查询时会附上一个随机 ID,只有响应中携带相同 ID 才会被接受。早期 DNS 的一个漏洞在于,这个 ID 是可预测的。攻击者只要猜中 ID,就能把伪造的响应当作真的注入进去。所以现在不仅 ID,连源端口也一并随机化,以扩大被猜中的难度空间。

传统上,DNS 响应一旦超过 512 字节就会出问题。UDP 数据包变大时,要么被截断,要么得改用 TCP 重试。随着 DNSSEC 签名这类较大的数据加入进来,这个限制变成了负担,于是出现了扩展机制(EDNS),允许更大的 UDP 响应。

否定应答与缓存

DNS 处理的不只是「存在」的答案,也处理「不存在」的答案。查询一个不存在的名字时,权威服务器会返回否定应答。有意思的是,这种「不存在」也会被缓存。

如果否定应答不被缓存,只需反复查询一个不存在的名字,就能给权威服务器造成负载。实际上,确实存在配置错误的应用程序不断查询不存在的名字、折磨 DNS 基础设施的情况。否定缓存正是用来吸收这类负载的。

否定应答的缓存时间是单独管理的。区域的管理信息(SOA 记录)里写明了否定缓存时间,解析器会在这段时间内重复使用「这个名字不存在」的答案。这个值设得太长,新建名字生效就会拖得很久,所以需要权衡。

轮询与负载分散

DNS 也是一种原始却有效的负载分散手段。给同一个名字注册多条 A 记录后,解析器每次以不同顺序返回,或从多个 IP 中挑一个,从而分散流量。这就是所谓的 DNS 轮询(round-robin)。

  查询 www.example.com
        |
        v
  +------------------+
  | A 203.0.113.1    |
  | A 203.0.113.2    |  <- 返回多个 IP
  | A 203.0.113.3    |
  +------------------+
        |
   客户端挑一个(通常是第一个)

轮询很简单,但局限也很明显。DNS 并不知道每台服务器的实际负载或健康状态,即使某台服务器已经挂了,也会若无其事地返回它的 IP。所以现代系统会用结合健康检查的智能 DNS 来取代纯粹的轮询,或者在 DNS 后面再放一层负载均衡器。即便如此,轮询作为最简单的分散层,至今仍被广泛使用。

选择解析器 — 公共解析器还是运营商

用户可以选择使用哪个递归解析器。默认情况下用的是运营商提供的解析器,但许多用户会切换到大型公共解析器。这个选择在多个方面都会带来影响。

方面运营商解析器公共解析器
延迟通常较近借助 Anycast 可能更快
隐私由运营商记录由公共厂商记录
过滤应用运营商策略通常过滤较少
稳定性依赖运营商依托大型厂商的基础设施
功能有限支持 DoH/DoT 等新技术

这里存在权衡。公共解析器凭借 Anycast 与最新协议,性能与功能都更好,但代价是你的全部访问记录会集中到少数几家厂商手里。运营商解析器地域性强,但受制于运营商的过滤与监控。没有完美的选择,归根结底是你更信任谁的问题。

DNS 预取与浏览器优化

浏览器会使用多种优化手段来降低 DNS 延迟,其中具有代表性的就是 DNS 预取。如果页面上有链接,浏览器会在用户点击之前就预先解析那些域名。真正点击的那一刻,IP 已经准备就绪,连接会很快。

  页面加载
      |
      v
  发现链接(其他域名)
      |
      v
  在后台预先解析 DNS
      |
      v
  用户点击时 --> IP 已缓存 --> 立即连接

这项优化大多是有益的,但在隐私层面存在争议。即使用户没有点击某个链接,只要解析了它的域名,访问意图就已经暴露给解析器了。所以有些浏览器会视情况限制预取。

除此之外,浏览器还会通过连接复用、HTTP 连接池,以及新协议中的提前连接等技巧,降低包括 DNS 在内的连接建立成本。在网页性能优化中,DNS 常常被遗忘,但打磨这第一道关卡,对整体体感速度的影响意外地大。

DNS 为何使用 UDP

DNS 大多使用 UDP 是有原因的。TCP 建立连接需要往返,还必须维持状态。而 UDP 不需要连接,一次查询、一次响应就结束了。这种轻量性正是 DNS 能扛住庞大查询量的关键。

但 UDP 也有代价。它不会告诉你数据包是否丢失,不保证顺序,还有大小限制。所以当响应较大(比如 DNSSEC 签名、大量记录)或 UDP 不够可靠时,DNS 会转而使用 TCP。也就是说,DNS 采取的是一种双重策略:平时用快速的 UDP,需要时借助可靠的 TCP。

这种设计是「为常见情况优化,把例外单独处理」这一优秀工程原则的一个例子。绝大多数查询靠又小又快的 UDP 就能充分处理,只有少数的大响应才需要借助 TCP 的可靠性。

邮件与 DNS — MX 与认证的世界

DNS 不只是 Web 的基石,也是邮件基础设施的根基。发送邮件时,发件服务器会查询收件域名的 MX 记录,以决定把邮件转交给哪台服务器。MX 记录带有优先级,数字更小的服务器会被优先尝试,失败后再转向下一个。

现代邮件在此基础之上叠加了三层基于 DNS 的认证。

  • SPF:通过 TXT 记录声明哪些服务器可以代表这个域名发送邮件。
  • DKIM:给邮件附上数字签名,并把用于验证的公钥发布在 DNS 上。
  • DMARC:声明当上述两者验证失败时该如何处理(拒绝、隔离、放行)的策略,同样发布在 DNS 上。

没有这三者,任何人都可以冒充你的域名发送邮件。DNS 早已超越单纯的地址簿、成为信任基础设施的核心,这一点在这里体现得淋漓尽致。反垃圾邮件与反钓鱼防御的相当一部分,都依赖于发布在 DNS 上的策略。

可观测性 — 如何诊断 DNS

DNS 问题素以难以诊断而闻名。「偶尔连不上」这种模糊的症状背后,可能藏着缓存问题、传播延迟,或者错误的记录。实务中诊断 DNS 有几种常见思路。

首先,从多个地点查询同一个名字。由于 Anycast 和 GeoDNS 的存在,不同地点可能得到不同的答案,只从一个地方看会漏掉问题。这时候,能从全球多个节点查询 DNS 的工具就很有用。

接下来,确认 TTL 与传播状态。如果改了记录却没有生效,通常是某处的缓存还攥着旧的 TTL 不放。直接向权威服务器询问以确认最新值,再用 TTL 反推出传播到解析器需要多长时间。

DNS 可观测性的核心原则是「从多个层面去看」。要缩小范围,确定问题究竟出在浏览器、操作系统、解析器,还是权威服务器这几层中的哪一层,才能找到根因。只看一层,真相就会被缓存挡住。

常见陷阱与批判性视角

我们来盘点一下处理 DNS 基础设施时经常掉进去的陷阱。

因误解 TTL 而导致的停机。 改了 IP,但 TTL 设得很长,全球各地的缓存还攥着旧地址不放,对部分用户来说,服务看起来像是断了好几个小时。养成在迁移前提前调低 TTL 的习惯很有必要。

对单一提供商的依赖。 一旦大型 DNS 提供商出故障,依赖它的无数服务会同时瘫痪。现实中确实发生过多次大规模 DNS 故障,让互联网的很大一部分陷入停摆。名称服务器的冗余不是可选项,而是必需品。

DNSSEC 的低采用率。 DNSSEC 是个好主意,但配置起来很棘手,一旦出错,整个域名都可能变得无法解析。正因为这份复杂性,它的采用一直很缓慢。为了安全起见,使用自动化的签名管理工具很重要。

隐私的中心化悖论。 DoH 号称保护隐私,但如果浏览器把查询都集中导向少数几个大型解析器,所有的访问记录就都集中到了这几家厂商手里。有批评指出,试图保护隐私的努力,反而可能制造出新的监控节点。

分裂视界 — 同一个名字,不同的答案

展现 DNS 灵活性的另一项技巧是分裂视界(split-horizon)DNS。它会根据查询来源的位置,对同一个名字给出完全不同的答案。从内部网络查询会返回内部 IP,从外部互联网查询则返回外部 IP。

这在企业环境中很常见。内部员工访问公司服务时,会直接连接到内部网络上的私有 IP;从外部访问时,则要经过公开的网关。用的是同一个域名,但实际路径会因位置而异。

分裂视界很方便,但也提高了管理复杂度。必须同时维护内部与外部两套区域,一旦两者不一致,就会出现「外面能连、里面连不上」这类令人困惑的情况。所以这类配置尤其需要清晰的文档记录和自动化管理。

全局流量管理 — 超越 DNS

对大规模服务来说,仅靠 GeoDNS 是不够的。在决定把用户送到哪个数据中心时,不能只看地理距离,还要综合考虑每个数据中心当下的负载、健康状态和网络延迟。这正是全局流量管理(GTM)的领域。

GTM 也被称为智能 DNS,它会根据实时信号动态调整 DNS 响应。

  用户查询
      |
      v
  +--------------------+
  | 流量管理器          |
  |  - 地理位置         |
  |  - 数据中心负载     |
  |  - 健康检查结果     |
  |  - 网络延迟         |
  +--------------------+
      |
   选出最优 IP 后返回

这种方式比单纯的 GeoDNS 灵活得多。比如,如果附近的数据中心处于过载或故障状态,GTM 会避开它,把用户送到稍远一点的地方。用户完全察觉不到这个决策过程,只会觉得服务运行得很好。

这里 TTL 再一次变得重要。无论 GTM 的决策有多聪明,一旦这个决策被困在陈旧的缓存里,就毫无意义。所以 GTM 记录通常使用短 TTL。这是一种权衡:放弃一部分缓存带来的好处,换取实时响应能力。这再一次印证了,DNS 设计中的每一个决策,最终都站在这样的平衡点上。

新记录与不断演进的 DNS

DNS 是一个古老的协议,但仍在持续演进。为了呼应 Web 的新需求,新的记录类型与功能不断被加入。

一个具有代表性的例子是服务绑定记录。传统上,客户端要连接服务器,得先把名字解析成 IP,再另外查明连接参数(端口、协议、加密设置)。新的记录类型把这些信息一并放进 DNS 响应里,让第一次连接就能以最优设置开始。这对降低新一代 Web 协议中的连接延迟尤其有用。

DNS 的演进方向可以概括如下。

  • 连接优化:在名字解析这一步就一并提供连接提示,减少往返次数。
  • 隐私强化:超越 DoH/DoT,人们正在讨论把查询本身隐藏得更彻底的技术。
  • 安全扩展:DNSSEC 自动化工具日趋成熟,采用门槛正在降低。
  • 边缘整合:CDN 与 DNS 的边界日渐模糊,名字解析本身正在成为边缘计算的入口。

这股潮流表明,DNS 正在从单纯的「名字-地址转换器」,扩展为「互联网接入的智能协调者」。

实务要点小结

给处理 DNS 的开发者与运维人员的实务要点,压缩起来如下。

  • 迁移前提前调低 TTL,减少切换时的停机时间。
  • 名称服务器务必做冗余,尽量分散在不同的提供商上。
  • 确认否定缓存时间,以预估新记录生效的延迟。
  • 保持 CNAME 链简短,减少解析步骤。
  • 引入 DNSSEC 时配合自动化工具,防止配置失误。
  • 诊断问题时,从多个地点、多个层面去查询。
  • 邮件域名务必配置好 SPF/DKIM/DMARC。
  • 若性能至关重要,善用 Anycast 解析器与 DNS 预取。

这些要点大多可以归纳为「提前准备」和「多角度审视」。DNS 是一种平时悄无声息地运转良好、一旦出问题就会闹得很大的基础设施,所以预防性的习惯,远比事后补救更有价值。

结语

DNS 是互联网上最不起眼、却也最根本的基础设施。在我们随手敲下的一个域名背后,层层叠叠地堆着委派的层级结构、精细的缓存、Anycast 路由、地域化,以及安全签名。正因为它们默默地运转良好,我们通常才会忘记它们的存在。

2026 年的免费 DNS 潮流表明,这套古老的基础设施仍在持续演进。Anycast 变得更加密集,隐私技术日趋成熟,准入门槛也在降低。但这份便利的背后,始终存在着权衡:性能与灵活性、隐私与控制、中心化与韧性。把一个名字变成 IP 的那短短一瞬间,其实正站在互联网设计中最精妙的平衡点上。

下次在浏览器里敲下地址时,不妨花一秒钟,想想它背后默默运转的这台庞大机器。

参考资料

현재 단락 (1/216)

2026 年上半年,GeekNews 和 Hacker News 上 DNS 再次成为话题。起因是一家 CDN 厂商宣布将自家的 Anycast DNS 服务免费开放。开发者们一边发出「DNS 都免费...

작성 글자: 0자원문 글자: 9,959자작성 단락: 0/216