子域名解析 - 用分层排查判断问题出在哪一层
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /123e351d68aa.html
📄
子域名解析 - 用分层排查判断问题出在哪一层
判断子域名解析问题属于哪一层，核心方法是按“解析记录是否生效→DNS服务器是否应答→递归解析是否拿到结果→网络连接与证书是否正常→应用层是否响应”的顺序逐层取证。假设一个例子：shop.example.com在浏览器中打不开，但主域example.com正常。不要急着改解析记录，先确定故障发生在哪一层，否则容易把应用问题误判为DNS问题。
先分清“解析层”和“访问层”
子域名解析只负责把主机名翻译成IP地址，它不负责端口是否开放、页面是否返回200、证书是否有效。判断时先看一个关键现象：如果ping shop.example.com能显示出IP，说明解析层大概率已经返回了结果；此时浏览器仍打不开，问题更可能在网络连接、证书或应用层。反过来，如果连IP都拿不到，才优先怀疑解析层。
常见错误是看到“无法访问此网站”就认定是DNS故障。浏览器报错文案经常把DNS失败、连接超时、证书错误混在一起显示，必须用命令行或DNS查询工具拿到具体返回码，才能定位层级。
按顺序执行的五步排查
- 查本地缓存与hosts文件。先确认本机没有写死
shop.example.com的旧IP。查看hosts文件并清空本地DNS缓存，再重新查询。这一步排除“只有你这台机器异常”的情况。 - 直接向权威DNS查询。用
dig shop.example.com @ns1.example.com或nslookup shop.example.com ns1.example.com，其中ns1.example.com替换为该子域名所属区域的权威服务器。如果权威服务器返回NXDOMAIN，说明记录不存在或区域配置有误，问题在解析配置层。 - 向公共递归解析器查询。用
dig shop.example.com @8.8.8.8或指定其他递归服务器。如果权威有记录、递归却没有，可能是缓存尚未过期或递归链路异常，问题在递归解析层。 - 检查返回记录类型与目标。确认返回的是A、AAAA还是CNAME，以及CNAME指向的目标是否真实存在。CNAME指向一个已删除的别名，是子域名解析中很常见的断点。
- 拿到IP后测试连接。用
curl -v https://shop.example.com观察是TCP连接失败、TLS握手失败还是HTTP返回错误码。能连上但返回5xx，问题已经不在解析层，而在源站或反向代理。
用返回结果对照故障层级
- NXDOMAIN：域名或记录不存在。优先检查子域名拼写、区域文件、记录是否被删除。
- SERVFAIL：权威服务器无法正常应答，可能是区域配置错误、DNSSEC校验失败或服务器故障。
- 返回了错误IP：记录值写错、CNAME指向了过期目标，或本地hosts覆盖了正确结果。
- 解析正确但连接超时：问题在防火墙、安全组、源站监听或网络链路，不属于解析层。
- 连接成功但证书报错：证书未覆盖该子域名，或证书链不完整，属于TLS配置层。
注意，返回码本身也可能有多个解释。例如SERVFAIL既可能是权威服务器问题，也可能是递归服务器到权威服务器的链路问题。要结合“直接问权威”和“问递归”两次结果对比，才能缩小范围，不要凭单一现象下结论。
容易误判的几种情况
其一，把robots.txt或站点地图当成解析问题。robots.txt限制抓取、站点地图提交都不影响DNS解析是否成功，它们属于抓取与索引层，和子域名能否解析到IP是两回事。
其二，认为启用了HTTPS就说明解析和配置都正常。HTTPS只表示TLS握手成功，不代表子域名记录正确、源站健康或页面可访问。
其三，忽略TTL的影响。修改记录后，旧缓存可能在TTL到期前继续返回旧值。判断时应以权威服务器的当前返回为准，而不是以本地或公共递归的缓存为准。
其四，只测一个网络环境。不同递归解析器、不同地区、不同运营商可能拿到不同结果。至少用两个独立递归解析器交叉验证，才能判断是普遍问题还是局部缓存问题。
下一步怎么做
把上面五步的实际输出记录下来：本地查询结果、权威查询结果、递归查询结果、连接测试结果。对照“返回结果与层级”清单，标出第一个出现异常的位置，那一层就是需要继续深挖的层。若权威与递归结果不一致，先等待TTL过期或联系DNS服务商核查区域配置；若解析正常但连接失败，转向检查源站、防火墙与证书配置。
