攻击发生时，备用域名能否接住真实访问，取决于解析缓存、入口配置和回切准备是否都经过验证。攻击事件中备用域名与业务入口的切换演练应在平时完成，不能等主入口不可用后才临时改记录、查证书。
演练的目标不是证明某条解析记录已经修改，而是确认不同网络中的用户能抵达可用入口，业务请求能够完成，并且需要恢复时有清楚的回切路径。
先明确切换边界，避免只改域名记录
开始前列出主域名、备用域名、对应的服务入口、负责修改解析的人，以及批准切换和回切的负责人。确认备用入口已部署所需的页面或接口、访问控制和流量承载能力；如果备用域名使用不同主机名，还要检查证书是否覆盖该名称，避免解析成功却出现浏览器证书错误。
明确哪些现象会触发切换，例如主入口持续不可达、关键请求失败，或运维人员确认正在发生影响服务的攻击。触发条件应配合现有监控和处置流程，不宜仅凭单次告警自动切换。演练记录中还要写明谁有权操作、如何通知相关人员，以及什么条件下停止演练。
把 DNS 缓存纳入时间预期
TTL表示解析记录可被缓存的时间，但它不是用户切换完成的倒计时。递归解析服务会依记录的 TTL 缓存答案；操作系统、应用程序和已有网络连接也可能影响实际访问。因此，修改后不同用户不会必然同时到达备用入口。
若计划降低 TTL，应提前调整并留出原有缓存逐步过期的时间。临近攻击才缩短 TTL，不能让此前缓存的答案立即失效。演练时可从多个网络环境查询结果，并分别核对权威 DNS 返回值和实际访问结果；两者不一致时，先判断是传播、缓存还是入口问题，不要连续反复改记录。
按步骤演练切换与入口验证
- 检查基线：记录主入口和备用入口当前状态、解析记录、证书有效性及关键页面或接口的预期响应。选择不会影响真实用户的演练窗口；若无法隔离流量，应先确认影响范围并取得操作批准。
- 确认备用入口：直接测试备用域名，检查连接是否成功、证书名称是否匹配、页面或关键业务请求是否返回预期结果。仅看到入口首页，不足以证明后续业务链路可用。
- 执行受控切换：按预定变更流程将相关解析指向备用入口，记录操作时间和变更前后内容。不要同时修改多个无关配置，以免故障时无法判断原因。
- 验证用户路径：在不同网络中重新查询并访问备用域名，检查页面、登录或查询等选定的关键流程。结合入口健康检查和业务监控，观察失败率、响应状态及错误提示；实际收敛时间受缓存和网络环境影响，应以观测结果记录，而非预设统一时限。
- 记录异常：若解析已更新但访问仍到旧入口，检查本地和递归缓存；若访问备用域名后报错，检查证书、主机名路由、访问策略和后端依赖。记录发现、处置和验证结果。
回切不是把记录改回去就结束
只有主入口恢复稳定、切回风险经过评估，并且负责人批准后，才进入回切。先确认主入口能够处理恢复后的访问，再按变更流程恢复解析；随后重复多网络查询、证书检查和关键请求验证。由于 DNS 缓存仍可能保留备用入口地址，切回后应同时监控两个入口，避免把“记录已恢复”误当成“所有用户已回到主入口”。
每次演练都应保存时间线、解析结果、入口检查结果、异常及改进项。若备用入口依赖不同的配置或后端服务，应把这些依赖纳入下一轮验证。这样的攻击事件中备用域名与业务入口的切换演练，才覆盖从触发、切换到回切的完整过程。
常见问题
修改解析记录后，为什么还有人访问旧入口？
递归解析服务或本地环境可能仍缓存旧答案，已有连接也未必立即中断。应结合 TTL、不同网络的查询结果和实际请求判断收敛情况。
演练是否需要真的切换生产流量？
不一定。优先使用隔离环境或受控范围验证；若必须触及生产流量，应提前批准、界定影响范围，并准备停止和恢复步骤。
备用域名能打开，就算切换成功吗？
不能。还需验证证书、主机名路由、关键页面或接口，以及相关业务依赖是否正常。
回切后可以马上结束观察吗？
不宜仅凭解析记录恢复就结束。应观察不同网络的访问结果，并确认主入口承接正常、遗留缓存没有造成持续异常。
