DNS 是什么以及它是如何工作的？

DNS（域名系统）是互联网的分布式命名基础设施，它将人类可读的域名（如 example.com）转换为机器可读的 IP 地址（如 93.184.216.34）。没有 DNS，每次浏览器请求、API 调用和电子邮件投递都需要用户和应用程序知道每台远程主机的确切数字地址，这将使现代互联网在规模上无法运行。

DNS 的核心是一个全球分布式的层次化数据库。它不是单一的服务器或集中式注册表——它是一棵跨越全球数十万台权威名称服务器的委托树，通过一小组根服务器进行协调，并受 RFC 1034 和 RFC 1035 中定义的标准约束。

为什么 DNS 不仅仅是一本”电话簿”

电话簿的类比对初学者很有用，但它大大低估了 DNS 的实际功能。DNS 是一个实时、容错、全球复制的查找系统，还处理以下事务：

• 邮件路由：通过 MX 记录，将电子邮件引导至正确的邮件服务器
• 服务发现：通过 SRV 记录，供 SIP、XMPP 和 Kubernetes 内部网络等协议使用
• 域名所有权验证：通过 TXT 记录，用于 SPF、DKIM、DMARC 和 Google Search Console
• 规范命名：通过 CNAME 记录，实现 CDN 集成和负载均衡
• IPv6 地址：通过 AAAA 记录
• 反向查找：通过 in-addr.arpa 区域中的 PTR 记录，对邮件服务器信誉和安全审计至关重要
• DNSSEC 验证：为 DNS 响应添加加密签名以防止缓存投毒

每次发送电子邮件、连接 VPN 或加载 Web 应用程序时，DNS 都在后台解析多种记录类型——每次页面加载通常需要数十次查询。

DNS 层次结构：命名空间的组织方式

DNS 被组织为一棵倒置的树。理解这一结构对于理解解析工作原理至关重要。

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• 根区域（.）：由 IANA 管理。共有 13 个逻辑根服务器地址（A 至 M），由 Verisign、NASA 和 ICANN 等组织运营。实际上，这些服务器通过任播路由由数百台物理机器提供服务。
• 顶级域（TLD）：通用 TLD，如 .com、.net、.org，以及国家代码 TLD，如 .uk、.de、.md。每个 TLD 都有自己的权威名称服务器集合。
• 二级域（SLD）：您注册的域名——example.com。该区域的权威 DNS 由域名注册者控制。
• 子域：www、mail、api、staging——这些是 SLD 区域内的记录，完全由域名所有者控制。

逐步解析：DNS 查询的解析过程

完整的递归 DNS 解析涉及最多七个不同的网络交换。以下是精确的步骤序列：

第 1 步——浏览器缓存检查

当您在浏览器中输入 www.example.com 时，操作系统首先检查其本地 DNS 缓存。在 Linux 上，这可能由 systemd-resolved 管理；在 Windows 上，由 DNS 客户端服务管理。如果存在有效的缓存记录且其 TTL（生存时间）尚未过期，解析在此终止。

您可以在 Linux 上使用以下命令检查本地 DNS 缓存：

resolvectl statistics

或使用以下命令刷新缓存：

sudo resolvectl flush-caches

在 Windows 上：

ipconfig /displaydns
ipconfig /flushdns

第 2 步——递归解析器查询

如果没有缓存答案，操作系统将查询转发给已配置的递归解析器（也称为递归 DNS 服务器或全服务解析器）。通常为：

• 您的 ISP 解析器（通过 DHCP 分配）
• 公共解析器：8.8.8.8（Google）、1.1.1.1（Cloudflare）、9.9.9.9（Quad9）
• 在您自己的 VPS 托管基础设施上自托管的解析器，如 Unbound 或 BIND

递归解析器承担繁重的工作。它将代表您遍历 DNS 层次结构，并缓存结果以更快地响应未来的查询。

第 3 步——根服务器转介

递归解析器查询 13 个根服务器集群之一。根服务器不知道 www.example.com 的 IP 地址。相反，它返回一个转介——.com TLD 区域的权威名称服务器列表及其 IP 地址（称为粘合记录）。

第 4 步——TLD 名称服务器查询

解析器查询 .com TLD 名称服务器（由 Verisign 运营）。这些服务器也不持有最终答案。它们返回另一个转介——专门针对 example.com 的权威名称服务器（例如 ns1.example.com、ns2.example.com）。

第 5 步——权威名称服务器查询

解析器查询 example.com 的权威名称服务器。该服务器持有实际的区域文件，并返回最终答案——包含 IPv4 地址的 A 记录（或 IPv6 的 AAAA）。

第 6 步——响应缓存与传递

