Explain DNS TTL Like I'm five

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 that "full propagation can take 2-3 days," so I always set the TTL to the lowest possible time.

Why choose 1 day when I can choose 2 minutes?

What's happening "under the hood" and when should I choose a short TTL versus a long TTL?

Please, explain it like I'm five!

Did you find this post useful? Show some love!

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

Classic DEV Post from Jan 4

It's Just Syntactic Sugar

I've read/heard people express themselves like this many times when talking abo...

Follow @chrisvasqm to see more of their posts in your feed.
Peter Kim Frank
Working on dev.to. Previously: on-demand tutoring and textbooks. Before that, ran/sold an online community and worked for the company that built Tinder. ๐Ÿ˜Ž
More from @peter
Explain Required Downtime Like I'm Five
Is Bitcoin vulnerable to a "bank run"?
#discuss #explainlikeimfive #bitcoin
Trending on dev.to
Why do developers have the toughest interviews in the world?
#interview #developer #discuss
Linux distro you are using for development?
#discuss #development
Explain it to me like I'm five: .map, .reduce, & .filter edition
#explainlikeimfive #javascript #arrays
Learning to think like a programmer.
How do you keep track of what you're reading?
Explain Callback Like I'm Five
#explainlikeimfive #beginners #javascript
Explain RxJS Like I'm Five
#explainlikeimfive #javascript
Learn New Technology as a Way of Stepping Up Your Understanding of Your Current One