In my last post in this series I talked about common DNS record types, in this I am going to be talking about how the concept of TTLs (Time To Live) and caching are used in DNS.
The two concepts are interlinked in DNS, let’s get into it.
TTLs and Caching
In all of my previous posts in this series I used output from the dig tool to explain concepts, this one is going to be no different.
You might have noticed a certain number being present in dig output:
nullrouted.space. 86400 IN A 126.96.36.199
The second number in the answer section after the name you queries for? That is the TTL value. In this example, the TTL is set to 86400s or 24 hours.
Twenty four hours is how long the record should be maintained in our DNS resolver’s cache. Now, the question is, how does a DNS resolver know how to expire an entry in its cache? It’s counts down the seconds.
Like for example if I query the same resolver again shortly after:
nullrouted.space. 86261 IN A 188.8.131.52
You will notice that the TTL has gone down. The DNS resolver will keep decreasing the TTL of this record every second until it reaches 0 at which point it gets removed from the cache. Of course, if you control the resolver (i.e you are running your own), you can flush the cache yourself.
Now you may be asking, can I set the TTL to a different value? Yes, you can, when you add/modify a record at your DNS provider, there is usually a field that lets you control the TTL you wish to set. Yep, this means that the authoritative servers for a domain also are, you guessed it, authoritative for the TTL value.
Caching allows for faster response to DNS queries as it allows resolvers to return answers from their own cache instead of having to send queries further up the chain which takes longer.
I mentioned that DNS resolvers use TTLs for caching but they are not the only things in the chain of DNS software that does caching. In a typical home network there is usually at least three levels of DNS caching happening.
The first is usually your operating system’s DNS cache. Windows for example has a DNS caching layer called “DNSCache” where it uses the TTL returned from the resolver. You can check what this Windows DNS cache contains using the Command Prompt command `ipconfig /displaydns`. You can also flush/clear this cache with `ipconfig /flushdns`.
The second layer is usually your local forwarder which in typical home networks is your router device. The router runs software like dnsmasq which forwards queries to your ISP’s resolvers and then caches answers using the TTL values in the records. Depending on the configurability provided to you via your router’s web interface you may not be able to view the contents of this cache and the only way to clear/flush it might be to power cycle your router.
The third layer is the resolver that is your second layer’s forwarding destination. This is usually your ISP’s resolvers but you may be able to configure your router’s resolvers to use a different set of resolvers like Google Public DNS or Cloudflare’s 184.108.40.206. Those two public resolvers provide ways to flush specific records from their caches but there is no way to view or flush their entire cache.
You can get rid of the second layer if you configure your router to send the public resolver values or your ISP’s resolver values directly via DHCP. How you do that depends on the specific router model you have so if you are interested in that, go look up instructions for your specific router via your favourite search engine.
How long should my TTLs be?
The answer to that question is: “it depends”. It depends whether it is a record with a value that is dynamic or a value that is static over a long period of time. For dynamic DNS records, I would recommend a short TTL like 300s/5m. A typical example of a dynamic DNS record is a record that points at your residential home connection’s IP address which is usually dynamic and can change at any time without notice.
For static records, I would recommend TTLs anywhere between 1hr to 24hr, depending on how long you want records cached for. MX records are usually good candidates for longer TTLs as you are not likely to be switching email providers often.
Personally most of my DNS records have a TTL of 24 hours to maximize use of caching. I initially add records with a TTL of 1 hour just in case it needs changing, after a week or so I change the TTL to 24 hours.
I hope this post answers some basic questions about what DNS TTLs are and how they work in relation to DNS caching.
This is going to be the last in this series of basic DNS concept explainers. I may write more about some other more advanced concepts but those require a little bit more time and research on my part so it will be a bit before those posts are published.
If you missed the previous posts in this series, you can find them all conveniently linked on this page.
Thank you for reading!