DNS TTL Explained: What It Means, How to Set It, and How to Check It

This article is a localized edition of the Japanese original. Read the Japanese original

The DNS TTL (Time To Live) is the number of seconds a caching server (a recursive resolver, such as your ISP's or Google Public DNS) may keep a record it received from the authoritative DNS server. If the TTL is 3600, a lookup result can be cached for up to one hour, and even if you change the record on the authoritative DNS server during that time, people using that caching server still get the old value.

Most cases of "I changed my DNS but it isn't taking effect" come from cached records that are still within their TTL. This article covers how to choose a TTL, how to lower it for a server move, how to write it in BIND, and how to check that changes have propagated.

Where the TTL applies

A DNS lookup flows in this order:

1. A computer or smartphone asks its configured caching server for a name
2. If the answer is not in its cache, the caching server asks the authoritative DNS server
3. The authoritative DNS server returns the record and its TTL
4. The caching server remembers the result for that many seconds and answers from its cache after that

The TTL is set on the authoritative side (by whoever manages the domain's DNS) and honored by the caching servers. Shortening the TTL does not affect results that are already cached: they stay until the TTL they were received with expires.

How to choose a TTL

A short TTL makes changes spread faster, but caching becomes less effective and the authoritative DNS server gets more queries. The basic approach is to keep it long normally and shorten it only before a change.

Lowering the TTL for a server move

When you move a WordPress site to another server, proceed in this order:

1. Lower the TTL before the move: Set the TTL of the relevant A records (including www) to 300.
2. Wait for the old TTL to pass: If the old TTL was 86400, wait at least one day after lowering it. This lets the caches holding the old, long TTL expire, so every caching server re-queries every 300 seconds.
3. Switch the IP address: Change the A record to the new server's IP address. Most visitors will reach the new server within about five minutes.
4. Keep both servers running for a while: Some caching servers do not honor the TTL, so do not shut the old server down right away; check its access log and stop it once traffic has stopped arriving.
5. Restore the TTL: Once the new server is working, set the TTL back to 3600 or similar.

If you skip step 2, lowering the TTL to 300 does not help right away, because caches handed out before the change still hold the long TTL, and the switch will not spread quickly.

For troubleshooting slow propagation, see also "What to check when DNS changes are not taking effect".

Setting the TTL in a DNS provider’s control panel

If you use the DNS service of your hosting provider or domain registrar, the record edit screen has a TTL field. The range of values you can choose differs by service, so check your provider's documentation.

For Cloudflare (official documentation as of November 2026):

• Records that are not proxied (DNS only): the TTL can be set from 60 seconds (30 seconds on the Enterprise plan) up to 1 day
• Proxied records (Proxied, the orange cloud): the TTL is fixed at "Auto" (300 seconds). Visitors receive Cloudflare's IP addresses, so changing the origin server's IP does not affect visitors' caches

Setting the TTL in BIND

If you run BIND yourself, the TTL goes in the zone file, not in named.conf. There is no ttl option inside a zone statement in named.conf.

Here is an example zone file (replace example.com with your own domain):

$TTL 3600
$ORIGIN example.com.
@       IN  SOA  ns1.example.com. hostmaster.example.com. (
                 2026111001 ; serial number
                 12h        ; refresh
                 15m        ; retry
                 4d         ; expire
                 1h         ; negative caching TTL
                 )
        IN  NS   ns1.example.com.
        IN  NS   ns2.example.net.
ns1     IN  A    192.0.2.2
@       IN  A    192.0.2.10
www 300 IN  A    192.0.2.10

• $TTL 3600: The default TTL for records that do not specify one. You can also use units, such as 2d (2 days) or 12h.
• www 300 IN A ...: A number after the name sets the TTL for that record only, here 300 seconds. Use this form when you want to lower only some records before a move.
• The last SOA value: How long a "this name does not exist" (NXDOMAIN) answer is cached (RFC 2308). If someone looks up a name before you create the record, the "does not exist" answer stays cached for this long.

Applying the change

File locations differ by distribution. On Debian and Ubuntu they are under /etc/bind/ (zones are declared in /etc/bind/named.conf.local); on RHEL, Rocky Linux and AlmaLinux the defaults are /etc/named.conf and /var/named/.

1. Increase the SOA serial number (in the example above, change 2026111001 to 2026111002). Secondary servers transfer the zone again only when this number goes up.
2. Check the syntax, then reload just that zone.

# Check the zone file syntax (adjust the file path to your setup)
sudo named-checkzone example.com /etc/bind/db.example.com

# Reload only this zone
sudo rndc reload example.com

If you changed named.conf itself, check it with sudo named-checkconf and then run sudo rndc reconfig (or restart the service).

Checking the TTL with dig

The second column of dig output is the TTL.

# Ask the authoritative DNS server directly (shows the configured TTL)
dig @ns1.example.com www.example.com A +noall +answer

# Ask a caching server (shows the remaining seconds)
dig @8.8.8.8 www.example.com A +noall +answer

Example output:

www.example.com.    300    IN    A    192.0.2.10

When you ask the authoritative DNS server, you always get the configured value (300 here). When you ask a caching server, you get the time remaining in its cache, so the number goes down each time you repeat the query. If the number stays large, a cache with the old, long TTL is still around.

If dig is not installed, it is in the bind9-dnsutils (dnsutils) package on Debian and Ubuntu and in bind-utils on RHEL-based systems.

Summary

• The TTL is how many seconds a caching server keeps a record, and it is set on the authoritative DNS server
• Use 3600 seconds or more normally; lower it to about 300 seconds only before a server move, and switch the IP address after the old TTL has passed
• In BIND, write the TTL with $TTL and per-record numbers in the zone file, increase the serial number, and apply it with rndc reload
• Check the TTL in the second column of dig output, and compare the answers from the authoritative DNS server and a caching server

The overall DNS resolution flow is explained in "How DNS name resolution works".

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)