TTL is the great unknown of DNS and, at the same time, the number that decides whether a migration takes you ten minutes or two days. Three letters meaning time to live, and its value is expressed in seconds.
What it actually is
Every DNS record in your domain carries a TTL. That number tells any DNS server in the world how long it may keep the answer in memory before having to ask again.
When someone types your domain into a browser, their ISP looks up the answer and caches it for exactly as long as the TTL says. During that period, every customer of that ISP gets the cached answer, without your DNS server knowing anything about it. It is a brilliantly efficient system: without it, the Internet would drown in repeated queries.
Why it matters in practice
The problem appears when you change something. If your TTL is 86,400 seconds, that is 24 hours, and you change your website’s IP, some ISPs will keep sending their customers to the old server for a full day. You see the new site, your customer still sees the old one, and nobody understands anything.
With a 300-second TTL, that same change propagates in five minutes. The difference between the two situations is a single number you can change with one click.
Typical values and what each is for
- 300 seconds (5 minutes). For change windows. Near-instant propagation in exchange for more queries to your DNS servers.
- 3,600 seconds (1 hour). A good balance for records that change occasionally.
- 86,400 seconds (24 hours). For stable records you will not touch: name servers, verification records.
The low-TTL technique
This is the manoeuvre that separates those who know from those who improvise, and it has three steps:
First, two days before the change, lower the TTL of the record you are going to modify to 300 seconds. Doing it in advance matters: ISPs that already cached the old value, with its old TTL, will take that long to learn about the new TTL. If your TTL was 24 hours, you need 24 hours for the world to know it is now 5 minutes.
Second, make the real change. With TTL at 300, propagation completes in minutes and you can verify it from several networks.
Third, once everything has been stable for a few days, raise it back to an hour or more. That eases the load on your DNS servers and improves response time for your visitors, because their ISP will have the answer at hand for longer.
Common TTL mistakes
Lowering it on the day of the change. It does nothing: the caches that matter still honour the old TTL. You have to plan ahead.
Leaving it low forever. A permanent 60-second TTL multiplies queries against your DNS and adds a fraction of latency to every new visit. For a stable record it makes no sense.
Forgetting that email has TTL too. MX, SPF and DKIM records propagate the same way. If you migrate email, lower their TTL as well, or you will have messages going to the old server.
When TTL is not the culprit
Sometimes a change does not show and TTL has nothing to do with it. The usual causes are your own browser cache, the operating system cache, or an ISP that ignores your TTLs and applies a minimum of its own. In those cases, testing from your phone on mobile data, without wifi, is the quickest way to check whether the change is already in public DNS.
Managing it painlessly
All of this is far simpler with a decent panel and a fast DNS network. Our managed DNS runs on a global anycast network with hundreds of points of presence, changes apply instantly from your client area, and DNSSEC is included. And if you are preparing a full migration, in our hosting plans we handle the whole TTL choreography for you.