Use DNS TTL or Cache-Control header for resolution cache #21

New issue

Open

opened 2026-07-05 00:47:32 +00:00 by s1lv3r · 2 comments

s1lv3r commented

2026-07-05 00:47:32 +00:00

Member

Quote from the spec:

Responses (successful or otherwise) to the /.well-known endpoint should be cached by the requesting server. Servers should respect the cache control headers present on the response, or use a sensible default when headers are not present. The recommended sensible default is 24 hours. Servers should additionally impose a maximum cache time for responses: 48 hours is recommended. Errors are recommended to be cached for up to an hour, and servers are encouraged to exponentially back off for repeated failures.

This essentially means:

Cache-Control headers should be followed, defaulting to 24 hours if none are present (for this implementation, no-cache = none = 24 hours)
Responses should be cached for a maximum of 48 hours, regardless of header value
Error responses should be cached for up to an hour, with backoff for repeated failures.

The spec says nothing on DNS SRV responses, however it is reasonable to treat these the same way as Cache-Control headers (follow when possible, default 24h, max 48h).

See some discussion in the dev channel here until here

Quote from the spec: > Responses (successful or otherwise) to the `/.well-known` endpoint should be cached by the requesting server. Servers should respect the cache control headers present on the response, or use a sensible default when headers are not present. The recommended sensible default is 24 hours. Servers should additionally impose a maximum cache time for responses: 48 hours is recommended. Errors are recommended to be cached for up to an hour, and servers are encouraged to exponentially back off for repeated failures. This essentially means: - Cache-Control headers should be followed, defaulting to 24 hours if none are present (for this implementation, no-cache = none = 24 hours) - Responses should be cached for a maximum of 48 hours, regardless of header value - Error responses should be cached for up to an hour, with backoff for repeated failures. The spec says nothing on DNS SRV responses, however it is reasonable to treat these the same way as Cache-Control headers (follow when possible, default 24h, max 48h). --- See some discussion in the dev channel [here](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24uPMp45RGebI2A6UNOUgT3LVQTrFibTzWZ_Cnz5iL-WY?via=wolfgirl.pet&via=explodie.org&via=matrix.org) until [here](https://matrix.to/#/!ksTlboXVgcyWjv5GrlEeKyQuJ8ZCprnwQx2b6-BQ44Q/%24vzvzFFE_JWf0T-E9xRbxEqHncmlCTB2llEFzG8RZDYk?via=wolfgirl.pet&via=explodie.org&via=matrix.org)

nex commented

2026-07-09 17:54:05 +00:00

Owner

The spec says nothing on DNS SRV responses, however it is reasonable to treat these the same way as Cache-Control headers (follow when possible, default 24h, max 48h).

In this case, DNS TTLs should be honoured. The spec pedant in me hates it, but it might be worth ignoring TTLs with a value of 300 or 600 since those tend to be default values set by DNS providers in my experience, and re-querying every 5 minutes probably isn't something either party actually wants

> The spec says nothing on DNS SRV responses, however it is reasonable to treat these the same way as Cache-Control headers (follow when possible, default 24h, max 48h). In this case, DNS TTLs should be honoured. The spec pedant in me hates it, but it might be worth ignoring TTLs with a value of 300 or 600 since those tend to be default values set by DNS providers in my experience, and re-querying every 5 minutes probably isn't something either party actually wants

s1lv3r commented

2026-07-09 17:59:56 +00:00

Author

Member

I agree, 5/10/15 minutes is too little. A minimum of 1h could be a good middle ground, but I can also see times where such a long cache is undesirable. Then again a server restart or cache clear command would empty it anyways, so probably a worthwhile compromise