跳转到内容
← 返回核心概念
系统与架构计算机科学 · 计算机网络约 19 分钟阅读

DNS：互联网的命名系统

DNS: The Internet's Naming System

1983 年之前，互联网上的所有计算机名字都记录在一个文件里：HOSTS.TXT。这个文件由斯坦福研究院（SRI）下属的网络信息中心（NIC，长期由 Elizabeth "Jake" Feinler 团队负责）手工维护，每周编译一两次新版本，所有主机用 FTP 从单一服务器 SRI-NIC 下载同步。当时 ARPANE…

DNS域名分布式系统网络安全

1983 年之前，互联网上的所有计算机名字都记录在一个文件里：HOSTS.TXT。这个文件由斯坦福研究院（SRI）下属的网络信息中心（NIC，长期由 Elizabeth "Jake" Feinler 团队负责）手工维护，每周编译一两次新版本，所有主机用 FTP 从单一服务器 SRI-NIC 下载同步。当时 ARPANET 上只有几百台主机，这勉强管用。

问题在于它不可扩展：每多一台主机，HOSTS.TXT 就多一行，而所有人都要回到同一台 SRI-NIC 拉取更新，更新流量比主机数量增长得更快。到 1983 年，规模已经让这种集中维护无法维持。

当时在 USC 信息科学研究所（USC ISI）的 Paul Mockapetris 设计了一个分布式、去中心化的命名系统来取代它，写进了 RFC 882 与 RFC 883（1983 年 11 月）。四年后，根据真实部署经验，这两份文档被 RFC 1034 与 RFC 1035（1987 年 11 月）取代，至今仍是 DNS 的核心规范。

这就是 DNS（Domain Name System，域名系统）。今天，它每天处理数以万亿计的查询，是互联网最关键的基础设施之一。

破除误解：DNS 不只是"把名字转成地址"

DNS 被简化描述为"把 google.com 翻译成 IP 地址"。这是真的，但只是它功能的一部分。DNS 同时存储： - 邮件服务器地址（MX 记录） - 文本记录（TXT 记录，用于域名验证和 SPF/DKIM 防伪） - 别名（CNAME 记录） - 服务发现（SRV 记录）

DNS 是一个分布式数据库，记录类型决定查询语义。把它看作互联网的"通用目录服务"更准确。

更进一步，DNS 已经成为互联网的流量调度层。同一个域名，权威服务器可以根据查询来源的地理位置、各数据中心的负载或健康状况，返回不同的 IP 地址——这正是 CDN（内容分发网络）和全局服务器负载均衡（GSLB）的工作原理。

Akamai、Cloudflare 这类服务把记录的 TTL 压到几十秒，就能近实时地把用户引导到最近、最健康的边缘节点，并在某个节点故障时快速切走流量。所以"把名字转成地址"这一步本身，已经承载了路由与调度的决策，远不止一本静态电话簿。

这套调度藏着一个技术暗面：权威服务器看到的查询来自递归解析器（你的 ISP 或公共 DNS），而不是你本人，它怎么知道你在哪？答案是 EDNS Client Subnet（RFC 7871，2016）——递归解析器转发查询时，附上用户 IP 的前几段（通常是 /24）。调度因此更准，代价是用户的部分地址被泄露给查询路径上的每一层，缓存命中率也因答案按网段分裂而下降。Google Public DNS 选择发送它，Cloudflare 的 1.1.1.1 则以隐私为由拒绝发送——同一份标准，两种工程伦理。

还有一个流传甚广的误读："DNS 只用 UDP。"普通查询确实走 UDP——一个包问、一个包回，没有握手开销——但应答过大被截断时会退回 TCP，主从权威服务器之间同步整个区域（区域传送，AXFR）也走 TCP。UDP 是性能选择，不是协议的全部。

核心：层级结构与分布式权威

DNS 的名字空间是一棵树：

               . (根，Root)
          /    |    \    \
        com   org   net   cn   ...
       /   \
   google  example
    /
  www
