DNS正缓存、负缓存、TTL、SOA MINIMUM和Serve Stale有什么区别？

直接答案

DNS正缓存保存已经存在的资源记录及其结果；负缓存保存“域名不存在”或“该类型记录不存在”等否定答案；TTL规定缓存数据在正常情况下可以保留多久；SOA MINIMUM在现代DNS语义中用于参与确定负缓存TTL；Serve Stale允许递归解析器在权威服务器暂时不可达时，有限度返回已经过期的旧数据，以提高可用性。

修改A记录不立即生效，通常与旧正缓存有关；刚创建的新域名仍显示NXDOMAIN，可能是负缓存尚未到期；TTL已经为零却仍得到旧结果，可能涉及本地应用缓存、Serve Stale或并未查询到预期解析器。排障时必须先区分缓存层和答案类型。

一、核心概念对比

缓存行为还会受到递归解析器的最小/最大TTL限制、操作系统与应用缓存影响。

二、正缓存如何工作

递归解析器从权威服务器获得A、AAAA或其他资源记录后，可按TTL保存。后续相同查询可以直接从缓存回答，不必重新走根、顶级域和权威查询链。

缓存返回时，TTL通常随着已缓存时间递减。看到TTL剩余300秒，表示该解析器当前缓存条目距离正常过期约还有300秒，不等于权威区原始TTL就是300秒。

三、RR与RRSet有什么区别

同一名称、类型和类别的一组资源记录构成RRSet。例如一个域名的三个A地址属于同一个A RRSet。RFC 2181要求同一RRSet中的记录使用相同TTL。

不要为同一轮询A记录设置不同TTL并期待各自独立过期。接收方遇到不一致TTL时，可能按最低值处理或视为错误。

四、TTL真正表示什么

TTL是资源记录可在缓存中保留的时间上限，单位为秒。它不是网络延迟，也不是权威服务器刷新区域文件的周期，更不是客户端必须在该秒数后主动查询。

TTL为零通常表示不应缓存该记录，但查询链上的软件仍可能有实现差异。高TTL降低查询量、提高缓存命中率；低TTL加快计划变更传播，却增加权威与递归查询负载。

五、TTL到期不等于记录立即消失

TTL只控制某个缓存实例。不同递归解析器在不同时间首次查询，过期时间也不同。浏览器、操作系统、语言运行时和本地代理还可能有独立缓存。

因此全球不存在一个同步倒计时。变更验证应向多个指定递归解析器查询，并直接向权威服务器查询作为基准。

六、负缓存为什么必要

如果每次查询不存在的域名都必须重新访问权威服务器，拼写错误、扫描或失效链接会产生大量重复流量。负缓存让解析器暂时保存权威否定答案。

RFC 2308使负缓存成为规范行为：当权威响应携带可确定期限的SOA记录时，缓存解析器可以保存NXDOMAIN或NODATA结果。

七、NXDOMAIN负缓存保存什么

NXDOMAIN表示查询名称不存在。其缓存键关注名称和类别，因此对同一个不存在名称查询不同记录类型时，缓存的名称错误可能继续适用。

这与NODATA不同。若名称本身不存在，后来新建该名称后，用户仍可能在负缓存到期前看到NXDOMAIN。

八、NODATA负缓存保存什么

NODATA表示名称存在，但请求的记录类型不存在。例如域名有A记录，但没有AAAA记录。负缓存应结合查询名称、类型和类别保存。

创建AAAA记录后，之前查询过该AAAA的解析器可能继续返回NODATA，而从未查过的解析器会立即看到新记录。这种差异并不必然表示权威服务器不一致。

九、SOA为何出现在否定答案中

否定答案的Answer区没有目标记录，无法从目标RR获取TTL。权威服务器会在Authority区携带所属区域的SOA，用它向解析器提供负缓存所需信息。

缺少SOA的否定响应不适合正常负缓存，因为无法建立可靠的到期时间，也可能使错误在转发器循环中长期传播。

十、SOA MINIMUM的现代含义

SOA MINIMUM曾被赋予多种历史含义，包括区域记录的最小TTL和默认TTL。RFC 2308明确其现代定义是用于负响应TTL。

实际负缓存TTL取SOA记录自身TTL与SOA MINIMUM中的较小值。修改负缓存时间时，应同时核对两个值，而不是只改MINIMUM字段。

十一、$TTL与SOA MINIMUM不是一回事

区域文件中的$TTL为没有显式TTL的后续资源记录提供默认值，影响普通正记录。SOA MINIMUM参与负响应缓存。

把两者设置成相同数字只是运维选择，不代表协议语义相同。排查“新建记录仍不存在”时关注负缓存；排查“旧A记录仍存在”时关注原A RRSet TTL。

十二、SERVFAIL可以缓存吗

SERVFAIL表示服务器无法完成查询，不同于权威确认名称不存在。现代RFC对解析失败缓存给出了短期上限，目的是避免故障查询风暴，但不能像普通NXDOMAIN那样长时间保存。

看到持续SERVFAIL时，应检查DNSSEC验证、权威可达性、委派与递归器日志，而不是假设“等SOA MINIMUM到期就好”。

十三、Serve Stale解决什么问题

RFC 8767允许递归解析器在无法刷新缓存时提供已过期数据，以避免权威服务器故障导致整个域名立即不可用。它是韧性机制，不是延长权威TTL的普通缓存行为。

解析器返回过期记录时，应使用很短的响应TTL，并继续尝试刷新。客户端通常无法仅凭答案内容确认它是否来自过期缓存，需要查看解析器能力、日志或扩展信息。

