每个开发者都应该了解的 DNS 基础知识

你已经部署了应用程序,但用户报告无法访问。你的第一反应可能是检查服务器,但真正的罪魁祸首往往是 DNS。理解 DNS 基础知识不是可选项——它对于调试生产环境问题和理解 Web 应用程序如何真正到达用户至关重要。

本文涵盖 DNS 解析流程、常见记录类型、缓存行为以及影响性能和安全性的现代 DNS 发展。

DNS 解析的工作原理

当浏览器需要连接到 api.example.com 时,它并不会神奇地知道 IP 地址。解析过程涉及三层:

存根解析器(Stub resolver):操作系统内置的 DNS 客户端。它本身不解析域名——而是将查询转发到配置的递归解析器,并在本地缓存响应。

递归解析器(Recursive resolver):通常由你的 ISP 或公共服务(如 Cloudflare(1.1.1.1)或 Google(8.8.8.8))运营。该服务器负责繁重的工作,代表你查询其他服务器。

权威域名服务器(Authoritative nameservers):域名 DNS 记录的权威来源。递归解析器会遍历 DNS 层次结构——根服务器、然后是顶级域服务器(.com、.io),最后是域名的权威服务器——以找到答案。

对于开发者来说,关键的认识是 DNS 故障可能发生在任何层。配置错误的存根解析器、无法访问的递归解析器或过时的权威记录都可能导致应用程序中断。

常见的 DNS 记录类型

你会经常遇到这些记录:

• A / AAAA:将主机名映射到 IPv4 或 IPv6 地址
• CNAME:将一个主机名别名到另一个主机名(不能用于区域顶点——example.com 本身需要 A 或 AAAA 记录)
• MX:指定域名的邮件服务器
• TXT:存储任意文本,通常用于域名验证和邮件身份验证(SPF、DKIM)
• NS:将区域委托给特定的域名服务器

理解这些记录有助于配置 CDN、邮件服务或调试子域名无法解析的问题。

DNS 缓存和 TTL

DNS 缓存和 TTL(生存时间)直接影响你的部署策略。每条 DNS 记录都包含一个以秒为单位的 TTL 值。一旦解析器缓存了记录,在 TTL 过期之前不会再次查询。

实际影响:

• 3600 秒(1 小时)的 TTL 意味着 DNS 更改最多需要一小时才能传播
• 在迁移之前提前降低 TTL——而不是在更改期间
• 浏览器和操作系统维护自己的缓存,增加了另一层

“DNS 传播需要 24-48 小时”的说法是误导性的。传播时间取决于之前的 TTL 值。如果你的旧 TTL 是 86400 秒(24 小时),那就是你最坏情况下的等待时间。

现代 DNS:HTTPS 记录和加密传输

近年来 DNS 有了显著发展。对 Web 开发者来说,有两个最重要的发展。

HTTPS DNS 记录(SVCB)

HTTPS 记录(一种特定类型的 SVCB 记录)在浏览器联系你的服务器之前就提供连接提示。它可以通告:

• HTTP/3 和 QUIC 支持
• 备用端口
• 加密客户端问候(ECH)密钥

这使浏览器能够建立更快、更安全的连接。然而,HTTPS 记录支持尚未普及——并非所有 DNS 提供商都支持它,一些解析器也不会查询它。

注意:HTTPS 记录提供有限的顶点别名功能,但它们不是完整的 CNAME-at-apex 解决方案。

DNS over HTTPS(DoH)和加密 DNS

传统的 DNS 查询通过 UDP 端口 53 以明文传输。DNS over HTTPS(DoH)、DNS over TLS(DoT)和 DNS over QUIC(DoQ)加密这些查询,防止窃听和篡改。

加密 DNS 现在已广泛部署——Firefox 和 Chrome 在许多配置中默认使用 DoH——但并非普遍适用。企业网络和一些 ISP 仍然拦截或阻止加密 DNS。

DNSSEC vs 加密:了解区别

一个常见的混淆:DNSSEC 不是加密。

DNSSEC 提供身份验证。它对 DNS 记录进行加密签名,以便解析器可以验证响应未被篡改。它不会隐藏你的查询。

加密 DNS(DoH/DoT/DoQ)提供隐私。它加密传输层,使观察者无法看到你正在查询哪些域名。

它们解决不同的问题,可以一起使用。

DNS 故障如何在应用程序中显现

当 DNS 失败时,你通常会看到:

• NXDOMAIN 错误(域名不存在)
• 连接超时(解析器无法访问)
• SERVFAIL 响应(上游服务器问题)

在浏览器中,这些显示为”DNS_PROBE_FINISHED_NXDOMAIN”或类似错误。在 Node.js 或其他运行时中,你会得到 ENOTFOUND 或等效异常。

使用 dig 或 nslookup 进行调试。查询不同的解析器以隔离问题是本地缓存、你的解析器还是权威服务器的问题。

结论

DNS 位于你的用户和服务器之间。理解解析流程、TTL 行为以及 HTTPS 记录和 DoH 等现代协议有助于你更可靠地部署和更快地调试。当出现问题时,DNS 应该是你首先怀疑的对象之一——而不是最后一个。

常见问题

如何检查我的域名设置了哪些 DNS 记录?

在终端中使用 dig 命令,例如 dig example.com A 检查 A 记录,或 dig example.com ANY 查看所有记录。你也可以指定解析器,如 dig @8.8.8.8 example.com 直接查询 Google 的 DNS。在 Windows 上,使用 nslookup example.com 代替。

为什么 DNS 更改需要时间传播?

DNS 更改看起来延迟是因为解析器根据其 TTL 值缓存记录。如果你之前的 TTL 是 3600 秒,解析器在该小时过去之前不会检查更新。为了加快未来的更改,在进行更新之前提前降低 TTL,然后在之后恢复它。

CNAME 和 A 记录有什么区别?

A 记录将主机名直接映射到 IP 地址。CNAME 创建一个别名,将一个主机名指向另一个主机名,然后解析为 IP。CNAME 对于指向外部服务的子域名很有用,但不能用于区域顶点,根域名需要 A 或 AAAA 记录。

我应该为我的应用程序使用 DNS over HTTPS 吗?

DoH 加密 DNS 查询,防止网络观察者看到你解析哪些域名。对于最终用户隐私,这是有益的。然而,对于服务器应用程序,传统 DNS 通常就足够了,因为你的基础设施已经是已知的。当网络中间人的隐私对你的使用场景很重要时,考虑使用 DoH。