```

www.google.com. 是完整域名（末尾有个点代表根）。从右向左读：根 → com → google → www。

这棵树分布在全球数百万台 DNS 服务器上，每台服务器只负责自己那一部分（称为区域 Zone）： - 根服务器（Root Servers）：知道所有顶级域（.com, .org, .cn…）的名字服务器地址。全球共有 13 个根服务器逻辑地址（A~M），通过 Anycast 技术实际部署了超过 1900 个物理实例（截至 2025 年）。 - 顶级域服务器（TLD Servers）：负责 .com、.org 等顶级域内的记录。.com 由 VeriSign 运营。 - 权威服务器（Authoritative Servers）：由域名拥有者（如 Google）自己运营，存储该域名的实际记录。

为什么恰好是 13 个？这是一个被冻结的历史巧合。RFC 1035 规定 UDP 报文不超过 512 字节，而解析器启动时需要拿到全部根服务器的名字和地址——这份"启动清单"必须塞进一个 512 字节的应答里，装得下的上限就是 13 个。后来 EDNS（RFC 2671，1999；RFC 6891，2013）把 UDP 载荷上限放宽到 4096 字节，技术上早已可以列出更多根，但"13 个字母"已经硬编码在全球无数解析器和镜像软件里，改动成本远超收益，于是保留至今。

这 13 个字母由 12 家独立机构运营：Verisign 一家就运营 A 和 J 两个，其余包括南加州大学信息科学研究所（B）、Cogent（C）、NASA（E）、ISC（F）、美国国防部国防信息系统局（G）、美国陆军研究实验室（H）、瑞典 Netnod（I）、荷兰 RIPE NCC（K）、日本 WIDE 项目（M）等。没有任何单一机构控制整个根——这是刻意的架构决策，不是自然演化的结果。

DNS 解析过程：递归与迭代

当你访问 www.example.com，发生了什么？

递归查询（最常见）：

你的设备 --> 本地解析器（通常是 ISP 或 8.8.8.8）
                --> 根服务器（"我不知道，但 .com 服务器在这里"）
                --> .com TLD 服务器（"我不知道，但 example.com 权威服务器在这里"）
                --> example.com 权威服务器（"www.example.com 的 A 记录是 93.184.216.34"）
本地解析器 --> 你的设备（返回 IP）
```

本地解析器代你完成所有跳转，你只等最终结果。每一层都有TTL（Time-to-Live）缓存：一旦查过，在 TTL 时间内直接返回缓存，不再查询。热门域名的 TTL 通常几分钟到几小时，大幅减少全球 DNS 查询量。

缓存让根服务器和 TLD 服务器只承受很小一部分流量：绝大多数查询在解析器或操作系统本地缓存就被命中，根本到不了上层。连"查不到"也会被缓存——RFC 2308（1998）定义的负缓存（Negative Caching）让解析器按权威应答里 SOA 记录的字段，把 NXDOMAIN（域名不存在）的结果缓存一段时间，避免对不存在的名字反复回源。

上面的过程里其实有三种角色，常被混为一谈：你设备上的存根解析器（stub resolver）几乎不做功，只会把请求转给上游；ISP 或公共 DNS 的递归解析器替你跑完全程；根、TLD、权威三层则只做迭代应答——从不替别人查询，只回答"下一站在哪"。递归解析器是整个体系里唯一干重活的，也因此成为缓存投毒的首要目标。

层级委托还藏着一个鸡生蛋问题：如果 example.com 的权威服务器叫 ns1.example.com，要查 example.com 得先问 ns1.example.com，可它的地址又得先解析 example.com——死循环。解法是胶水记录（glue record）：上级区域（.com）在做委托时，直接附上下级名字服务器的 IP 地址，从体系外面打破循环。

关键记录类型

记录类型含义示例
AIPv4 地址www.example.com -> 93.184.216.34
AAAAIPv6 地址www.example.com -> 2606:2800:220:1:...
CNAME别名（规范名）blog.example.com -> example.com
MX邮件服务器example.com -> mail.example.com (优先级 10)
TXT任意文本SPF、DKIM、域名所有权验证
NS该区域的权威服务器example.com -> ns1.example.com
PTR反向 DNS（IP → 域名）34.216.184.93.in-addr.arpa -> www.example.com
SOA区域起始记录（权威信息）包含区域主服务器、管理员邮箱、序列号

DNS 的安全问题

DNS 在 1983 年设计时几乎没有考虑安全性——数据以明文 UDP 传输，没有认证机制。这带来了几类攻击：

DNS 缓存投毒（Cache Poisoning）：攻击者伪造 DNS 响应，在解析器缓存中写入假记录，让用户访问钓鱼网站。要让伪造的应答被接受，攻击者只需猜中 16 位的事务 ID——只有 65536 种可能，可以暴力猜测。

