因为现代解析器使用了预取和请求合并等技术来提高效率，所以没有必要让每个客户端请求在存在陈旧数据的情况下都触发新的查找流程，而是在将陈旧数据传递给任何客户端之前，尽最大努力刷新陈旧数据。
我没有得到此建议的限制。假设我的缓存中有“abc.com”，其 TTL 为 1 小时，已过期 30 分钟，还有“xyz.com”，其 TTL 为 1 小时，已过期 20 分钟。如果我将过时数据保留 12 小时，我应该先提供过时数据（因为它不久前就过期了）还是应该先尝试刷新？
文档中说，如果客户端计时器已过期（约 1.8 秒），则可以提供过时的数据，但现在建议在某些情况下返回第一个过时的数据。但我不明白这些情况是什么。
而是最近做出了善意的努力来更新陈旧的数据
这是否意味着如果解析器在 TTL 过期之前尝试刷新数据至少一次，我就可以立即提供过时的数据？无论请求现在是否可以成功刷新？
答案1
您所引用的文本是这样的（就在您的文本之前）：
仅在刷新失败时才会使用过时数据，以符合 DNS 设计的初衷和运营商所期望的行为。如果总是立即使用过时数据，然后在发送客户端响应后尝试刷新缓存，解析器将经常发送本来可以毫无问题地刷新的数据。
这意味着，只有当解析器在“客户端响应计时器”触发之前无法获取新数据（这与本文前面建议的 1.8 秒相关）时，才允许提供陈旧数据（缩短的 TTL）。
这并不意味着它仅仅因为向客户端提供了过时的数据就停止处理此查找。它仍应尝试完成查找并更新缓存，以避免下次提供过时的数据。
如果查找不仅比“客户端响应计时器”慢（建议 1.8 秒），而且比“查询解决计时器”（查询的最大时间，建议 10-30 秒）慢，甚至完全不可能，那么建议只需要每“故障重新检查计时器”秒（建议 30 秒）再次尝试查询。
即，如果您尝试在过去 30 秒内刷新（或使用任何故障重新检查计时器），并且该尝试彻底失败（或可能仍在进行中），则您可以提供过时的数据。否则不行。
你应该把它视为目标不是提供过时的数据。RFC8767 所说的内容本质上是，当传统行为会超时（从客户端的角度来看）或由于无法获取当前数据而返回错误时，您可以暂时提供过时的数据，同时继续尝试获取当前数据。
当递归解析器收到请求时，它应该启动
客户端响应计时器。此计时器用于避免客户端超时。
它应该是可配置的，建议值为 1.8 秒，
略低于常见的 2 秒超时值，同时仍为
解析器提供公平的解析名称的机会。然后，解析器会检查其缓存中是否
有满足请求的未过期记录，并返回这些记录（如果可用）。如果未找到
相关的未过期数据，并且请求中未设置“需要递归”标志
，则它应立即返回响应，而不
查询缓存中是否有过期记录。通常，此响应
将转介到覆盖该区域的权威名称服务器，
但具体细节取决于实现。如果要进行迭代查找，则参考故障重新检查计时器。 建议
从无响应或出现故障的权威名称服务器刷新的尝试 频率不超过每 30 秒一次。如果在此时间段内收到此请求 ，则可能会立即参考缓存以获取过时 数据以满足请求。在故障重新检查计时器的时间段之外，解析器
应启动查询解析计时器并开始迭代
解析过程。此计时器限制解析器在联系外部机构时所做的工作
，通常
约为 10 到 30 秒。如果此计时器在仍在处理的查询尝试上到期
，则解析工作将被
放弃。如果在客户端响应计时器到期时仍未完全确定答案
，则解析器应检查其
缓存，以查看是否有可满足
请求的过期数据。如果有，它会将该数据添加到响应消息中，TTL
大于 0（如第 4 节所述）。然后，响应将
发送给客户端，同时解析器继续尝试
刷新数据。如果在解析尝试期间无法联系到任何授权机构
，解析器应尝试刷新委托，并
使用查询解析计时器的剩余时间重新启动迭代查找过程。每次 解析尝试
只能恢复一次。在解析过程之外，最大过期计时器用于
缓存管理，与查询解析过程无关。
此计时器在概念上不同于
许多解析器中存在的最大缓存 TTL，后者是对从权威服务器收到的 TTL 值的限制， 在第 4 节的 TTL 定义中
建议为 7天。最大过期计时器应该是可配置的。它定义了记录 过期后应在缓存中保留的 时间长度。建议值 在 1 到 3 天之间。