子域名解析：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /978a1aca94d6.html
📄
子域名解析：怎样取得可复查的状态证据
要取得子域名解析的可复查状态证据，核心是同时记录三样东西：查询时间、查询所用的递归解析器、以及返回的完整应答内容。只截图一个“能打开”或“打不开”的结果，无法复查，因为解析结果会随解析器缓存、权威记录变更和网络位置而变化。正确做法是用命令行工具分别向多个递归解析器发起查询，保存原始输出，再与权威域名服务器上的记录逐项对照。
先明确要查的是哪一层记录
子域名解析涉及多个层级，证据必须对应到具体层级，否则无法判断问题出在哪里。
- 权威层：子域名在权威域名服务器上配置了什么记录，例如 A、AAAA、CNAME、MX、TXT。
- 递归层：本地或公共递归解析器返回了什么，是否命中缓存。
- 委派层：父域是否把该子域正确委派给权威服务器，NS 记录是否一致。
如果只查递归层，看到的是缓存后的结果；如果只查权威层，看到的是配置本身。两者不一致时，问题通常出在缓存未过期或委派配置有误，而不是记录本身不存在。
用命令行取得可复查的原始证据
以下命令在 Linux、macOS 和 Windows 的较新版本中大多可用，Windows 上部分命令需要安装相应工具。执行时把 sub.example.com 替换为实际子域名。
- 向默认递归解析器查询：
dig sub.example.com A，Windows 可用nslookup sub.example.com。 - 指定公共递归解析器查询，排除本地缓存干扰：
dig @8.8.8.8 sub.example.com A，再换一个解析器重复一次。 - 直接向权威服务器查询：先用
dig NS example.com找到权威服务器名称，再用dig @ns1.example.com sub.example.com A查询。 - 查看完整应答，包括 TTL、状态码和 ANSWER SECTION，而不是只看一行结果。
- 把每次输出的时间、使用的解析器和完整内容保存为文本文件，作为可复查证据。
判断结果时注意几个信号：状态码 NOERROR 且有 ANSWER 记录，说明该解析器返回了记录；状态码 NXDOMAIN 表示该名称在权威层不存在；如果只有 AUTHORITY SECTION 而没有 ANSWER，可能是委派或缓存问题。TTL 数值可以帮助判断缓存还会保留多久。
把解析结果与权威配置对照
可复查的证据必须能回答“权威配置是什么”和“递归看到的是什么”这两个问题。做法是：
- 记录权威服务器返回的记录类型、值和 TTL。
- 记录至少两个不同递归解析器返回的结果。
- 如果两者不一致，先确认权威记录是否刚刚修改过，再等待原 TTL 过期后重新查询。
- 如果权威层没有该记录，而递归层返回了旧值，说明是缓存残留，不是配置生效。
这里要区分“可能原因”和“已经定位的原因”。例如递归返回 NXDOMAIN，可能是子域名确实未配置，也可能是委派缺失，还可能是查询的解析器缓存了否定应答。只有分别向权威服务器和多个递归解析器查询后，才能确定是哪一种。
需要区分的几个常见误解
子域名解析证据只说明域名系统层面的返回结果，不能直接推断其他事情。
- 解析成功不等于网站可访问，还要看服务器是否响应、证书是否匹配。
- robots.txt 的抓取限制不等于索引移除，两者是不同机制。
- 站点地图不保证收录，提交站点地图与是否被索引没有必然对应关系。
- HTTPS 不保证安全无漏洞，也不保证排名。
这些边界不影响解析证据本身，但在根据解析结果下结论时需要分开看待。
验收信号与下一步
一份可复查的子域名解析证据应当满足：有明确查询时间；标明使用的递归解析器或权威服务器；包含完整应答而非截取片段；权威层与递归层结果可以逐项对照；对不一致之处有 TTL 或委派层面的解释。
下一步可以固定一个记录模板，每次排查时填写子域名、记录类型、查询目标、返回状态码、ANSWER 内容和 TTL，并按时间顺序保存。这样即使过一段时间回看，也能判断当时的解析状态是否与配置一致。