十四、Serve Stale的风险

旧地址可能已经不再属于原服务，继续返回会把流量送往错误主机；旧安全策略或验证记录也可能产生风险。RFC 8767明确讨论了过期数据被滥用的可能性。

因此Serve Stale应有最大保留时长、触发条件和监控。它适合短暂权威故障，不应掩盖长期失效的委派或区域维护问题。

十五、预计划DNS变更怎样降低TTL

若准备迁移IP，应在变更前至少一个旧TTL周期降低旧记录TTL，等待各地旧缓存自然过期，再切换记录。切换完成并稳定后，可以恢复常规TTL。

在切换瞬间才降低TTL不会影响已经缓存的旧记录。那些缓存仍按查询时获得的旧TTL倒计时。

十六、新建记录为何比修改记录更麻烦

修改现有记录受正缓存影响；新建此前不存在的名称或类型可能受负缓存影响。如果部署流程先让用户查询一个尚未创建的名称，再补记录，就可能提前制造NXDOMAIN缓存。

稳妥做法是先创建记录、验证权威答案，再让流量或客户端开始查询。若必须按阶段上线，应提前缩短相关区域的负缓存TTL。

十七、删除记录后的缓存行为

删除记录不会通知世界各地的递归解析器。已有正缓存可以继续服务到TTL结束；之后查询才会得到NODATA或NXDOMAIN，并进入负缓存阶段。

若要紧急下线有安全风险的目标，DNS变更不是即时撤销手段。还应在旧服务器、负载均衡器或防火墙层阻止危险流量。

十八、CNAME链中每一段都有缓存

查询别名时，CNAME RRSet和最终目标的A/AAAA RRSet各有自己的TTL。任何一段仍缓存旧值，都可能让最终结果与预期不同。

迁移前应检查整条链，包括目标名称、负载均衡域名和供应商返回记录。只降低最外层CNAME TTL不一定足够。

十九、如何确认权威答案

先查询区域的NS记录，直接向每台权威服务器询问目标名称和类型，并检查AA标志、答案、SOA序列号及TTL。所有权威节点应在区域传播完成后返回一致数据。

若权威仍返回旧值，问题在区域发布或同步；若权威正确而递归器旧，才进入缓存排查。不要一开始就清本机缓存而忽略权威状态。

二十、如何定位缓存在哪一层

依次比较：应用自身结果、操作系统解析结果、本地网关或企业DNS、指定公共递归解析器、最终权威服务器。每一步记录服务器地址、查询类型、返回码、TTL和时间。

关闭浏览器再打开不保证清除系统或网络缓存。使用明确指定DNS服务器的查询工具，才能减少路径不确定性。

二十一、为什么刷新或重启有时有效

重启应用可能清掉应用内DNS缓存，刷新本地解析服务可能清掉操作系统缓存，重启路由器可能清掉网关缓存。但这些操作不会清除运营商或公共递归解析器缓存。

因此“重启后好了”只能证明某个本地状态被改变，不能证明权威DNS配置从一开始就是正确的。

二十二、缓存异常排查清单

确认查询名称和类型；区分NXDOMAIN、NODATA与SERVFAIL；直接查权威；读取SOA及负缓存字段；比较多个递归器剩余TTL；检查CNAME链；清理可控本地缓存；核对是否启用Serve Stale；最后等待不可控缓存到期。

每次查询都保存时间戳。TTL是倒计时证据，脱离查询时间记录一个数字，很难重建故障过程。

常见问题

1. 把TTL改成60秒后，旧记录多久消失？

已经缓存的旧记录仍按它获取时的旧TTL到期。只有后续刷新获得的新记录才使用60秒。

2. NXDOMAIN和NODATA的负缓存相同吗？

不相同。NXDOMAIN表示名称不存在；NODATA表示名称存在但所查类型不存在，其缓存键范围也不同。

3. SOA MINIMUM越小越好吗？

不一定。过小会增加不存在名称带来的权威查询负载，过大则延长新建名称或记录类型后的不可见时间。

4. TTL到期后为什么还返回旧IP？

可能查询了另一个尚未过期的缓存，也可能解析器启用了Serve Stale，或应用维护独立缓存。先比较权威与指定递归器。

5. 清除公共DNS缓存可以立即解决吗？

多数递归器不提供任意用户可控的全局清缓存。最可靠的方法仍是正确规划TTL、修复权威配置并等待缓存到期。

结论

正缓存保存已有记录，负缓存保存权威否定答案，TTL控制正常缓存期限，SOA MINIMUM参与决定负缓存时间，Serve Stale则在刷新失败时短暂使用过期数据。按权威、递归、本地和应用四层取证，才能判断旧结果究竟来自哪里，而不是把所有延迟都归为“DNS传播”。

参考来源

1. RFC Editor：RFC 1034 Domain Names — Concepts and Facilities，https://www.rfc-editor.org/info/rfc1034/

2. RFC Editor：RFC 2181 Clarifications to the DNS Specification，https://www.rfc-editor.org/info/rfc2181/

3. RFC Editor：RFC 2308 Negative Caching of DNS Queries，https://www.rfc-editor.org/info/rfc2308/

4. RFC Editor：RFC 8767 Serving Stale Data to Improve DNS Resiliency，https://www.rfc-editor.org/info/rfc8767/

5. RFC Editor：RFC 9520 Negative Caching of DNS Resolution Failures，https://www.rfc-editor.org/info/rfc9520/