Florian Obser wrote: > 3. Figure out what to do about http / CDNs. I suppose we could use the > "last-modified" header? Not a web person. But that we need to > stipulate *somewhere* that "last-modified" reflects the inception > time of that version of the root zone, not whenever that file was > written to the local CDN cache in Farawayistan.
Hi, HTTP has a mechanism for performing conditional requests based on the ETag and If-None-Match headers, see RFC 9110 [0,1] for details. This lets a client with a previously downloaded copy of the file perform a conditional GET and either get a contentless 304 (Not Modified) response or the new version of the content. The ETag can be set arbitrarily by the origin, and if multiple CDNs (or, more generally, more than one webserver) are involved in serving a DNS zone file over HTTP, it would be nice to have an interoperable method for deriving an ETag from a DNS zone file and a recommendation that DNS-zone-file-transfer-over-HTTP clients/servers should use that ETag value to perform conditional requests. For instance, perhaps the serial field extracted from the zone's SOA RR, or the digest field extracted from the zone's ZONEMD RR (if present) would be suitable as an ETag value. The downside of using a custom ETag value is that it would probably require a custom HTTP origin that can extract the ETag value to be used from the zone, and that also supports the If-None-Match + ETag conditional request semantics. If you use the static file serving capability built into off-the-shelf HTTP servers, these implementations may have an automatic ETag response header generation feature which is not interoperable, and is usually derived from the filesystem modification timestamp and file size, anyway, which has the same problem as relying on the timestamp in a Last-Modified header, when that timestamp is taken from the filesystem. [0]: https://www.rfc-editor.org/rfc/rfc9110.html#name-etag [1]: https://www.rfc-editor.org/rfc/rfc9110.html#name-if-none-match -- Robert Edmonds _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
