本文目录
准备：确认记录类型与目标
在开始排查前，首先确认你修改的具体内容。DNS 记录各有用途：A 记录将域名映射到 IPv4 地址，AAAA 记录映射到 IPv6 地址，而 CNAME 记录则是一个域名的别名，指向另一个域名。混淆这些类型是“解析不生效”的常见原因。例如，如果你希望将 www.example.com 指向一个 IP 地址，却错误地创建了一个指向另一个域名的 CNAME 记录，而该目标域名本身没有 A 记录，解析就会失败。
- 操作： 登录你的 DNS 提供商控制台，找到你修改的具体记录（例如
example.com的 A 记录）。 - 验证： 记录具体的值（IP 地址或目标域名）以及 TTL（生存时间）设置。如果你使用 Cloudflare，可以参考其DNS 记录类型文档，确保记录类型符合你的意图。
第一步：验证权威 DNS 记录是否已更新
第一个故障点通常是更改尚未同步到权威名称服务器。权威名称服务器是域名 DNS 数据的最终来源。如果这些服务器上的记录不存在或错误，任何递归解析器都不会返回新值。
- 操作： 使用
dig命令直接查询权威名称服务器，以绕过本地和 ISP 缓存。
bash dig +short example.com A @ns1.your-dns-provider.com 将 ns1.your-dns-provider.com` 替换为你域名 WHOIS 或 DNS 提供商设置中列出的实际名称服务器。
- 验证： 输出应显示新的 IP 地址。如果显示旧 IP 或无返回，说明更改未保存或未同步到权威服务器。检查记录名称或值是否有拼写错误。根据 MDN 的 DNS 术语表，DNS 层级依赖权威服务器为其区域提供确定性答案。如果权威服务器正确，问题则位于下游。
第二步：检查递归解析结果与 TTL 影响
如果权威记录正确，下一层是递归解析器（通常是你的 ISP DNS 服务器或公共解析器如 8.8.8.8）。递归解析器会缓存 DNS 响应以提高性能。TTL 决定了解析器在必须再次查询权威服务器之前可以缓存记录多长时间。
- 操作： 查询公共递归解析器，查看其返回的结果。
bash dig +short example.com A @8.8.8.8
- 验证： 将结果与权威查询结果进行比较。
如果公共解析器返回旧 IP，说明记录可能仍被缓存。检查旧记录的 TTL。如果 TTL 较高（例如 86400 秒/24 小时），全球传播可能需要长达该时长的时间。 如果公共解析器返回新 IP，问题可能仅存在于你的本地机器或网络中。
第三步：清除本地与网络缓存
即使互联网看到了新记录，你的计算机可能仍在使用缓存版本。操作系统维护本地 DNS 缓存以加速重复查找。
- 操作： 刷新操作系统的本地 DNS 缓存。
Windows： 以管理员身份打开命令提示符，运行 `ipconfig /flushdns`。 macOS： 运行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。 Linux：* 重启 systemd-resolved 服务或使用 resolvectl flush-caches。
- 验证： 刷新后，在机器上运行
ping example.com或nslookup example.com。如果现在解析到新 IP，问题就是本地缓存。如果仍解析到旧 IP，检查路由器或 ISP 是否缓存了记录。联系 ISP 刷新其递归缓存可能是必要的，尽管在现代公共解析器中这种情况较少见。
第四步：验证源站可达性与端口状态
如果 DNS 解析到正确的 IP 但网站仍无法访问，问题可能不在 DNS，而在源站服务器。服务器可能宕机，或 Web 服务（HTTP/HTTPS）未在预期端口上监听。
- 操作： 测试到 IP 地址 80（HTTP）和 443（HTTPS）端口的连通性。
bash curl -I http://<new-ip-address> curl -I https://<new-ip-address> 或使用 telnet <new-ip-address> 80` 检查端口是否开放。
- 验证：
如果 `curl` 返回 HTTP 响应（例如 `HTTP/1.1 200 OK`），服务器可达且正在提供内容。问题可能是防火墙阻止了你的 IP 或反向代理配置错误。 如果连接超时或被拒绝，服务器可能宕机，或防火墙阻止了端口。这是应用层或网络层问题，而非 DNS 记录问题。
风险与回退：常见陷阱与应急处理
几个常见错误可能导致持续的解析问题：
- CNAME 扁平化问题： 某些 DNS 提供商不支持在区域顶点（例如
example.com）使用 CNAME 记录。如果你尝试为根域名创建 CNAME，可能会失败或导致解析错误。请使用 A 记录或 AAAA 记录作为根域名，或使用支持 CNAME 扁平化的服务（如 Cloudflare 代理）。 - DNSSEC 验证失败： 如果启用了 DNSSEC，公钥和签名之间的不匹配会导致解析器拒绝记录。检查 DNS 提供商控制台中 DNSSEC 的状态。如果你最近更改了记录，确保 DNSSEC 签名已更新。
- 传播延迟： 即使 TTL 较低，由于 DNS 的分布式性质，全球传播也需要时间。如果某些网络正常而其他网络不正常，不要立即假设更改已损坏。
回退策略： 如果由于 DNS 更改导致网站宕机，立即将记录恢复到上一个已知良好的值。大多数 DNS 提供商允许你将记录编辑回旧的 IP 或目标。使用 dig 监控解析，以确认回退已生效。如果回退后问题仍然存在，问题可能出在源站服务器或更广泛的网络问题上，而不是 DNS 记录本身。
验证记录类型与语法参考
当 DNS 更新失败时，记录类型不匹配或格式错误往往是罪魁祸首。在排查递归解析器之前，请参考官方的 Cloudflare DNS 记录类型参考，以确保您的配置符合支持的规范。
验证记录类型与解析器行为
当 DNS 更改似乎没有生效时，第一步是确认您修改的具体记录类型是否与应用程序使用的协议相匹配。例如，将 A 记录切换为 AAAA 记录将无法解析 IPv4 流量，且 CNAME 记录不能与同一主机名下的其他记录共存。您可以参考 Cloudflare DNS 记录类型参考 来验证每种记录类型的精确语法和支持字段。该文档阐明了不同记录类型如何与解析过程交互，有助于您区分是记录配置错误还是缓存问题。如果您对 A、AAAA 和 CNAME 记录之间的基本差异仍不确定，回顾 域名解析实操指南 可以为理解这些记录在实际环境中的功能提供实用基础。
资料来源
下一步
按当前任务继续，不必一次读完所有内容。