Optional stale-while-revalidate mode

[mrpops2ko]

Would you consider adding an optional stale-while-revalidate mode for expired cache entries?

As I understand current implementation, SDNS intentionally treats serve_stale primarily as reliability feature rather than latency optimisation:

expired cached entry
        |
        v
attempt normal resolution
        |
        +-- success  -> return fresh response
        |
        +-- SERVFAIL -> return eligible stale response

That design makes sense, and I can understand why SDNS would prefer fresh data whenever resolution remains possible.

What I would like is an additional opt-in behaviour where, if SDNS already has an expired entry considered safe to serve stale, it can return that response immediately and refresh it asynchronously:

expired eligible entry
        |
        +-- return stale response immediately
        |
        +-- refresh asynchronously

I would not suggest changing existing behaviour or making this default. This would be additional policy for deployments where predictable DNS latency is more important than always waiting for fresh answer.

Why I think this is useful

SDNS already has prefetch, which provides very similar behaviour while entry is still valid.

For example, with:

prefetch = 10

and upstream TTL of 300 seconds:

t=0      entry cached
t=270    final 10% of TTL begins
t=275    client query arrives
             |
             +-- valid cached response returned immediately
             |
             +-- refresh performed in background

This works well for frequently queried names.

There is, however, a gap when no request arrives during prefetch window:

TTL = 300s
prefetch = 10%

0s                         270s       300s     305s
|---------------------------|----------|---------|
cached                 prefetch      expiry    query
                        window

If nothing queries name between 270 and 300 seconds, prefetch never runs.

When client then asks at 305 seconds, SDNS has recently expired cached answer available, but client waits for normal recursive resolution before receiving response.

That first query after expiry can therefore have substantially different latency from surrounding cache hits.

Example

Imagine name with 5-minute TTL that application accesses every 5–10 minutes.

It is not hot enough to reliably hit prefetch window.

Current behaviour is roughly:

query #1
   |
   +--> recursive resolution
   +--> cache for 300s

... no requests ...

TTL expires

query #2
   |
   +--> recursive resolution
           |
           +--> client waits
   |
   +--> cache refreshed

With stale-while-revalidate:

query #1
   |
   +--> recursive resolution
   +--> cache

... no requests ...

TTL expires

query #2
   |
   +--> stale response immediately
   |
   +--> background refresh
              |
              +--> fresh cache

query #3
   |
   +--> fresh cached response

This would make latency much more predictable for intermittently accessed names.

Difference from existing serve_stale

I realise this is somewhat different from apparent intention behind SDNS's current stale implementation.

Current serve_stale seems designed around:

Fresh data should be preferred whenever resolution is possible. Stale data is an availability fallback if normal resolution fails.

That is reasonable default.

Behaviour I am describing makes different trade-off:

If a recently expired response is already considered safe enough to serve in a failure case, optionally allow it to be served immediately while freshness is restored asynchronously.

Both policies seem useful depending on deployment.

For example:

                   Current policy       Stale-while-revalidate

valid cache hit        cached                  cached

near expiry            cached +                cached +
                       prefetch                prefetch

expired entry          wait for fresh          stale immediately +
                                               background refresh

upstream failure       stale                   stale

I would therefore prefer this to be explicit option rather than changing what serve_stale currently means.

Why not just increase prefetch?

Increasing prefetch helps, but does not completely solve this case.

For example:

prefetch = 50

makes refresh window much larger, so intermittently used name is more likely to receive query before expiry.

However, higher prefetch values also cause hot records to be refreshed significantly earlier.

For 300-second TTL:

prefetch = 10%  -> refresh can begin around 270s
prefetch = 25%  -> around 225s
prefetch = 50%  -> around 150s
prefetch = 90%  -> around 30s

For frequently queried records this can substantially increase upstream refresh traffic.

It also still cannot guarantee that query occurs during prefetch window.

Prefetch and stale-while-revalidate therefore solve slightly different problems:

prefetch
    refresh before expiration when traffic happens to arrive

