On Sun, Mar 27, 2016 at 08:28:04PM +0000, Warren Kumari wrote: > So, most implementations do some sort of prefetch thing now, and so the > primary purpose of "hammer" has been achieved. But, I think it is still > worth documenting the behavior. I'm planning on updating and then asking > DNSOP to adopt and then publish this sometime...
From the draft:
> 5. Update of cached data
>
> In order to maintain the data freshness, the cache should be updated
> continually based on the behavior of stub resolvers or the statistics
> of domain names. For the former case, the data is updated when the
> stub resolver requests the specified domain name. While for the
> latter case, the recursive server pre-fetches the hot domain names
> before expiration and updates them actively.
FWIW, Shane, Stephen and I have been sorting out the details of
opportunistic whole zone cache refresh, an alpha draft version of which
can be found here:
https://github.com/muks/dnsrefresh/blob/master/draft-muks-dnsop-opportunistic-refresh.xml
As the SOA serial is usually meaningful in the context of zone
transfers, we're still discussing the details of why, what, how, etc. It
should've been ready by this IETF, but hopefully we'd have completed an
initial draft by the next one. Feedback to the idea so far has been
mixed.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
