Tiny Bits: DNS TTLs
Often overlooked but still important: The right choices for your DNS TTLs. tl;dr Make them longer!
Published (modified ) by Philipp Trommler. This article has also been translated to: de.
This blog post I've found via Hacker News talks about the importance of the right choices for DNS TTLs. These values tell anyone asking how long the DNS entry should be considered valid before the DNS server should be asked again (how long the value can be cached). The caching duration has impact on various topics: The named article talks of latency, privacy and reliability, and I'll add the environment. A busy DNS server has a higher energy consumption than an idling one (let alone the intermediate networking gear)! Those are more than enough reasons for me to take this seriously.
The cited article suggests a TTL of at least 40 minutes (2400 seconds) or
– better – one hour (3600 seconds), because the latter can
theoretically decrease the number of needed DNS queries down to 17 %! So
– of course – I've decided to check my own settings in order to make
them comply with the suggested settings. Using drill I got the following value
for my blog:
1 | |
Ouch! The first miss. That's only 30 minutes for a domain that will probably never change. Let's check my old blog:
1 2 3 4 5 | |
Here I even get embarrassed by Github, that choose the right values. From here on the value for my CV website is quite unsurprising:
1 | |
Setting these values is easy, though, you can do this usually in the web frontend of your domain registrar. This is what I've done and when you now check my domain you should see 60 minute TTLs everywhere.
What can you do? Well, if you're a domain holder, you can do as I did and choose appropriate TTLs. If you're an end user, well, your options are few. The one I took is Pi-hole. Apart from its ad-blocking capabilities, it also caches DNS requests and thus lowers the number of public observable DNS queries that leave your home network even further.
But you can go even further by adjusting the settings of dnsmasq, the DNS
server underlying Pi-hole. In an up-to-date Pi-hole installation you can add
custom settings to dnsmasq by creating an additional file in /etc/dnsmasq.d/
and putting your configuration options in there.
To increase the minimum TTL for all domains requested via Pi-hole
min-cache-ttl is the right value. Of course you could just set it to 2400 in
order to give all your network clients a TTL of 40 minutes for all domains. But
keep in mind that this may break sites making use of services like Cloudflare or
that use their DNS entries for load balancing. But even setting a value of 300
(five minutes) should decrease the number of DNS queries needed significantly
without breaking too much. Thus, the content of the newly created configuration
file should be the following:
1 | |
Additionally you could set a TTL for all blocked domains by using local-ttl
but alas Pi-hole already sets this value in an automatically regenerated config
file and dnsmasq doesn't allow you to override options. Thus, your only chance
to change this value is to edit /etc/dnsmasq.d/01-pihole.conf after each
upgrade. If you do, you can choose a really high value since you don't want to
visit those sites anyway. In that case you have to set dhcp-ttl to zero as
well, though, in order to prevent the former setting to have influences on your
DHCP (see dnsmasq(8)). Keep in mind that whitelisting a mistakenly blocked
domain may take up to local-ttl seconds to have an effect!
I hope I could arouse some interest for DNS TTLs. If not, I urge you to have a look at the aforementioned article again. Happy configuration!
Filed under Tiny Bits. Tags: dns, web, pi-hole.
Want to comment on this article? Write me at blog [at] philipp-trommler [dot] me!