Skip to content

Explain DNS TTL Like I'm five

Peter Kim Frank on December 18, 2017

When changing DNS settings, I'll sometimes see a TTL ("time to live") field. When I'm adding new records or changing settings, I'm usually warned ... [Read Full]
markdown guide

Your grandma wants to make sure she knows where you're at and how you're doing. She then calls the rest of the family to let them know. Would you prefer she call every day or every 2 minutes?

In this case, your grandma is the authoritative nameserver. The nameserver has to reach out as often as you tell it there might be an update. Getting a call every 2 minutes probably interrupts something in your daily life (and equally can cause delays) when someone requests your site. Using the grandma analogy, she's still trying to update the rest of the family to keep the information from getting stale.

The analogy is a little rough, but hopefully that gives you a more concrete example.


Is it a best practice to only have my grandma call every two minutes if I'm aware there might be some family emergency she should know about? "Uncle Tim is going in for surgery — ping me every two minutes to see how he's doing" type of thing?

Is there a risk that by having her call every two minutes, every day, forever, that she could jam up my phone line for other important calls? Or is it just not a good practice if it's not necessary to be a good-citizen of the other users of this telecom?

Thanks for the explanation! Super interesting stuff.


It is really dependent on your needs. I have historically done 24 hours, but needed to temporarily change it to 20 minutes because I'm deploying a new microsite, trying to update some other minor feature that relies on DNS records, etc. As a result, I had to wait 24 hours after I set it to 20 minutes in order for the update to take place.

Best practice for making a change: if your TTL is X, then X units of time before you need to make a change, update it to 5 minutes.

A higher TTL reduces the perceived latency of a site and decreases the dependency on the authoritative name servers. It isn't necessarily jamming the phone line, which is where the analogy fails. It takes more hops to get the correct nameserver information back thus the increase in perceived latency. A longer TTL/less perceived latency means the information has been cached on a nameserver (non-authoritative) that is a shorter hop between the end-user and DNS information that isn't yet stale.


Let's say you want to make a phone call to Bob, but you don't know his cell number. Luckily you have this phone book which say Bob's phone number is +1 XYZ 999 001. But what if Bob want change his number? How to decide should I buy or update phone book each day/month/year to know for sure that I will find most actual records there? In other words TTL is the interval you can trust that Bob's phone record will be consistent with Bob's most recent cell number.


If you lower the TTL DNS servers will have to refetch your entry more often from 'upstream'. So getting the address could take a little longer.

From Wikipedia

The Domain Name System is maintained by a distributed database system, which uses the client–server model. The nodes of this database are the name servers. Each domain has at least one authoritative DNS server that publishes information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root name servers, the servers to query when looking up (resolving) a TLD.

Edit: emphasis changed


A DNS TTL is like how long it takes me to remind you to go turn out the light when you leave a room. That time while the light is on after you left is the time it was allowed to live. If you need to turn the light back on, you can turn it on again and reset that time to live.


SHORT TTL leads to high number of query's to authoritative DNS and have slow propagation over worldwide,while higher TTL value is vice versa.
if you have 2 different subnet wan IP for service, so you can use short TTL value suppose 15 minutes , if one of your service provider is down you can change with another one so downtime is around 15 minutes

code of conduct - report abuse