大流量攻击期间，域名解析正常不代表业务入口安全：攻击可能直接冲击权威 DNS，也可能绕过 DNS 指向的入口，打满源站链路。处理大流量攻击期间的DNS解析与流量调度，先判断流量打在哪里，再按步骤切换，避免反复改记录却没有效果。
先明确：攻击发生在解析链路还是业务入口
区分 DNS 查询洪泛与指向业务地址的流量攻击。前者重点检查权威 DNS 服务和解析可用性；后者要核对入口、清洗服务或 CDN 的承载情况，以及源站是否仍可访问。若权威 DNS 已超时，应优先联系 DNS 服务商确认其服务状态；若解析正常但请求失败，单纯更换 A 记录通常不能消除入口拥塞。
按5步检查并调整
- 确认受影响范围。从不同网络使用 dig 或 nslookup 查询域名，分别检查 A、AAAA、CNAME 记录与权威名称服务器（NS）。同时观察业务错误率和入口流量：若多个网络都无法取得响应，排查 DNS 链路；若解析结果正常而服务不可达，继续检查流量入口。不要只根据单台设备的缓存结果判断。
- 核对权威解析与变更记录。检查 DNS 控制台中的记录值、代理状态、健康检查和近期变更，确认是否存在误删、错误指向或不一致的记录。使用 dig +trace 可沿解析路径查看委派情况；再对照权威服务器与公共递归解析器（如 1.1.1.1、8.8.8.8）的结果，判断问题是在权威端还是递归缓存环节。
- 评估可接流量的目标。逐一确认备用入口、清洗服务或 CDN 的健康状态、可用容量与回源路径。只有经过验证、能承接当前业务的目标才纳入调度；若备用端仍依赖被攻击的源站，切过去不等于完成隔离。记录原始解析值和当前状态，为回退留依据。
- 按容量调整解析策略。存在多个可用入口时，可使用 DNS 服务商支持的权重、地理位置或健康检查调度，把流量导向健康且有余量的目标。容量差异明显时不宜机械平均分配；若只有一个已确认可用的入口，则可临时切换到该入口。DNS 调度有缓存延迟，不能保证所有用户同时切换，也不适合秒级精细限流。
- 验证效果并设定回滚条件。切换后从多个网络复查记录，同时看入口流量、服务错误率、回源压力和备用端健康状态。若错误率上升、备用端接近容量上限或解析结果不一致，暂停继续调整并按预案回滚或重新分配。保存变更时间、操作者和观测结果，避免多人同时修改造成反复切换。
TTL、缓存与调度方式怎么选
TTL 决定递归解析器通常缓存记录的时间，但实际客户端和中间解析器可能有不同处理方式。攻击期间临时降低 TTL，有助于缩短部分缓存记录的存留时间，却会增加查询量，也无法清除已经缓存的旧结果。若预计需要快速切换，可在平时预先评估较短 TTL 对查询负载的影响；临时修改后应留出传播时间，并持续检查解析结果。
权重调度适合按已知承载能力分配多个入口，配置直观，但依赖健康检查和缓存更新；地理位置调度可让不同地区返回不同目标，适用于各地区入口均已验证的情况，但用户实际位置、递归解析器位置可能不一致。健康检查适合剔除不可用目标，不代表它能准确判断目标是否还有充足余量。大流量攻击期间的DNS解析与流量调度应与上游流量清洗、入口防护配合，不能把 DNS 当作流量清洗设备。
常见问题
改了记录，为什么用户还访问旧地址？
递归解析器或客户端可能仍缓存旧记录。TTL 是参考时间，不保证所有缓存同时刷新；应分别查询权威端和多个递归解析器确认传播情况。
降低 TTL 就能让切换立即生效吗？
不能。降低 TTL 不会追溯清除此前已缓存的记录，还可能增加 DNS 查询负载。应提前规划，并在切换后持续验证。
只有一个备用 IP 时，是否应该直接切换？
先确认备用入口容量、健康状态和回源链路。若无法承接当前流量，盲目切换可能扩大故障；可用目标不足时，应联系 DNS 或流量清洗服务提供方协同处置。
简要而言，先定位受影响的链路，再验证目标容量，最后小步调整并复查。按大流量攻击期间的DNS解析与流量调度这一路径操作，能减少无效改记录，并让每次变更都有观测依据和回滚条件。
