What is TTL in DNS?
By Ash, Founder, HosteazePublished 2 min read
The short answer
TTL (time to live) is a number, in seconds, attached to every DNS record. It tells other servers how long they may keep a copy of that record before asking for a fresh one. A TTL of 3600 means up to an hour, so it controls how quickly your DNS changes reach everyone.

Every DNS record comes with a little countdown attached. When a visitor's internet provider looks up your domain, it keeps the answer so it doesn't have to ask again for the next visitor. The TTL decides how long it may keep that answer before it has to check back with your DNS.
How does TTL work?
- You set a record, for example an A record pointing your domain at your web server, with a TTL of 3600.
- A visitor's resolver (the DNS server their broadband or phone network uses) looks it up and stores the answer.
- For the next 3600 seconds, it answers from that stored copy without asking your DNS again.
- When the time runs out, the copy expires and the next lookup fetches a fresh answer.
The standard defines TTL as a time interval in seconds. RFC 2181 sets the allowed range from 0 to 2,147,483,647 seconds (about 68 years), but nobody sensible goes near the top. Resolvers are also free to cap very long TTLs.
What TTL values are common?
| TTL | In plain terms | Good for |
|---|---|---|
| 300 | 5 minutes | Records you're about to change, or ones that change often |
| 3600 | 1 hour | A sensible default for most small business records |
| 14400 | 4 hours | Records that rarely change |
| 86400 | 1 day | Records that almost never change |
Providers set their own limits. Cloudflare, for example, lets you choose between 60 seconds and one day on its standard plans, and its "Auto" setting means 300 seconds. A quick live lookup shows the big players keep some records short: in October 2026, google.com's A records had a TTL of 300.
Why does TTL matter when I make a change?
Because the old TTL is what everyone is waiting on. If your MX record has a TTL of 86400 and you switch email provider, some mail servers may keep sending to the old one for up to a day. That's the real reason DNS changes take time to appear everywhere.
The fix is to plan ahead:
- A day or two before the change, lower the record's TTL to 300.
- Wait at least as long as the old TTL, so every cached copy has picked up the short one.
- Make your real change. It should now reach almost everyone within about five minutes.
- Once everything works, raise the TTL back to 3600 or more.
This is the single most useful trick when changing MX records or pointing a domain at a new website.
What is negative caching?
Resolvers also remember when a record doesn't exist. If someone looks up a TXT record before you've added it, the "not found" answer is cached too. RFC 2308 says that wait is set by your domain's SOA record (a housekeeping record every domain has), using the lower of its minimum field and its own TTL. So if a brand-new record seems stubbornly missing, an early lookup may be the culprit. Give it a little time before you start editing things again.
Frequently asked questions
What is a good default TTL?
An hour (3600 seconds) is a sensible default for most records on a small business domain. Drop to 300 seconds for a day or two around planned changes, then put it back.
Does a low TTL slow my website down?
Only slightly, and only for the first visit after a cached copy expires, because the visitor's resolver has to ask again. For most small sites the difference is too small to notice, but there's no benefit in leaving every record at the minimum forever.
Why did my change take longer than the TTL?
Usually because the TTL that matters is the old one. Resolvers that cached the record before you edited it keep it for the full old TTL. Your own computer or browser can also cache answers for a while.




