子域名解析：出现异常时怎样确定影响范围
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /98adc44c2a99.html
📄
子域名解析：出现异常时怎样确定影响范围
子域名解析异常时，确定影响范围的核心方法是：先在本地分别用权威DNS与公共DNS查询同一子域名，再对比不同网络、不同地区、不同记录类型的结果，从而判断是单台设备、单个网络、单个解析器，还是整个子域名 zone 的问题。范围越小，越可能是本地缓存或运营商递归问题；范围越大，越可能是权威记录、NS 委派或权威服务器故障。
先看一个假设例子
假设你负责 shop.example.com，同事反馈“打不开”。此时不要直接改解析。先做三件事：一，用 nslookup shop.example.com 8.8.8.8 和 nslookup shop.example.com 1.1.1.1 查询公共解析器；二，用 nslookup shop.example.com 查本机默认解析器；三，用 dig shop.example.com A 与 dig shop.example.com AAAA 分别查 A 和 AAAA 记录。若公共解析器都返回正确 IP，而本机默认解析器返回旧 IP 或 NXDOMAIN，影响范围大概率是本地缓存或内网 DNS，不是权威记录整体失效。
用分层查询缩小范围
判断影响范围时，建议按“本机 → 本地递归 → 公共递归 → 权威”的顺序逐层查。每一步都记录返回状态、IP 和 TTL。常见错误是只查一次就下结论，或把浏览器报错直接当成 DNS 故障。浏览器报错可能来自代理、HTTPS 证书、页面资源加载，不能单独证明解析异常。
- 本机层：检查 hosts 文件、系统 DNS 缓存、VPN 或代理设置。若只有一台设备异常，优先怀疑本机。
- 本地递归层：换一个同网络设备查询。若同网络多台设备都异常，范围可能在该递归解析器或出口网络。
- 公共递归层：用两个以上公共解析器查询。若结果一致且正确，权威侧大概率正常。
- 权威层：直接向该子域名所属区域的 NS 查询，例如
dig @ns1.example.com shop.example.com A。若权威返回异常，影响范围是使用该权威的所有解析器。
区分记录类型与委派问题
同一子域名可能同时存在 A、AAAA、CNAME、MX、TXT 等记录，异常不一定影响所有类型。例如 A 记录正常但 AAAA 记录指向已下线地址，只影响优先使用 IPv6 的访问者。又如子域名委派给独立 NS 后，父域 NS 与子域 NS 不一致，可能造成部分解析器查不到记录。判断时要把“记录值错误”和“委派链断裂”分开：前者通常只影响该记录类型，后者可能影响整个子域名下的所有记录。
检查缓存与 TTL 造成的假范围
TTL 会让旧记录在一段时间内继续被不同解析器返回。假设你把 api.example.com 从旧 IP 改为新 IP，TTL 为 3600 秒，那么修改后一小时内，部分递归解析器仍可能返回旧 IP。此时“异常范围”看起来忽大忽小，实际是缓存生效进度不同。判断方法是查询多个递归解析器并观察返回的 TTL 递减；若旧值 TTL 在下降，说明缓存正在过期，不必立即回滚。若权威本身仍返回旧值，则问题在发布流程，不在缓存。
时间有限时的处理顺序
人手有限时，按影响面从大到小排序：先确认权威 NS 是否可达、区域文件是否加载；再确认委派链是否一致；然后抽查两个公共解析器；最后才处理单设备缓存。这样能避免把大量时间花在个别用户环境上，却漏掉整个子域名不可解析的情况。每一步只记录可复核的结果：查询命令、解析器地址、返回状态、IP、TTL 和时间。下一步，选取一个异常样本和一个正常样本，分别向权威 NS 和两个公共解析器发起相同查询，把差异点作为首个修复目标。
