Florian Obser wrote:
> On 2026-02-27 13:19 +11, marka <[email protected]> wrote:
> >> On 27 Feb 2026, at 11:47, Wes Hardaker <[email protected]> wrote:
> >>
> >> marka <[email protected]> writes:
> >>
> >>> For HTTP I would make it mandatory that an Expires header exists in
> >>> the reply and that it is used to trim the expiry timer similarly to
> >>> how EDNS EXPIRE is used.
> >>
> >> Just to be clear: or what? Or the localroot implementation must not use
> >> the data from that source? (which is what I think you're implying but
> >> want to be sure)
> >
> > Not use data from that source.
>
> Since internic was mentioned upthread as a source, I had a look what they
> are doing.
>
> k.root-servers.net received the root zone with serial 2026022700 at
> 27-Feb-2026
> 05:37:26.425 with expire option 604797
>
> This is what internic has for that zone:
>
> $ curl -I https://www.internic.net/zones/root.zone
> HTTP/2 200
> date: Fri, 27 Feb 2026 07:48:23 GMT
> [...]
> last-modified: Fri, 27 Feb 2026 06:45:00 GMT
> [...]
> expires: Fri, 27 Feb 2026 07:55:23 GMT
>
> The zone is over one hour old (last-modified header) and it expires
> (expires header) in 7 minutes. From what I can work out from multiple
> requests is that the expires header is always exactly 7 minutes from
> after the request. I guess with such an aggressive expire time we
> shouldn't worry about signatures expiring.
>
> What I do worry about is us assuming how CDNs work and it then turns out
> they work completely differently. E.g. the http expires header is more
> like the SOA refresh timer. Now, we could prescribe that the expire http
> header should work like the SOA EXPIRE + EDNS EXPIRE for our case, but
> at the same time we want to use and off-the-shelf CDN. We will end up
> with two groups of operators talking past each other.
The full set of headers from this particular HTTP origin include the
Cache-Control header with the max-age directive set to 420 seconds, so
an off-the-shelf CDN that implements RFC 9111 section 5.3 will ignore
the Expires header and instead calculate the expiration time as the
current time plus 7 minutes.
(This is probably an Apache server with the mod_expires module
configured to generate the Expires and Cache-Control headers
automatically using the file modification time plus 7 minutes.)
Operationally, it is a common enough desire to control caching
parameters at the CDN layer separately from those at the browser or
other endpoints that there is a standardized way to do this, RFC 9213
("Targeted HTTP Cache Control").
For instance, one could imagine exposing a very long maximum age to the
LocalRoot resolver's HTTP client (regardless of whether it is exposed
via the Expires header or the Cache-Control: max-age directive + Age
header), perhaps as long as the 7 days currently expressed in the root
zone's SOA.EXPIRE field, while at the same time exposing a short max-age
to CDN-class caches so that updates are picked up quickly.
--
Robert Edmonds
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
