In March 2020, RFC 8767 was published that specifies when and how a resolver can serve stale data from its cache. Normally, that would break the contract between an authoritative name server and a caching resolver on the amount of time a record is permitted to be cached. The now updated TTL definition in section 4 of the RFC states that:

2020年3月，发布了RFC 8767 ，它指定了解析器何时以及如何可以从其缓存中为陈旧数据提供服务。 通常，在允许记录被缓存的时间量上，这将破坏权威名称服务器和缓存解析器之间的约定。 RFC 第4节中最新更新的TTL定义指出：

If the data is unable to be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired.

如果在TTL到期时不能权威地刷新数据，则可以使用该记录，就好像它没有到期一样。

Serving expired records is not a novel idea and it was already present in various forms (e.g., increased cache-hit ratio, fallback when upstream is not reachable) in various resolvers. Unbound’s own form was called serve-expired and its main purpose was to increase the cache-hit ratio.

服务过期的记录不是一个新颖的主意，在各种解析器中，它已经以各种形式存在(例如，增加的缓存命中率，无法到达上游时的回退)。 Unbound自己的形式称为serve-expired ，其主要目的是提高缓存命中率。

As the RFC landed in the standards track, Unbound gained support for it but still kept the original serve-expired logic. Certain aspects of the RFC, such as timers, were already present in Unbound and their functionality is shared by both modes of operation.

随着RFC进入标准轨道，Unbound获得了对它的支持，但仍保留了最初的serve-expired逻辑。 RFC的某些方面(例如计时器)已经存在于“未绑定”中，并且两种操作模式都共享它们的功能。

The following sections try to clarify the differences between serve-expired and RFC 8767 (serve-stale) and give some insight into when one may be preferable over the other. I will refrain from using the RFC term serve-stale in order to avoid any confusion between the terms and the configuration options later on.

