缓存命中率高，不等于递归解析器就安全。若公网任意主机都能使用递归服务，攻击者仍可能伪造查询来源，让解析器把较大的响应发给受害者。要让递归DNS缓存策略降低拒绝服务放大风险，第一步应是限制谁能递归，之后才是调缓存和响应行为。
先堵住开放递归入口
把递归解析器与权威解析器分开部署，或至少分别配置访问规则。面向企业终端、家庭网络或应用服务器的递归服务，只应接受明确的内网网段、VPN 地址或受控出口；公网权威服务器则不应顺带向任意来源提供递归。
BIND 9 可通过 allow-recursion 和 allow-query-cache 限定递归及缓存查询来源；Unbound 可用 access-control 设置允许的客户端网段。配置时不要把“允许查询权威记录”误当成“允许递归”。修改后从授权网段和外部网络各测试一次：前者应能正常递归，后者应被拒绝或无法获得递归结果。
若解析器必须对外开放，例如面向公众提供解析服务，仅靠缓存无法阻止反射滥用。还要结合网络入口的源地址校验、服务端访问策略、异常流量告警和必要的限速；这些措施分别减少伪造请求进入和异常响应持续发出的机会。
缓存怎么设：先尊重权威 TTL，再处理例外
正向缓存不宜一味延长
解析结果的 TTL 由权威 DNS 记录给出。通常应先遵循该值，不要为了提高命中率统一设很高的最短 TTL：网站切换地址、服务故障转移或记录频繁变化时，过长缓存会让客户端继续使用旧结果。若确有必要设置最短或最长 TTL，应先识别动态记录，并在变更窗口观察解析准确性与上游查询量。
负缓存与过期缓存各有边界
负缓存会暂存“名称不存在”等否定结果，减少重复的无效查询，时长受权威响应及解析器配置影响。设得过长，刚创建的域名或记录可能仍被判为不存在；排障时可清理相关缓存，而不是长期压低所有负缓存时间。
支持 RFC 8767 的解析器可配置 serve-stale，在上游暂时不可达时尝试返回过期记录，提高短时故障期间的可用性。但它可能延迟传播地址变更，也不能代替上游健康检查。应明确启用条件、过期数据的使用期限，并测试上游恢复后的刷新行为。
按步骤落地，并验证是否有效
- 盘点用途和来源。列出递归服务的客户端网段、解析器软件及版本，确认哪些实例必须对公网提供权威查询，哪些只服务内部用户。
- 先收紧递归 ACL。在变更窗口只放行必要网段；从非授权网络测试递归请求，确认不会得到可供反射利用的递归响应。
- 分项调整缓存。保留合理的权威 TTL；按业务需要设置 TTL 上下限、负缓存和 serve-stale，不要一次同时改动所有参数。
- 控制响应与监测异常。检查 EDNS(0) 响应大小设置，常见的约 1232 字节配置可降低部分网络中的分片问题，但具体上限要结合路径、软件和客户端测试；同时监控递归查询量、缓存命中、拒绝请求及出站响应规模。
- 记录回退条件。若出现旧地址持续生效、负缓存阻碍新记录解析或错误拒绝合法客户端，按记录或网段定位并回退对应设置，避免直接清空全部缓存造成上游查询突增。
DNS Cookie 在客户端和服务器支持时可辅助识别伪造来源，但兼容性和部署条件有限，不能替代访问控制。实际选择时，内网解析器优先使用严格 ACL 与适度缓存；公网权威服务则应关闭不需要的递归，并单独评估响应速率与网络防护。
常见问题
缓存命中率越高，放大风险就越低吗？
不一定。命中率主要反映重复查询是否减少；开放递归仍可能被利用。先限制递归来源，再观察缓存指标。
可以把所有记录的 TTL 设得很长吗？
不建议。长 TTL 可能让地址变更或故障切换延迟生效。应尊重权威 TTL，并针对稳定记录和动态记录分别评估。
serve-stale 能否作为防护措施？
它主要用于上游故障时维持解析可用，不是反放大机制。启用前应评估过期数据风险，并与访问控制、监控一起部署。
归根结底，递归DNS缓存策略降低拒绝服务放大风险，需要把“谁能递归”放在缓存参数之前：先隔离权限，再谨慎设置 TTL、负缓存和过期数据，并通过外部测试与流量监控持续验证。