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

子域名解析：怎样排除缓存造成的假象

排除子域名解析的缓存假象，核心是同时核对权威 DNS 记录、递归解析器缓存和本机解析缓存三层，而不是反复刷新浏览器。判断方法：用权威服务器直接查询得到 A/AAAA/CNAME 结果，再与本地默认解析结果对比；两者不一致时，差异通常来自缓存，而不是记录本身没生效。多人协作时，把每次查询的命令、时间、解析器和结果写进交付记录，能显著减少“我这边已经生效、你那边还是旧 IP”的返工。

先分清三种缓存，才知道该找谁

子域名解析链路里至少有三层缓存，混在一起排查就会得出错误结论。

• 权威缓存：权威服务器上的记录有 TTL，修改后旧值不会立刻消失，但权威查询返回的是该服务器当前认定的值。
• 递归解析器缓存：运营商或公共 DNS 按 TTL 缓存结果。TTL 未到期前，即使权威已改，递归仍可能返回旧值。
• 本机与浏览器缓存：操作系统解析缓存、浏览器 DNS 缓存、部分安全软件都会短暂保存结果。

三种缓存的表现不同：权威已更新但递归未更新，属于正常的 TTL 等待；权威仍返回旧值，说明修改没有真正下发或被其他记录覆盖；只有本机异常，则换一台设备就能复现差异。

用权威查询和默认查询做对比

这是最直接、可交付的验证方式。以 shop.example.com 为例（示例域名，仅作演示）：

1. 向该子域名的权威服务器直接查询：dig @ns1.example.com shop.example.com A +short。返回的值是权威当前认定的结果。
2. 用默认解析器查询同一名称：dig shop.example.com A +short。返回的值可能来自递归缓存。
3. 换一个公共解析器再查一次，例如指定另一个递归地址。若两个递归结果不同，说明它们缓存到期时间不一致。
4. 记录每次查询的时间戳和 TTL 剩余值，作为交付证据。

判断规则：权威结果与预期一致、递归结果仍是旧值，属于缓存未过期，等待 TTL 即可；权威结果本身就与预期不符，问题在记录配置或下发流程，与缓存无关。适用条件是你能拿到权威服务器名称；拿不到时，可先用 dig NS example.com 找到委派关系，再逐级核查。

多人协作时的交付清单

从交付结果倒推，需要固定四类信息，否则每次都要重新问一遍。

• 资料：子域名全称、记录类型、目标值、TTL、修改时间、权威服务器名称。
• 任务：谁负责改记录，谁负责验证权威结果，谁负责通知依赖方。
• 责任：明确“权威已生效”和“递归已生效”是两个不同的验收点，不能由同一句“已经好了”代替。
• 验收：至少两名成员在不同网络下用默认解析器查询，结果一致且与权威一致，才算通过。

建议把 TTL 调低安排在变更前完成，而不是变更后临时改。低 TTL 需要提前一个旧 TTL 周期生效，否则递归仍按旧 TTL 缓存，等待时间不会缩短。

常见误判与检查项

下面这些现象容易被当成“缓存问题”，实际原因不同：

• 浏览器显示旧页面，但 dig 返回新 IP：属于浏览器或本机缓存，清本机缓存即可，与递归解析器无关。
• 权威查询返回新值、递归返回旧值、且已超过 TTL：可能是递归解析器未按 TTL 刷新，需要向该解析器服务方反馈，而不是继续改记录。
• 同一子域名在不同地区结果不同：可能是多地递归缓存进度不一致，也可能是权威做了按地域返回，需要先确认权威是否配置了分区解析。
• 修改后立刻查询仍为旧值，但 TTL 尚未走完：这是预期行为，不是故障。

需要说明的是，子域名解析生效不等于搜索引擎会立刻更新索引；抓取、收录与解析是不同环节，robots.txt 限制抓取也不等于可靠的索引移除，站点地图同样不保证收录。排查解析缓存时，不要把这些目标混进同一份验收标准。

下一步怎么做

在下一次子域名变更前，先建立一份最小交付模板：子域名、记录类型、目标值、TTL、权威服务器、变更时间、权威查询结果、两名成员的默认查询结果。变更后按模板逐项填写，把“权威已生效”和“递归已生效”分开记录。这样出现分歧时，直接对比字段就能定位是缓存等待、配置错误还是本机问题，不必重复排查。