每个开发者都应该了解的 DNS 基础知识
你已经部署了应用程序,但用户报告无法访问。你的第一反应可能是检查服务器,但真正的罪魁祸首往往是 DNS。理解 DNS 基础知识不是可选项——它对于调试生产环境问题和理解 Web 应用程序如何真正到达用户至关重要。
本文涵盖 DNS 解析流程、常见记录类型、缓存行为以及影响性能和安全性的现代 DNS 发展。
核心要点
- DNS 解析涉及三层:存根解析器、递归解析器和权威域名服务器——故障可能发生在任何环节
- TTL 值决定传播时间;在迁移前降低它们,而不是在迁移过程中
- HTTPS 记录(SVCB)提供连接提示,实现更快、更安全的浏览器连接
- DNSSEC 验证记录的真实性,而 DoH/DoT/DoQ 加密查询——它们解决不同的问题
- 使用
dig或nslookup通过查询不同的解析器来调试 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 小时),那就是你最坏情况下的等待时间。
Discover how at OpenReplay.com.
现代 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 应该是你首先怀疑的对象之一——而不是最后一个。
常见问题
在终端中使用 dig 命令,例如 dig example.com A 检查 A 记录,或 dig example.com ANY 查看所有记录。你也可以指定解析器,如 dig @8.8.8.8 example.com 直接查询 Google 的 DNS。在 Windows 上,使用 nslookup example.com 代替。
DNS 更改看起来延迟是因为解析器根据其 TTL 值缓存记录。如果你之前的 TTL 是 3600 秒,解析器在该小时过去之前不会检查更新。为了加快未来的更改,在进行更新之前提前降低 TTL,然后在之后恢复它。
A 记录将主机名直接映射到 IP 地址。CNAME 创建一个别名,将一个主机名指向另一个主机名,然后解析为 IP。CNAME 对于指向外部服务的子域名很有用,但不能用于区域顶点,根域名需要 A 或 AAAA 记录。
DoH 加密 DNS 查询,防止网络观察者看到你解析哪些域名。对于最终用户隐私,这是有益的。然而,对于服务器应用程序,传统 DNS 通常就足够了,因为你的基础设施已经是已知的。当网络中间人的隐私对你的使用场景很重要时,考虑使用 DoH。
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