stale-while-revalidate
    handle first request after expiration without making client
    wait for refresh

They seem complementary rather than interchangeable.

Possible configuration

Something along these lines could preserve existing semantics:

serve_stale = true
serve_stale_mode = "failure"

Where failure remains current behaviour.

Alternative mode:

serve_stale = true
serve_stale_mode = "immediate"

With:

failure
    Attempt normal resolution first.
    Serve stale only if resolution fails.

immediate
    If an eligible stale entry exists, return it immediately
    and refresh asynchronously.

Naming could obviously differ; main point is making behaviour explicitly opt-in.

Existing safeguards should still apply

I would not expect this mode to mean "return any expired entry".

Ideally it would use same stale eligibility checks SDNS already applies today.

For example, whatever existing protections apply around:

• maximum stale age;
• response types considered safe for stale serving;
• delegation validity;
• ECS/scoped cache entries;
• DNSSEC considerations;
• cache replacement races;
• other stale-response safety checks.

Those should remain unchanged.

Only point at which already eligible stale response is returned would differ.

Reusing existing prefetch machinery

From looking through cache code, SDNS already appears to have much of machinery needed for asynchronous refresh because of prefetch:

cached response
      |
      +--> return to client
      |
      +--> background refresh queue
                  |
                  v
           resolver path without
             hitting same cache
                  |
                  v
             fresh response
                  |
                  v
              cache update

There also appears to be existing protection against duplicate refreshes and against late background refresh blindly replacing newer cache entry.

That makes me wonder whether immediate stale mode could reuse much of prefetch infrastructure rather than requiring separate refresh mechanism.

Implementation details are obviously better decided by someone familiar with resolver internals, but architecturally operations seem closely related:

prefetch:

valid old answer
    -> return old answer
    -> asynchronously obtain new answer


stale-while-revalidate:

expired-but-eligible old answer
    -> return old answer
    -> asynchronously obtain new answer

Main difference is whether cached response still has authoritative TTL remaining.

Benefits

Lower tail latency

Normal cache hits are extremely fast, while first query after expiration may require complete recursive resolution.

Immediate stale serving removes much of that latency discontinuity.

More predictable application behaviour

DNS is often on critical path before TCP/TLS/application connection setup.

Small number of cold cache expirations can therefore show up as application latency even when DNS resolver itself is otherwise performing well.

This mode would allow operators to optimise for predictable response time.

Better behaviour for intermittently queried names

Prefetch naturally favours hot names.

Stale-while-revalidate particularly helps names that are queried often enough for cache usefulness but not often enough to reliably trigger prefetch.

Avoids needing aggressive prefetch values

Operators interested in avoiding post-expiry latency would not need to expand prefetch window purely to increase chance that refresh occurs before expiration.

This could reduce unnecessary upstream refresh traffic.

No behaviour change for existing users

If current behaviour remains default, deployments that prioritise freshness continue to operate exactly as today.

Users would have to deliberately select latency-oriented behaviour.

Trade-off

Obvious cost is that immediate mode deliberately increases chance that client receives data past authoritative TTL even though fresh answer could potentially have been obtained.

That is meaningful semantic difference, which is why I think it should be optional.

Operator would effectively choose between:

freshness-oriented:

expired
   -> wait
   -> fresh whenever possible
   -> stale only on failure

and:

latency-oriented:

expired + stale eligible
   -> stale immediately
   -> freshness restored asynchronously

Neither policy is universally better; they optimise for different requirements.

Overall request

Would you consider supporting optional stale-while-revalidate / immediate stale mode while retaining existing failure-only stale behaviour as default?

My main use case is eliminating latency spike on first query after cache expiry for records that are not queried frequently enough to trigger prefetch reliably.

I like conservative intention behind SDNS's existing serve_stale behaviour and would not want this feature to change that default. It would instead give operators explicit choice when they are willing to trade some freshness for lower and more predictable query latency.

[semihalev]

Thanks. This added and will be release in v1.9.0