2008 年，安全研究员 Dan Kaminsky 发现可以绕过 TTL 限制、极高效地完成这种猜测（即 CVE-2008-1447），引发了互联网史上最大规模的协调漏洞修复行动：微软、ISC（BIND）、Cisco、Sun 等厂商在 2008 年 7 月 8 日同步发布补丁。

补丁的核心是源端口随机化——把发起查询的 UDP 源端口也当作一个随机标识，与事务 ID 一起把熵从约 6.5 万提升到数十亿（这一思路 Dan Bernstein 早在 1999 年就提出过）。漏洞细节于 7 月 21 日提前泄露，Kaminsky 随后在 8 月的 Black Hat 大会上完整公开。

DNSSEC（DNS Security Extensions，RFC 4033/4034/4035，2005）：为 DNS 响应添加数字签名，让解析器能沿信任链验证数据是否来自真正的权威服务器、是否被篡改。根区域直到 2010 年 7 月才完成签名，提供了全球统一的信任锚；.com 更是迟至 2011 年 3 月才签名。DNSSEC 不加密数据，仅做完整性验证，且部署极其缓慢——复杂性高、运营成本高、错误容忍度低（一个签名过期就可能让整个域名解析失败）。

信任链最顶端的那把钥匙——根区 KSK（密钥签名密钥）——启用八年后的第一次更换发生在 2018 年 10 月 11 日。这次"换锁"原定 2017 年进行，ICANN 的遥测却发现相当数量的解析器还没有跟进新钥匙；贸然切换意味着这些解析器身后的用户会全网失联，于是整个计划推迟了整整一年。换一把密码学钥匙，需要提前一年向全世界打招呼——这就是全球信任锚的运维重量。

DNS over HTTPS（DoH，RFC 8484，2018）和 DNS over TLS（DoT，RFC 7858，2016）：把 DNS 查询加密，防止 ISP 或网络监听者看到你查询了哪些域名。两者的关键差别在端口：DoT 走独立的 853 端口，网络管理员一眼能认出并按需阻断；DoH 则把查询藏进 443 端口的普通 HTTPS 流量里，与网页浏览混在一起，难以被单独识别和封锁。浏览器已开始内置 DoH 支持，绕过 ISP 的 DNS 服务器——这引发了 ISP 和网络安全社区的争议：DoH 破坏了企业网络的 DNS 过滤机制，也让 ISP 无法监控 DNS 以应对法律义务。2022 年，第三个选择加入战局：基于 QUIC 的 DoQ（RFC 9250），在加密之外继承了 QUIC 的低握手延迟和连接迁移，目前主要由公共解析器和移动端先行部署。

DNS 作为攻击工具： - DNS 放大攻击：向开放 DNS 解析器发送伪造来源 IP 的小查询，触发大响应发送到受害者，流量放大比可达 50-100 倍。 - 快速变化（Fast Flux）：恶意软件域名频繁更换 IP，每次 TTL 极短，让黑名单失效。 - DNS 隧道（DNS Tunneling）：把数据编码进查询名和 TXT 记录，DNS 就成了一条隐蔽信道——恶意软件用它接收指令、外泄数据，它也能在收费 Wi-Fi 的强制门户下"合法"偷出网络访问。因为几乎没有防火墙敢拦 DNS，检测只能靠查询频率、域名长度这类统计特征。

DNS 作为单点故障：很多公司把权威 DNS 托管给第三方服务商，这让服务商本身成了诱人的攻击目标。2016 年 10 月 21 日，约 10 万台被 Mirai 僵尸网络感染的物联网设备（摄像头、路由器、录像机等）分三波向托管 DNS 服务商 Dyn 发起 DDoS，峰值流量约 1.2 Tbps。

由于 Twitter、Netflix、Reddit、Spotify、GitHub、PayPal 等大量站点都依赖 Dyn 解析域名，它们在美国东海岸和欧洲数小时内时断时续——即便这些站点自己的源服务器完好无损，用户也因为解析不出 IP 而打不开。这次事件说明：DNS 这层依赖一旦集中，就会成为整个互联网的单点故障。事后复盘直接改变了一个行业惯例：关键业务不再把权威解析押在单一服务商身上，跨厂商的双权威配置从此成为大型站点的标配。

代价与争议

中心化风险：DNS 根服务器虽然分布广泛，但根区域的签名密钥由 ICANN 控制。这使得某种程度的"互联网控制权"集中在一个非政府国际组织中。这把钥匙的使用有一套公开的"钥匙仪式"（key ceremony）：定期在摄像头与见证人监督下，由来自全球社区的持钥人依次操作硬件安全模块完成签名，全程录像可审计。多个国家（中国、俄罗斯）已建立国家 DNS 基础设施，能在极端情况下与全球 DNS 断开独立运行。

