📍 WDQWDWQD987AAAAA:216.73.217.23
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /67207a3200ed.html
📄

子域名解析日志中应该核对哪些字段：从一条假设的解析记录说起

子域名解析日志里，最先要核对的是查询名称、记录类型、解析结果、响应状态和解析时间这五类字段。它们能回答三个问题：谁被查了、查到了什么、结果是否正常。人手有限时，优先看解析结果为空、响应状态异常、解析时间突增的记录，而不是逐条通读全部日志。

假设一条日志，逐字段看它说明了什么

假设某条日志大致长这样（字段名因日志来源不同会有差异，这里只是示意）：

time=2024-06-01T10:12:03Z name=shop.example.com type=A answer=203.0.113.10 status=NOERROR ttl=300

逐项核对：

• 查询名称（name）：确认是目标子域名本身，而不是父域或其他相似名称。大小写、结尾的点、是否存在拼写差异都要看。
• 记录类型（type）：A、AAAA、CNAME、MX、TXT 等含义完全不同。查 A 却只返回 CNAME，往往说明解析链没走完。
• 解析结果（answer）：是否为空、是否指向预期目标、是否出现多个值。空结果和错误 IP 是两类不同问题。
• 响应状态（status）：NOERROR、NXDOMAIN、SERVFAIL、REFUSED 指向的原因不同，不能混为一谈。
• 解析时间与 TTL：时间用于对齐变更窗口，TTL 用于判断旧结果还会被缓存多久。

先处理哪几类异常，判断依据是什么

时间和人手有限时，可以按下面的顺序排查，而不是按日志时间顺序：

1. 先筛 NXDOMAIN 和空 answer：子域名完全查不到，影响面最大。可能是记录未添加、被删除，或查询名称写错。
2. 再筛 SERVFAIL 和 REFUSED：这类通常指向权威服务器不可达、配置错误或权限限制，需要联系解析服务方核对。
3. 然后对比解析结果与预期值：结果存在但指向错误 IP，常见于迁移后旧记录未清理、CNAME 指向了过期目标。
4. 最后看解析时间分布：如果某时段查询量或响应时间明显抬升，结合变更记录判断是否与配置调整相关。

判断结果时注意：一条异常记录可能是偶发缓存造成的，需要看同一子域名在同一时间窗内是否反复出现同类状态，再决定是否升级处理。

容易看错的几个地方

• 把 CNAME 当成最终结果：CNAME 只是指向另一个名称，最终仍要落到 A 或 AAAA。只看到 CNAME 就认为解析完成，容易漏掉后续环节。
• 忽略查询名称的尾点：shop.example.com 与 shop.example.com. 在部分日志里表现不同，核对时保持写法一致。
• 把 TTL 当成生效时间：TTL 决定缓存保留多久，不代表修改立即对所有解析器生效。
• 只看一条日志下结论：单条记录无法区分偶发失败和持续故障，至少要看同一子域名的一段连续记录。

可执行的最小核对清单

打开日志后，按这个清单逐项打勾，通常十几分钟能完成一轮初筛：

• 查询名称是否与目标子域名完全一致；
• 记录类型是否符合本次排查目的；
• 解析结果是否为空、是否与预期值一致；
• 响应状态是否为 NOERROR；
• 解析时间是否落在已知变更窗口内；
• 同一子域名在时间窗内是否重复出现同类异常。

如果清单里前四项都正常，问题可能不在解析层，需要转向 Web 服务、证书或网络链路继续排查。下一步建议先固定一个时间窗和一组目标子域名，把上述字段导出成表格，再按异常类型分组处理，避免在单条记录上反复停留。