[dns-operations] prefetching and thundering herds

[Roy Arends]

I the java version of unbound, we had an option to set a TTL in a response from the caching resolver to the stub resolver to, say, 1 minute. The purpose of this was so that you can’t “probe” a caching resolver to see exactly when a record expires in case you wanted to mount a spoofing attack against the cache. This was pre Kaminsky.

This would seem to defend against a thundering herd, at the cost of an increased load.

Roy

> On 15 Jul 2020, at 12:42, Tony Finch <dot at dotat.at> wrote:
> 
> I've been wondering about the effects of stub resolvers with caches as
> clients of recursive servers. To what extent do they cause a thundering
> herd effect where all the cache entries expire with the same deadline?
> The herd will arrive when the RRset expires so most of those clients will
> hit maximum latency and stress the server's query deduplication mechanism.
> 
> (I don't think I have enough traffic to get a useful answer from my
> servers right now.)
> 
> If thundering herds happen, do they thunder enough to help explain the
> lack of benefit from prefetching observed by PowerDNS?
> 
> Or maybe is the herd is too small to thunder? Instead there's a more
> gentle swell of queries after the TTL expires?
> 
> https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018605.html
> 
> If there is much of a herd, would it make sense to give some proportion of
> the clients a slightly reduced TTL so that they will trigger prefetch
> before the rest of them requery?
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
> Bailey: Southwest 4 or 5, increasing 6 or 7 later. Moderate or rough,
> occasionally very rough later in far northwest. Drizzle, fog patches. Moderate
> or poor, occasionally very poor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations