攻击后才给网站接入高防，DNS缓存会怎样影响切换生效？

“解析已经改成高防地址，TTL也设成了60秒，为什么十几分钟后还有人访问旧服务器？”这并不矛盾。DNS修改通常只改变权威DNS之后给出的答案，不会主动清除各地递归DNS、操作系统和应用已经保存的旧答案。攻击发生后再临时接入高防，网站往往会经历一段新旧入口并存的时间，而不是在某个时刻统一切换。

DNS缓存对切换的核心影响，是让部分正常用户继续使用旧入口，直到旧缓存到期、重新查询并取得新答案。但这只是其中一层：已有连接可以继续使用旧地址，攻击者也可以直接攻击已知源站IP。因此，“权威解析已修改”“用户开始进入高防”和“源站不再受到直接攻击”是三个不同的状态，不能用一个TTL数值同时判断。

一、先明确：DNS切换改变的是访问入口，不是所有流量

网站高防接入通常改变了什么

本文讨论的是通过修改网站域名解析，将访问流量引向高防入口的场景。常见形式包括把A记录改为高防IP，或把域名的CNAME记录指向服务方提供的接入域名。

接入前，正常访问路径可能是：

浏览器 → 域名解析得到源站IP → 源站

接入后，希望形成的路径是：

浏览器 → 域名解析得到高防入口 → 流量检测与防护 → 回源 → 网站服务

这里的“切换生效”，至少包含三个层次：

这个区分很重要。管理后台显示“修改成功”，通常只能说明配置提交成功；某个探测点解析到新IP，只能说明该探测点使用的解析链路已经取得新答案。

哪些高防方式不以DNS切换为核心

如果防护通过原有IP的上游清洗、路由牵引等方式接入，网站域名不一定需要更换地址。这类方式的接入时间主要受路由、防护策略和运营商协作等因素影响，不能直接套用“等待DNS缓存过期”的解释。

即使使用CNAME接入，不同服务也可能返回不同入口地址。因此，验证时应以实际接入方式为准：确认域名是否指向约定的接入名称，以及最终返回的地址是否属于预期服务，而不是要求所有地区都得到一个固定IP。

DNS缓存导致的延迟，主要发生在“通过改解析更换入口”的方案中；它不是所有高防接入方式共同的等待机制。

二、为什么修改之后，旧地址仍然会被使用

TTL约束的是缓存寿命，不是全网同步倒计时

权威DNS负责发布域名答案。用户通常不直接查询权威DNS，而是交给运营商、企业网络或其他递归DNS，由递归DNS查询并缓存结果。

TTL是DNS记录允许被缓存的时间。递归DNS拿到答案后，通常会随着时间减少剩余TTL；缓存到期后，再次查询时才会取得当前答案。

可以把它理解为一张有有效期的地址卡片：网站管理员换了地址，不等于所有持卡人手里的卡片立即作废。持卡人要在卡片到期后重新获取，才知道新地址。

用一个示例说明：

在这个例子里，切换时旧缓存还剩55分钟。把新TTL设为60秒，不会把此前已经缓存的3600秒记录改成60秒。

新TTL主要影响之后取得相应新记录的缓存。只要旧答案还在有效期内，递归DNS通常没有必要再次询问权威DNS。

为什么不同用户会在不同时间切换

各递归DNS并不是同一时刻缓存同一条记录。有的刚拿到旧答案，有的旧缓存已经接近过期，有的没有缓存、需要立即查询。于是，同一时间可能出现：

• 甲用户已经进入高防，访问正常。
• 乙用户仍然访问旧源站，页面超时。
• 丙用户的首页恢复，但调用另一个业务子域名时仍失败。
• 同一用户换了网络后，得到不同访问结果。

这不是简单的“DNS还没同步到所有地方”。更准确的描述是：不同解析节点手中保留了不同剩余寿命的旧答案，正在分别更新。

实际权威DNS平台也可能需要一定时间完成内部配置分发。因此，分析时要先确认各权威服务器是否都发布了新记录，再讨论递归缓存的自然过期。否则，部分递归DNS重新查询后，仍可能从尚未更新的权威节点取得旧答案。

TTL到期，也不等于业务马上重新解析

DNS回答的是“下一次建立连接应该去哪里”，不会迁移已经建立的连接。

浏览器连接复用、HTTP长连接、WebSocket、应用内部的连接池，都可能让客户端继续使用原有连接。即使DNS答案已经变成高防地址，只要旧连接仍然有效，相关请求就未必重新经历域名解析和建连。

此外，操作系统、浏览器、语言运行时和应用可能拥有自己的缓存机制。它们对缓存寿命、刷新时机及失败重试的处理不完全相同，不能仅凭递归DNS返回的新记录，断定所有客户端都已切换。

另一个例外是过期答案服务：部分递归DNS在上游查询失败等条件下，可能暂时继续返回过期缓存，以维持解析可用性。这不代表TTL没有意义，而是说明旧TTL可用于估算正常缓存路径下的等待量级，不能作为所有访问迁移完成的硬性上限。