以下各节试图阐明在serve-expired和RFC 8767 ( serve-expired之间的区别，并提供一些见解，使它们何时比另一种更可取。 为了避免稍后在术语和配置选项之间造成任何混淆，我将避免使用RFC术语“服务陈旧”。

服务到期 (serve-expired)

Since version 1.6.0, Unbound has the ability to answer with expired records. Before trying to resolve, Unbound will also consider expired cached records as possible answers. If such a record is found it is immediately returned to the client (cache response speed!). But contrary to normal cache replies, Unbound continues resolving and hopefully updating the cached record.

从1.6.0版开始，Unbound可以回答过期的记录。 在尝试解决之前，Unbound也将过期的缓存记录视为可能的答案。 如果找到这样的记录，则立即将其返回给客户端(缓存响应速度！)。 但是与普通的缓存答复相反，Unbound会继续解析并希望更新缓存的记录。

The immediate downside is obvious: the expired answers rely heavily on the cache state. Unbound already has the tools to try and tip the scales in its favor with the prefetch and serve-expired-ttl options.

显而易见的缺点是：过期的答案在很大程度上取决于缓存状态。 Unbound已经拥有一些工具，可以通过prefetch和serve-expired-ttl选项来尝试扩大规模。

With prefetch, Unbound tries to update a cached record (after first replying to the client) when the current TTL is within 10% of the original TTL value. The logic is similar to serve-expired: if a cached record is found and the record is within 10% of the TTL, it is returned to the client but Unbound continues resolving in order to update the record. Although prefetching comes with a small penalty of ~10% in traffic and load from the extra upstream queries, the cache is kept up-to-date, at least for popular queries.

使用prefetch ，当当前TTL在原始TTL值的10％以内时，Unbound尝试更新缓存的记录(在第一次答复客户端之后)。 逻辑类似于serve-expired ：如果找到了缓存的记录，并且记录在TTL的10％以内，则会将其返回给客户端，但是Unbound会继续解析以更新记录。 尽管预取会带来额外的上游查询流量和负载约10％的损失， 但至少对于流行查询而言 ，高速缓存保持最新状态。

Rare queries have the inescapable fate of having their records expired past any meaningful time. The option serve-expired-ttl limits the amount of time an expired record is supposed to be served. A suggested value per RFC is between one and three days.

稀有查询的命运不可避免地要经过任何有意义的时间。 选项serve-expired-ttl限制了应该为过期记录提供服务的时间。 每个RFC的建议值在1-3天之间。

A note on the expired reply’s TTL value: prior to the RFC, Unbound was using TTL 0 in order to signal that the expired record is only meant to be used for this DNS transaction and not to be cached by the client. The RFC now RECOMMENDS a value of 30 to be returned to the client.

关于过期答复的TTL值的注释：在RFC之前，Unbound使用TTL 0来表示过期记录仅用于此DNS事务，而不是由客户端缓存。 RFC现在 建议 将值30返回给客户端。

A simple configuration for the primal serve-expired behavior could then be:

一个简单的原始serve-expired行为的配置可以是：

server:  prefetch: yes  serve-expired: yes  serve-expired-ttl: 86400  # one day, in seconds

This will allow Unbound to:

这将使Unbound能够：

• prioritize (expired) cached replies,优先处理(过期)缓存的回复，
• keep the cache fairly up-to-date,使缓存保持最新状态，
• in the likelihood that an expired record needs to be served (e.g., rare query, issue with upstream resolving), make sure that the record is not older than the specified limit.如果需要提供过期的记录(例如，罕见查询，上游解析问题)，请确保该记录不早于指定的限制。

RFC 8767 (RFC 8767)

Starting with version 1.10.0 (1.11.0 really, as 1.10.0 contains a bug when the RFC behavior is activated), Unbound also supports serving expired records following the RFC guidelines.

从1.10.0版本开始(实际上是1.11.0，因为激活RFC行为时1.10.0包含一个错误 )，Unbound还支持遵循RFC准则提供过期记录。

The RFC behavior is mainly focused on returning expired answers as fallback for normal resolution. The new option to control that is serve-expired-client-timeout and setting it to a value greater than 0 enables the RFC behavior.

RFC行为主要集中在返回过期的答案作为正常解决方案的后备。 控制serve-expired-client-timeout并将其设置为大于0的值的新选项将启用RFC行为。

With the value set, Unbound has a limit on how much time it can spend resolving a client query. When that limit is passed, Unbound pauses resolution and checks if there are any expired records in the cache that can answer the initial query. If that is the case, Unbound answers with the expired record before resuming resolution. The result of the resolution will be used to update the cache if possible.

设置该值后，“未绑定”对其解决客户查询所花费的时间有限制。 超过该限制后，Unbound将暂停解析，并检查高速缓存中是否有任何可以回答初始查询的过期记录。 在这种情况下，Unbound会在恢复解决方案之前用过期的记录进行答复。 解决方案的结果将在可能的情况下用于更新缓存。

Similar to the client timeout, Unbound will also try and use expired answers instead of returning SERVFAIL to the client where possible.

与客户端超时类似，Unbound也将尝试使用过期的答案，而不是在可能的情况下将SERVFAIL返回给客户端。

A simple configuration for the RFC behavior could then be:

RFC行为的简单配置如下：

server:  serve-expired: yes  serve-expired-ttl: 86400            # one day, in seconds  serve-expired-client-timeout: 1800  # 1.8 seconds, in milliseconds

This will allow Unbound to use expired answers only as fallback from normalalong resolving:

这将使Unbound只能将过期答案用作正常解决方案的后备：

• when 1.8 seconds have passed since the client made the query,自客户进行查询以来已经过了1.8秒，
• instead of returning SERVFAIL;而不是返回SERVFAIL;
• in the likelihood that an expired record needs to be served (e.g., issue with upstream resolving), make sure that the record is not older than the specified limit.如果需要提供过期的记录(例如，上游解析问题)，请确保该记录不早于指定的限制。

结论 (Conclusion)

Unbound offers two distinct modes for serving expired records.

Unbound提供两种不同的模式来服务过期的记录。

The safest approach is to use the RFC behavior where expired records are used as a fallback to availability, network or configuration errors. This will serve expired records as a last resort instead of returning SERVFAIL or the client giving up.

最安全的方法是使用RFC行为，其中将过期的记录用作对可用性，网络或配置错误的后备。 这将把过期的记录作为最后的手段，而不是返回SERVFAIL或客户端放弃。

If more client-side performance is required, the default original serve-expired behavior can keep the cache-hit ratio higher. Using it together with the prefetch option is highly recommended in order to try and keep an updated cache.

如果需要更高的客户端性能，则默认的原始serve-expired行为可以使高速缓存命中率保持较高。 强烈建议将其与prefetch选项一起使用，以尝试保持更新的缓存。

In all cases make sure to consult the man page of your installed Unbound for defaults and suggested values. And always remember that serving expired records should be approached with caution; you may be directing your clients to places long gone.

在所有情况下，请确保查阅已安装的Unbound的手册页以获取默认值和建议值。 并始终记住，处理过期记录时应格外小心； 您可能会将客户引导到久违的地方。