子域名解析灰度只放量一个子域后，全量发布的例外该怎么取舍
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /650f18c451ea.html
📄
子域名解析灰度只放量一个子域后，全量发布的例外该怎么取舍
灰度只放量一个子域，往往能验证解析本身是否生效，却验证不了全量发布时其他子域、通配记录和缓存层级是否同样成立。常见结果是：样本子域访问正常、证书匹配、目标页面可见，但扩到全部子域后，一部分主机名落到旧记录、默认站点或证书不覆盖的地址。此时要做的不是立刻全量回滚，而是先判断例外属于保留、改写还是退出。
先分清灰度验证的是解析，还是发布链路
子域名解析的灰度样本通常只覆盖一条记录或一个主机名。它能证明该记录在当前递归链路下可返回预期地址，却不能证明同一套发布流程对所有子域都成立。一个可区分的证据是：样本子域返回新地址，而另一个未放量子域仍返回旧地址，且两者查询的权威服务器相同。这说明差异出在记录集合或发布范围，而不是解析链路本身。
另一种证据是：所有子域都返回新地址，但只有部分子域能完成 TLS 握手。此时问题更可能出在证书覆盖范围或 SNI 配置，而不是 A、AAAA、CNAME 记录。把这两类现象分开记录，才能决定下一步是改记录、改证书，还是暂停发布。
需要说明的是，单个子域解析成功不能证明全量发布安全。DNS 缓存、递归解析器行为、CDN 回源配置和证书签发范围都可能让规模化后的结果偏离样本。
保留：例外子域确实需要独立解析时
如果例外子域承担独立服务，例如面向内部系统、独立品牌页或第三方托管，保留独立记录往往比强行并入统一发布更合理。适用前提是：该子域有明确且稳定的用途，且维护者能持续管理其证书与记录。
实际动作可以这样设计：在灰度放量前，先列出所有子域及其预期目标，标记哪些必须独立、哪些可以合并。放量后若发现某子域返回旧地址但业务仍正常，先确认它是否被有意保留。若是，则把它排除在本次发布范围外，并记录排除原因。这个动作的结果是：发布范围缩小，但例外被显式管理，后续排查不会再把它误判为故障。
保留的代价是记录集合变复杂。子域越多，证书覆盖和记录同步越容易遗漏。因此保留只适合有明确归属和持续维护能力的子域。
改写：例外只是配置漂移，可以收敛到统一规则
如果例外子域并没有独立业务，只是历史遗留或手工添加，改写通常比保留更省维护成本。适用前提是：该子域可以接受与主发布相同的目标地址和证书策略，且没有外部依赖写死旧地址。
可执行的动作是：把例外子域的记录改为与灰度样本一致的 CNAME 或 A 记录，然后重新查询权威服务器和公共递归解析器，确认返回一致。若改写后仍有个别网络返回旧地址，先检查 TTL 和本地缓存，而不是立即判定改写失败。TTL 较长时，旧记录在缓存中继续存在属于预期现象，不代表权威配置未生效。
改写的结果如何影响下一步：如果改写后所有受控查询都返回新地址，就可以把该子域纳入下一轮放量；如果仍有差异，则说明存在未识别的中间层，需要先定位再扩大范围。
退出：例外暴露的是发布假设不成立
当例外子域数量多、原因分散，且无法在短时间内确认每个子域的归属时，退出本轮全量发布是合理选择。这里的退出不是放弃，而是把发布范围收回到已验证的样本，避免例外继续扩散。
判断退出的一个信号是：同一批子域中，部分返回新地址、部分返回旧地址，且无法用 TTL、证书或独立业务解释。此时继续放量只会让排查面变大。退出后应做的是补齐子域清单和预期目标，而不是反复重试同一批记录。
退出也有代价：发布节奏被打断，已改动的记录可能需要回退或保持中间状态。因此退出适用于例外原因不明、影响面可能扩大的情况，不适用于单个已知缓存延迟。
用一个小例子说明边界
假设某次发布只放量 beta.example.com，它解析到新地址且页面可见。随后把同一规则应用到 shop.example.com 和 api.example.com，发现前者仍返回旧地址，后者返回新地址但证书告警。这里不能直接照搬样本结论：shop 的差异可能是 TTL 或独立记录，api 的差异更可能是证书覆盖。下一步应分别查询权威记录和证书覆盖范围，再决定保留、改写还是退出，而不是因为样本成功就继续放量。
这个例子的数字和域名均为假设，只用于说明比较方法：样本成立不等于全量成立，例外需要按原因分类处理。
- 样本子域解析成功，只证明该记录在当前链路下可用。
- 规模化后出现例外，先区分记录差异、缓存延迟和证书覆盖。
- 保留适合有独立业务的子域，改写适合配置漂移，退出适合原因不明且影响面可能扩大。
- TTL 未到期时旧地址继续返回属于缓存现象，不能单独证明权威配置错误。