三、攻击后临时接入，哪些因素会拉长或破坏切换

原TTL越长，临时降低TTL越难补救当前等待

如果切换前TTL为300秒，按TTL正常工作的缓存，剩余等待通常是分钟量级；如果原TTL为86400秒，就可能存在接近一天的旧缓存。

这里应看的是切换前的TTL和各节点的剩余TTL，不是控制台现在显示的TTL。

提前降低TTL之所以有用，是因为旧的长TTL缓存有机会先过期，之后各节点拿到短TTL答案。攻击发生后才降低TTL，主要改善后续调整，难以消除当前已经存在的旧缓存。

短TTL也有代价：缓存更频繁地到期，会增加查询频率，并提高访问链路对DNS持续可用性的依赖。它是切换准备手段，不是越短越好的通用设置。

只修改一条记录，可能留下另一条旧路径

网站域名不一定只有一个A记录。IPv4和IPv6、主域名和业务子域名都要分别核对。

例如，www.example.com的A记录已指向高防，但AAAA记录仍指向源站。具备IPv6连接能力的客户端可能继续走原IPv6入口。这种情况即使等待很久也不会自动解决，因为问题不是旧缓存，而是权威DNS仍在发布旧路径。

同样，首页域名切换成功，也不意味着登录、接口、静态资源和文件上传所用域名已经接入。页面能打开、提交表单却失败，可能来自这些域名的解析和接入配置差异。

CNAME链与负缓存会增加判断难度

CNAME接入通常不止一次DNS查询：

www.example.com
  → 接入服务的目标域名
  → 高防入口地址

CNAME记录与目标域名的A、AAAA记录可以有不同TTL，也可以被分别缓存。若旧CNAME仍在缓存里，客户端可能继续沿旧链路取地址；若CNAME已经更新，但目标地址缓存或服务配置不正确，仍可能出现异常。

这不意味着每层TTL要机械相加。它们往往独立计时，实际等待取决于哪一层仍阻止客户端取得可用的新路径，应逐层查看答案及剩余TTL。

负缓存也值得注意。如果新增的接入子域名曾返回“不存在”或“没有所查询类型的记录”，递归DNS可能缓存这一否定答案。随后补齐记录，也不一定马上可见。负缓存寿命与否定响应中的SOA信息及解析器策略有关，不能仅用新A记录的TTL解释。

更换DNS服务商，不等于更快接入高防

临时接入时，如果原DNS托管仍然可用，通常没有必要为了更换网站入口，同时更换域名的权威DNS服务器。

修改NS记录会引入另一层委派缓存，并要求新旧权威DNS的数据保持正确。涉及DNSSEC的域名，还要保证签名和相关委派信息协调，否则可能出现解析验证失败。

这类变化会让问题从“地址缓存尚未过期”，变成“部分请求进入不同权威DNS”或“解析本身失败”。旧缓存等待与解析失败需要分开诊断，不能都归为传播延迟。

新入口能收到流量，不代表网站一定恢复

攻击期间匆忙接入，还可能缺少证书、站点绑定、回源协议、端口或Host设置。DNS可以正确指向高防，但访问出现证书错误、跳转循环、502或504。

如果源站已被运营商黑洞、原线路持续拥塞，或源站到高防的回源路径不可达，新入口也可能无法提供页面。此时继续降低TTL没有帮助，应验证高防到源站的业务链路。

四、如何验证：把解析、入口和业务拆开检查

验证的目标不是寻找一个“全网生效百分比”，而是判断异常发生在哪一层。下面使用保留示例域名和文档示例IP说明方法，实际执行时需要替换为自己的域名、权威DNS和高防入口地址。

第一步：确认权威DNS当前发布的答案

先查找域名使用的权威DNS，再分别查询各权威节点。以下命令适用于已安装dig的环境：

dig example.com NS +short

dig @ns1.example.com www.example.com A +norecurse
dig @ns1.example.com www.example.com AAAA +norecurse
dig @ns1.example.com www.example.com CNAME +norecurse

对其他权威DNS重复查询，查看应答状态、ANSWER区及TTL；正常的权威应答通常带有aa标志。如果多个权威节点答案不一致，应先解决权威发布问题，不能只等待用户缓存过期。

如果采用CNAME接入，还要查询其目标域名的地址记录。若返回否定答案，可查看AUTHORITY区中的SOA信息，辅助判断是否存在负缓存相关因素。

这一层能确认“现在发布什么”，但不能证明用户已经取得新答案。

第二步：查看用户所用递归DNS的答案

通过默认解析路径查询，再指定用户实际使用的递归DNS进行比较：

dig www.example.com A
dig www.example.com AAAA

dig @192.0.2.53 www.example.com A
dig @192.0.2.53 www.example.com AAAA

完整输出中的SERVER字段有助于确认查询对象，ANSWER区中的TTL则可用于观察剩余缓存寿命。