内容管制的工具：ISP 和政府经常用 DNS 阻断来实现内容管制（将被封锁域名解析到 127.0.0.1 或不返回）。这推动了 DoH 的采用，也引发了关于谁应该控制 DNS 解析的政策辩论。

名字空间的膨胀：2012 年起 ICANN 开放新顶级域申请，一千多个新后缀（.app、.dev、.zip……）陆续入根。2023 年 .zip 和 .mov 开放注册时，安全社区担心它们与文件名后缀混淆会助长钓鱼——一段写着 report.zip 的文本，可能是文件，也可能是网址。

Anycast 与弹性：13 个根服务器"地址"背后实际上有 1900+ 个物理节点，使用 Anycast 路由：你的请求被路由到地理上最近的实例。这让根服务器几乎不可能被 DDoS 打下去。

2002 年 10 月 21 日的攻击中，13 个根有 9 个性能受损，但因为部署了包过滤、对普通用户几乎没有影响。2007 年 2 月 6 日的攻击规模更大、持续约 24 小时，结果只有当时仍用单播（未上 Anycast）的两台根（G、L）明显吃力，已上 Anycast 的根则把流量分摊到各地实例、平稳扛住——这是 Anycast 韧性的一次真实压力测试。

跨域连接

  • 负载均衡：把调度决策塞进名字解析，是最省事的全局负载均衡：同一个域名按来源位置与节点健康返回不同地址。代价写在缓存里——切换速度的上限就是生存时间，而客户端与中间解析器是否守规矩，运营方并不能控制。推论是：故障切换的实际时长，取决于最不听话的那一级缓存。
  • 克里普克：名字的指称靠一条从命名到当前使用的传递链维持。安全扩展把这条链做成可机器验证的形式：从根开始逐级签名，任何一环断裂整条链失效。可检验推论：一个签名过期就足以让整个域名不可解析，容错余地极小。
  • 言论自由：解析阻断是最廉价的内容管制手段——不必看内容，拦住名字即可。加密查询正是针对这条杠杆，把它藏进普通网页流量里；代价对称：企业与校园网络也同时失去了那个统一的过滤与审计点。推论是：这场争论的实质不是加密好不好，而是那个观测点该归谁。
  • 垄断与寡头：权威解析托管的规模经济导致高度集中，于是单一服务商故障能同时切断大批互不相关站点的可达性——即便这些站点的服务器完好无损。效率与故障域大小同向增长，是集中化无法回避的内生代价。
  • 生命之树与系统发生：双名法与域名同样用层级把"全局唯一"分解为"每级本地唯一"，也同样要回答谁有权命名。可检验推论：一旦同层出现两个自认权威的机构，冲突在层内无解，只能上诉到更高一级——分歧最终总是关于委派。同理，根区密钥掌握在谁手里，就是这套体系里最上层的委派问题。

参考文献

  • Mockapetris, P. Domain Names — Concepts and Facilities. RFC 1034, IETF, 1987.
  • Mockapetris, P. Domain Names — Implementation and Specification. RFC 1035, IETF, 1987.
  • Andrews, M. Negative Caching of DNS Queries (DNS NCACHE). RFC 2308, IETF, 1998.
  • Arends, R. et al. DNS Security Introduction and Requirements. RFC 4033（及 4034、4035），IETF, 2005.
  • Hu, Z. et al. Specification for DNS over Transport Layer Security (TLS). RFC 7858, IETF, 2016.
  • Hoffman, P. & McManus, P. DNS Queries over HTTPS (DoH). RFC 8484, IETF, 2018.
  • Kaminsky, D. It's the End of the Cache As We Know It. Black Hat USA, 2008.（漏洞编号 CVE-2008-1447）
  • Huitema, C., Dickinson, S. & Mankin, A. Specification of DNS over Dedicated QUIC Connections. RFC 9250, IETF, 2022.
  • ICANN. Factsheet: Root Server Attack on 6 February 2007. ICANN, 2007.
  • ICANN. Review of the 2018 DNSSEC KSK Rollover. ICANN, 2019.（首次根区密钥更换的复盘报告）

延伸阅读

  • Albitz, P. & Liu, C. DNS and BIND. 5th ed. O'Reilly, 2006.

正文中引用本条 · 3 · 其中 1 条来自其他领域

政治学主权