子域名解析 - 怎样处理重复或冲突信号
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2eece7d0f821.html
📄
子域名解析 - 怎样处理重复或冲突信号
当同一个子域名同时出现多条解析记录、CNAME 与 A 记录并存，或解析结果与预期不一致时，先不要急着删记录，而是按“收集现象—分类冲突—验证解析—修正记录”的顺序处理。重复或冲突信号的本质是：DNS 查询返回了多个目标，或不同层级、不同记录类型给出了互相矛盾的回答，导致访问、抓取或验证行为不稳定。
先分清重复信号和冲突信号
重复信号指同一记录类型下存在多条指向不同目标的记录，例如为 blog.example.com 配置了两条 A 记录，分别指向不同 IP。冲突信号指不同记录类型或不同层级之间互相矛盾，例如同一主机名既有 CNAME 又有 A 记录，或者子域名委派与父域记录同时生效。
两者的处理方式不同：重复信号要判断是否需要保留多条做负载或容灾；冲突信号通常需要删掉其中一条，因为多数解析场景下 CNAME 不能与其他记录共存于同一主机名。
从一个假设例子开始排查
假设你为 shop.example.com 配置了解析，期望它指向一台服务器。最近发现有时能打开，有时返回错误，有时又跳到另一个页面。可以按以下步骤收集证据：
- 用
dig shop.example.com或nslookup shop.example.com查询，观察返回了几条记录、分别是什么类型。 - 换一个公共 DNS 再查一次，比如指定
dig @8.8.8.8 shop.example.com，对比结果是否一致。 - 检查权威 DNS 服务商控制台，看该主机名下是否同时存在 A、AAAA、CNAME、TXT 等记录。
- 如果子域名被委派给另一组名称服务器，用
dig NS shop.example.com确认委派是否生效，再查委派后的权威结果。
常见错误是只在一个网络环境里查一次，看到某条结果就认定“解析没问题”。DNS 有缓存，不同递归解析器拿到的结果可能不同，必须多源对比。
判断该保留哪条记录
处理冲突时，判断依据不是“哪条看起来新”，而是这条子域名实际要完成什么任务：
- 如果它要指向一个固定 IP，保留 A 或 AAAA 记录，删除同名的 CNAME。
- 如果它要指向另一个域名，保留 CNAME，删除同名的 A、AAAA 等记录。
- 如果多条 A 记录指向不同服务器，确认这些服务器是否都提供相同内容；只有都可用时才考虑保留多条。
- 如果存在 TXT 验证记录，不要因为它“看起来无关”就删除，先确认它是否仍被某项验证依赖。
一个可执行的检查项：把当前所有记录列成表，标注类型、目标、用途、添加时间。对每条记录问一句“删掉它，这个子域名的哪个功能会失效”。答不上来的记录，才进入待删除候选。
修正后如何验证
修改记录后，不要立即反复刷新页面下结论。先确认权威服务器已经返回新结果，再等待缓存过期。验证时至少检查三点：
- 权威查询结果是否只剩预期记录，类型和目标是否一致。
- 不同公共 DNS 的查询结果是否逐步收敛到同一答案。
- 实际访问、证书签发或站点验证流程是否恢复正常，且不再出现随机跳转。
如果修改后问题依旧，优先怀疑缓存未过期或委派未生效，而不是继续叠加新记录。记录越多，冲突面越大。
容易踩的坑
用 robots.txt 限制抓取，并不能替代对冲突解析记录的修正；它只影响爬虫行为，不解决 DNS 返回矛盾的问题。站点地图提交也不保证收录，解析冲突导致的访问不稳定仍会干扰抓取。HTTPS 证书正常也不代表解析没有冲突，证书只覆盖加密连接，不校验 DNS 记录是否唯一。
下一步：整理一份当前子域名的全部解析记录清单，逐条标注用途，先删除明确的冲突项，再用多源 DNS 查询验证结果是否收敛。