递归解析器根据记录的 TTL 值缓存响应（例如 300 秒 = 5 分钟，86400 秒 = 24 小时）。然后将 IP 地址返回给客户端操作系统，再传递给浏览器。

第 7 步——TCP/IP 连接

浏览器使用解析得到的 IP 地址建立 TCP 连接（通常在 HTTPS 的 443 端口上）。DNS 的工作至此完成。Web 服务器响应，页面加载完毕。

整个过程——第 2 步至第 6 步——在解析器缓存热的情况下通常在 20–120 毫秒内完成，对于遍历所有层次级别的完全冷、未缓存解析，则在 500 毫秒以内。

DNS 记录类型：技术参考

CAA 记录值得特别关注：它们指示证书颁发机构哪些组织被允许为您的域名颁发 SSL 证书——这是一项经常被忽视的关键安全控制措施。

DNS 查询类型：递归、迭代与非递归

大多数终端用户设备向其配置的解析器发送递归查询。解析器本身在遍历层次结构时使用迭代查询。

TTL：最容易被误解的 DNS 参数

TTL（生存时间）是 DNS 记录可被解析器和客户端缓存的秒数。它由域名所有者在区域文件中设置。

• 低 TTL（60–300 秒）：更快传播变更。在计划迁移、IP 变更或故障转移事件之前至关重要。会增加权威服务器的查询负载。
• 高 TTL（3600–86400 秒）：减少解析器负载并加速重复查询。变更传播到全球需要更长时间。

关键操作建议：在计划服务器迁移或 IP 变更时，至少在变更前 48 小时将 TTL 降低至 300 秒。这样可以确保在更新 A 记录时，没有解析器会将旧值缓存超过 5 分钟。未能做到这一点是迁移过程中导致长时间停机的最常见原因之一。

当您通过 域名注册注册域名并将其指向新服务器时，传播窗口直接由之前的 TTL 值决定——而非通常被错误引用的”24–48 小时”规则。

DNS 传输协议：UDP、TCP、DoH 和 DoT

传统 DNS 对 512 字节以下的查询使用 UDP 53 端口。超过此大小的响应会触发回退至 TCP 53 端口。DNSSEC 响应、区域传输（AXFR）和大型 TXT 记录通常需要 TCP。

现代 DNS 隐私协议显著改变了这一格局：

DoH 与 DoT 的实际操作差异：DoH 将 DNS 封装在 443 端口的 HTTPS 流量中，使其与普通 Web 流量无法区分。这对隐私有益，但使企业网络监控和过滤变得更加困难。DoT 使用专用端口（853），网络管理员可以独立监控、阻止或检查。对于在独立服务器上自管理的基础设施，运行本地 DoT 或 DoH 解析器可同时提供隐私保护和对解析策略的完全控制。

DNSSEC：DNS 的加密完整性

DNSSEC（DNS 安全扩展）为 DNS 响应添加加密签名链，允许解析器验证响应的真实性以及在传输过程中未被篡改。它可防范 DNS 缓存投毒（Kaminsky 攻击）和中间人 DNS 欺骗。

DNSSEC 不加密 DNS 流量——它只对其进行签名。签名链的工作原理如下：

1. 区域所有者生成区域签名密钥（ZSK）和密钥签名密钥（KSK）
2. 每个 DNS 记录集使用 ZSK 签名，生成 RRSIG 记录
3. KSK 对 DNSKEY 记录集进行签名
4. 在父区域（例如 .com）中发布 DS（委托签名者）记录，建立回溯至根的信任链

强烈建议为任何处理金融交易、身份验证或电子邮件的域名启用 DNSSEC。配置错误的 DNSSEC——尤其是过期的签名或不匹配的 DS 记录——将导致验证解析器完全解析失败，这比完全没有 DNSSEC 更难处理。

常见 DNS 故障及诊断方法

NXDOMAIN——域名不存在

权威服务器确认该域名不存在。常见原因：域名拼写错误、域名注册过期、DNS 记录被删除。

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL——服务器故障

解析器无法完成查询。常见原因：DNSSEC 验证失败、权威服务器无法访问、区域文件配置错误。

dig +dnssec example.com
# Look for: status: SERVFAIL

要绕过 DNSSEC 验证并隔离问题：

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

过期缓存 / 传播延迟

更新 DNS 记录后，旧值将在解析器缓存中持续存在，直到 TTL 过期。要直接查询权威服务器并绕过解析器缓存：

dig @ns1.example.com www.example.com

全球 DNS 传播检查

使用 dig 配合特定公共解析器检查传播状态：

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

托管环境中的 DNS：实用配置