可以间隔一段时间重复查询：如果仍返回旧地址，TTL也持续下降，符合旧缓存尚未过期的特征。如果旧地址的TTL反复升高，应进一步检查权威节点是否一致、解析器是否连接了不同缓存节点，以及是否存在刷新或过期答案服务等情况。

不要把TTL重新变大直接解释成“有人改回了记录”。同样，对单个公共递归DNS的查询结果，也不能代表运营商网络和所有真实用户。

第三步：绕开DNS等待，单独验证高防入口

在高防侧已经绑定域名、配置证书并设置回源后，可以使用curl --resolve指定连接地址，同时保留HTTPS所需的域名、Host与SNI：

curl --resolve www.example.com:443:203.0.113.20 \
  --connect-timeout 5 \
  --max-time 15 \
  -sS -D - -o /dev/null \
  -w '\nremote_ip=%{remote_ip} http_code=%{http_code} total=%{time_total}s\n' \
  https://www.example.com/

这个测试不修改公网DNS，只让本次请求连接到指定入口，适合验证“新入口本身是否可用”。

应重点检查证书验证是否通过、连接地址是否正确、状态码和跳转是否符合预期。这里没有关闭证书校验，因为忽略证书错误会掩盖真实用户可能遇到的问题。

首页返回200只能证明该请求成功，还应选择不产生业务写入的页面、静态资源或健康检查地址验证关键路径，避免把登录、下单等操作当作随意探测接口。

如果指定高防入口成功，而普通访问仍失败，才有理由重点检查DNS缓存、客户端缓存和旧连接。如果指定入口也失败，应先检查接入及回源，不宜把故障归咎于DNS。

第四步：结合真实访问日志判断迁移状态

DNS探测展示的是答案，业务日志才更接近实际访问。切换期间可同时观察高防入口请求量、源站请求来源，以及用户失败时间和网络分布。

这里有一个容易误判的地方：接入高防后，源站仍有HTTP请求是正常现象，因为高防可能需要回源。应结合可信的入口日志、回源地址和连接信息，区分正常回源与公网直连，不能只看源站总请求量。

请求头中的客户端IP也不能单独作为依据。只有来自可信入口、且源站按约定处理的转发信息，才适合用于判断；来自不可信直连请求的同名头部可以被伪造。

一组示例结果，如何定位问题

切换20分钟后，得到以下示例观察：

这些结果并不冲突。它们共同说明：新入口已经可用，但正常访问尚未全部迁移，源站也仍可能承受直接攻击。处理时需要分别跟踪缓存收敛与源站直达风险，而不是继续重复修改同一条DNS记录。

五、判断边界：等待缓存能解决什么，不能解决什么

DNS切换不能撤回已经暴露的源站IP

攻击者如果已经知道源站公网IP，可以直接向该地址发送流量，不必再查询网站域名。即使所有正常用户都进入高防，这些直达攻击仍可能持续。

因此，通过改DNS接入高防，主要改变的是遵循域名解析的访问路径，不能自动完成源站隐藏，也不能自动解除原线路的拥塞或黑洞。

源站访问控制、回源专用路径或地址调整可能是后续防护环节，但需要结合服务形态评估。尤其不能在接入链路尚未验证时，贸然关闭所有公网访问。若要限制源站仅接受可信回源，应先备份现有规则，确认管理、监控及业务依赖的影响范围，保留可用管理通道和明确的回滚方式。

回滚解析，也会再次受到缓存影响

发现新入口异常后，将DNS改回源站，并不会让已经缓存高防地址的用户立即返回。切换过去有延迟，切换回来也有延迟。

短时间反复修改记录，还可能让不同缓存持有多个阶段的答案，使故障更难解释。在条件允许时，应保留旧入口与新入口的必要兼容性，直到观察到访问迁移趋于稳定，而不是仅按修改后台的时间关闭旧服务。

用分层证据，而不是单一时间判断生效

现场判断可以按下面的顺序进行：

1. 权威DNS仍返回旧记录或各节点不一致：先检查配置发布和记录完整性。
2. 权威DNS正确，用户递归DNS仍返回旧记录：重点观察旧TTL、缓存刷新及解析链路。
3. 递归DNS已更新，客户端仍访问旧入口：检查本地缓存、应用缓存和已有连接。
4. 已连接高防，但业务失败：检查证书、域名绑定、回源和源站状态。
5. 正常访问已进入高防，源站仍遭直达攻击：这是源站暴露或网络侧问题，不能继续等待DNS来解决。

攻击后才接入高防，真正需要验证的不是“改完解析过了多久”，而是：权威DNS是否一致、代表性用户是否取得新答案、新入口能否完成业务访问，以及源站是否仍被绕过入口直接攻击。

当权威答案一致、多个有代表性的网络路径开始使用新入口、关键业务测试正常且日志能够相互印证时，可以判断切换正在有效收敛。但单个探测点成功、某条记录TTL很短，或等待超过原TTL，都不足以证明所有访问已经迁移，更不足以证明源站已脱离攻击风险。