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