当您在 带 cPanel 的 VPS 上部署网站或应用程序时，DNS 管理通常通过 WHM 的 DNS 集群或 cPanel 的区域编辑器处理。了解底层区域文件结构可让您进行 GUI 未公开的更改。

example.com 的最小区域文件如下所示：

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

要使电子邮件托管正常运行，MX 记录必须指向主机名（而非直接指向 IP 地址），且该主机名本身必须通过 A 记录解析。常见的配置错误是将 MX 直接指向 IP——这违反了 RFC 2821，并会导致严格邮件服务器的投递失败。

DNS 性能：真正影响解析速度的因素

• 解析器距离：地理上靠近客户端（或在同一网络上）的解析器可显著减少往返时间。
• 缓存命中率：具有合理 TTL 的高流量域名几乎总是从缓存中提供服务。冷缓存解析慢 5–20 倍。
• 任播路由：根服务器和主要公共解析器使用任播，自动将查询路由到最近的物理节点。
• 每页 DNS 查询数：单个网页可触发 20–50 次 DNS 查询（CDN 资产、分析、字体、广告网络）。浏览器并行处理这些查询，但每个唯一主机名都需要自己的查找。
• DNS 预取：现代浏览器支持 <link rel="dns-prefetch" href="//cdn.example.com">，在需要之前解析第三方主机名，从而降低感知延迟。

DNS 与替代解析机制

/etc/hosts 文件在几乎所有操作系统上都在 DNS 之前被评估。这使其对本地开发非常有价值——您可以将 myapp.local 映射到 127.0.0.1，而无需接触任何 DNS 基础设施。

关键要点与决策清单

在为任何生产环境配置或排查 DNS 问题时，请使用此清单：

• 在任何服务器迁移之前：至少提前 48 小时将 TTL 降低至 300 秒
• 为确保电子邮件送达率：验证 MX、SPF（TXT）、DKIM（TXT）、DMARC（TXT）和 PTR 记录均已正确配置
• 为确保安全：在您的域名上启用 DNSSEC，并添加 CAA 记录以限制证书颁发
• 为确保隐私：在客户端设备和服务器上使用 DoT 或 DoH；避免在不受信任的网络上发送明文 DNS
• 为确保性能：对稳定记录将 TTL 设置为 3600–86400；仅对频繁变更的记录使用 300
• 为进行诊断：始终使用 dig @ns1.yourdomain.com 直接查询权威服务器，以区分传播延迟和真正的配置错误
• 为进行区域管理：每次修改区域文件时递增 SOA 序列号——解析器使用它来检测变更
• 为进行托管：确认注册商的名称服务器委托与区域文件中的 NS 记录匹配——不匹配是域名转移后”DNS 不工作”最常见的原因

常见问题

DNS 解析器与权威 DNS 服务器有什么区别？

递归解析器（例如 8.8.8.8）是代表您的设备查询 DNS 层次结构并缓存结果的中间人。权威名称服务器持有特定域名的实际区域记录，并提供最终答案。您的解析器查询许多权威服务器；您域名的权威服务器只回答其托管区域的查询。

为什么更新记录后 DNS 传播需要时间？

传播延迟是由基于 TTL 的缓存引起的。之前缓存了您旧记录的每个解析器将继续提供该记录，直到 TTL 过期。如果您的 TTL 是 86400（24 小时），解析器可能在您更新后最多 24 小时内仍提供旧记录。这不是错误——这是使 DNS 可扩展的预期缓存机制。

什么是 DNS 泄漏，为什么它很重要？

DNS 泄漏发生在您的设备将 DNS 查询发送到预期解析器之外——通常是您的 ISP 解析器——即使在使用 VPN 或隐私工具时也是如此。这会将您的浏览活动暴露给您的 ISP。您可以在 dnsleaktest.com 测试泄漏，并通过配置 VPN 客户端强制通过其自己的解析器路由 DNS 来修复它。

DNS 可以被用作攻击媒介吗？

可以。常见的基于 DNS 的攻击包括：缓存投毒（向解析器缓存注入虚假记录）、DNS 放大 DDoS（利用开放解析器向目标发送大量 DNS 响应）、DNS 劫持（将查询重定向到恶意服务器）以及 DNS 隧道（通过在 DNS 查询字符串中编码数据来窃取数据）。DNSSEC 可缓解缓存投毒；权威服务器上的速率限制和响应速率限制（RRL）可缓解放大攻击。

如何查找任意域名的权威名称服务器？

使用 dig，指定 NS 记录类型和 +short 标志以获得简洁输出：

dig NS example.com +short

要追踪从根到权威的完整委托路径，请使用：

dig +trace example.com

这显示了每个转介跳转——根 → TLD → 权威——这是诊断委托配置错误最可靠的方法。