Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS

Dave Warren davew at hireahit.com
Thu Mar 24 22:29:17 UTC 2016


On 2016-03-24 15:20, Tony Finch wrote:
> Dave Warren <davew at hireahit.com> wrote:
>> On 2016-03-24 09:46, Ray Bellis wrote:
>>> On 24/03/2016 16:41, Tony Finch wrote:
>>>
>>>>> When I changed our TTLs from 24h to 1h last year, it didn't have a visible
>>>>> effect on authoritative server query load, much to my surprise.
>>> I'm not that surprised - there's definitely not a linear correlation
>>> between the TTL of an RRset and how frequently it's queried.
>>>
>>> Unless your TTL is very short, forced expulsion from cache (due to
>>> cache-size limits) would cause many clients to re-query for a record far
>>> more frequently than once-per-TTL.
>> Has anyone ever done any evaluation on this? For average resolvers, what
>> is the longest TTL that has any utility?
> There was a great paper published 15 years ago describing a study of DNS
> cache effectiveness at MIT. http://nms.csail.mit.edu/projects/dns/
>
> It concluded (amongst other things) that NS records (and associated
> address records) are really important, but leaf records that users ask for
> don't matter so much. (Based on cache hits before TTL expiry, IIRC.)
>
> I don't know of a similar study performed more recently.

The internet was a very different place 15 years ago, in particular, 
this was before every Windows client machine had it's own DNS cache 
service and largely before today's connected mobile devices were a thing.

I'm not sure how mobile devices cache, in particular, whether they clear 
their cache when moving between connections or not (although I suspect 
yes, otherwise there would be more issues with split DNS environments)

My gut feeling is that the findings wouldn't be all that different in 
the end anyway.


> https://00f.net/2012/05/10/distribution-of-dns-ttls/ is also interesting.

Definitely an interesting read, thanks!

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren




More information about the bind-users mailing list