On 8/4/23 02:45, Ray Bellis wrote:
On 04/08/2023 00:29, Petr Menšík wrote:
What do you think, would such mechanism be useful even on classic
DNS? Are there already deployed alternatives? How useful something
similar might be? Does such mechanism contain significant drawback,
why it would not be a good idea?
Something like it has been proposed before, around the time of the
previous Yokohama IETF:
draft-muks-dnsop-dns-opportunistic-refresh
Thanks, I haven't noticed this proposal. I think my idea has few vital
advantages to that one.
IIRC, one problem with the proposal is that zone serials are only
intended to be meaningful in the context of zone transfers, and
servers generating dynamic answers may not even use "zones".
Ray
Yes, the opportunistic-refresh proposal were directly bound to entire
zone serial number. While I understand the motivation, my proposal tries
to relate primarily to the change of the record, not the whole zone. It
does not try to reuse queries to different names and records.
I think my proposal can change included SOA to any other identifier of a
change. Be it UUID or just timestamp of last modification of that record
(not whole zone!), it would work the same. Client and server should use
provided server identifier just as a binary blob tested for equality. It
would be up to server to provide whatever works for them. It should work
this way even for database driven provider, which do not rely on always
increasing SOA use.
Perhaps for stable results when querying different servers, few types
like SOA, unix-timestamp or random salt might be defined. For recursive
servers using 4 byte unix timestamp would make it work even without any
support at authoritative server. It would have to just know correct
time. Then it would not matter if it did refresh on 8.8.8.8 or 9.9.9.9
or 1.1.1.1. All them would serve last time of change in this record.
I assume communication from stub to recursive would be the most limited,
so there is the best place to direct transmission savings. I expect
communication in data centers does not need too much traffic reduction,
but may take an advantage if it makes sense. Recursive to authoritative
communication support should be just optional, not required part.
Support on authorative would ensure all recursive servers would have the
same change identifier, improving interoperability. But it would work
just slightly less efficient even without its support.
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
