DNS - 互联网的「电话簿」是如何运作的
在浏览器中输入 example.com，网站就会瞬间显示出来。然而，计算机通信使用的不是域名，而是 IP 地址（例如：93.184.216.34）。将域名转换为 IP 地址的系统就是 DNS（Domain Name System）。
DNS 由 Paul Mockapetris 于 1983 年在 RFC 882/883 中提出，取代了此前通过 HOSTS.TXT 文件手动管理的方式。当时的互联网只有几百台主机，由 SRI-NIC 管理的一个文本文件就能管理所有主机名。DNS 通过分布式系统解决了这一局限性，是互联网的核心基础技术。
从输入 URL 到页面显示的第一步，就是 DNS 进行的域名解析。
域名解析流程 - 四阶段查询
浏览器获取 www.example.com 的 IP 地址最多需要经过四个阶段的查询：
- 检查本地缓存：首先检查操作系统缓存，然后检查浏览器缓存。如果之前访问过该域名，在这里就能解析
- 向解析器（递归解析器）查询：如果缓存中没有，则向 ISP 或公共 DNS（如 Google 的 8.8.8.8、Cloudflare 的 1.1.1.1）的解析器发起查询
- 向根服务器查询：如果解析器缓存中也没有，则向根服务器询问「.com 的权威服务器在哪里」
- 向权威服务器查询：.com 的权威服务器回答「example.com 的权威服务器在这里」，最终 example.com 的权威服务器返回 IP 地址
这一系列处理通常在 20 至 120 毫秒内完成。如果命中缓存，则不到 1 毫秒。
递归查询与迭代查询
客户端（浏览器）向解析器发起的是「递归查询」。客户端委托解析器「给我最终答案」，由解析器代为执行所有查询。而解析器向根服务器和权威服务器发起的是「迭代查询」。各服务器只返回「我不知道，但你可以去问这里」的引用信息，不承担给出最终答案的责任。
DNS 缓存 - 速度与新鲜度的权衡
如果每次 DNS 查询都从根服务器开始逐级查找，互联网将无法正常使用。缓存支撑着 DNS 的性能。
每条 DNS 记录都设有 TTL（Time To Live），以秒为单位指定缓存的有效期。TTL 为 3600 意味着在 1 小时内复用缓存，过期后重新查询。
- TTL 较短（60-300 秒）：DNS 变更能快速生效。用于 CDN 和故障转移配置。但会增加向解析器的查询频率
- TTL 较长（3600-86400 秒）：减轻解析器负载，域名解析更快。但修改 DNS 记录后，在旧缓存过期之前不会生效
经常看到「DNS 传播」这种说法，但这在技术上是不准确的。DNS 的变更并非在「传播」，而是各解析器的缓存按照 TTL 过期后重新获取新记录。提前缩短 TTL 可以加快变更的生效速度。
根服务器 - 互联网的顶端
位于 DNS 层级结构顶端的是 13 组根服务器（A 至 M）。虽然常被误解为「13 台」，但实际上通过 Anycast 技术在全球分布了 1700 多个实例。
根服务器由 ICANN 统管，各根服务器由不同组织运营。A 由 Verisign 运营，B 由 USC-ISI 运营，J 由 Verisign 运营，K 由 RIPE NCC 运营，M 由 WIDE Project（以日本�的庆应义塾大学为中心）运营。
根服务器保存的信息其实很简单，只有「.com 对应这个权威服务器」「.jp 对应这个权威服务器」这样的顶级域名（TLD）委派信息。根区文件的大小仅约 2MB。
DNS 记录类型
DNS 有多种记录类型，各自存储不同的信息。
| 记录 | 用途 | 示例 |
|---|---|---|
| A | 域名 → IPv4 地址 | example.com → 93.184.216.34 |
| AAAA | 域名 → IPv6 地址 | example.com → 2606:2800:220:1:... |
| CNAME | 域名别名 | www.example.com → example.com |
| MX | 邮件服务器指定 | example.com → mail.example.com（优先级 10） |
| TXT | 文本信息（SPF、DKIM、域名验证） | "v=spf1 include:_spf.google.com ~all" |
| NS | 权威 DNS 服务器指定 | example.com → ns1.example.com |
| SOA | 区域管理信息（序列号、更新间隔） | 主 NS、管理员邮箱、序列号 |
TXT 记录本来是存储文本信息的通用记录，但现在广泛用于邮件认证（SPF、DKIM、DMARC）和域名所有权验证。Google Search Console 和 Let's Encrypt 的证书签发也使用 TXT 记录进行验证。另外，如 CNAME 记录示例中的 www.example.com，过去 URL 中加 www 是常见做法，但现在越来越多地被省略。为什么不输入 www 也能显示网站与 DNS 的配置密切相关。
DNS 的安全性与未来
DNS 在 1983 年设计之初并未考虑安全性。DNS 查询和响应以明文传输，ISP 或同一网络上的第三方可以窃听「你正在访问哪个域名」。
为解决这一问题，DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 应运而生。DoH 通过 HTTPS 加密 DNS 查询，使其与普通 Web 通信无法区分。DoT 在端口 853 上进行 TLS 加密。
此外，防止 DNS 响应被篡改的 DNSSEC（DNS Security Extensions）也很重要。DNSSEC 通过数字签名验证 DNS 响应的合法性，但即使在 .com 域名中普及率也仅约 3%。DNS 的脆弱性是直接关系到整个互联网安全的课题。
想确认自己使用的 DNS 服务器是否安全，可以在 IP 确认酱进行 DNS 泄漏测试。
想从基础学习 DNS 工作原理的读者，可以参考网络技术入门书籍。