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.

This is more complicated than fetching a file with curl and hoping for
the best...

>
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: [email protected]
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

-- 
In my defence, I have been left unsupervised.

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to