DNS TTL Explained: How Caching and Changes Work

DNS TTL explained simply: a record’s time to live is the number of seconds a DNS resolver may keep an answer in its cache before it needs fresh data. A longer TTL reduces repeat lookups but can leave old information in circulation longer after a change. The twist: lowering the setting today does not shorten a cache entry created yesterday.

DNS TTL explained: what the timer controls

DNS, the Domain Name System, is the phonebook of the internet. It maps names such as loqmi.com to the information computers need, often an IP address. A TTL is attached to a DNS resource record (RR) and measured in seconds. The specification defines it as how long the record may be cached before its source should be consulted again. See RFC 1035.

The value belongs to one record or record set, not to the whole domain. An A record maps a name to IPv4; AAAA to IPv6; CNAME points to another name; MX identifies mail servers; TXT carries text; and NS identifies nameservers. Each one can have its own TTL, so an alias and its target may expire at different times.

A recursive resolver does the looking up for your device, often through your ISP, workplace, VPN, or a public DNS provider. The authoritative nameserver publishes the domain’s official records. TTL is the maximum cache window, not a promise that every resolver keeps an answer for the full time.

How DNS caching and the countdown work

Say an answer comes with 3600. A resolver may reuse it for up to 3,600 seconds, or one hour. A response served from cache normally shows the remaining time, not a fresh hour.

At 09:00, a resolver caches shop.example A 192.0.2.40 with TTL 3600. At 09:25, the owner changes the address to 192.0.2.80. The old answer can still have 35 minutes left, like a sticky note nobody has peeled off yet. Setting the published TTL to 300 seconds now does not edit that cached entry. The resolver learns the shorter TTL only after it asks again.

Resolvers ask at different times, so visitors may get different answers. Operating systems and apps keep caches too, adding another layer. Flushing your laptop helps only if its own cache is stale. It cannot clear an ISP or office resolver. Think of several clocks, each started when a resolver last looked.

How to choose a DNS TTL

No single TTL is best for everything. Weigh how often the record changes, how fast a cutover or rollback needs to show up, and how much repeated DNS traffic your service can handle.

Treat these as starting points, not protocol rules. AWS Route 53 guidance treats TTL as a decision for each use case, and providers set their own ranges. For a planned move, lower the TTL well in advance, wait at least the old TTL, change the record, confirm the authoritative answer, then restore a longer value. Setting a five-minute TTL five minutes before a migration is optimistic scheduling.

Very low TTLs can increase queries and may affect cost or performance. A TTL of zero prevents ordinary caching, like asking the receptionist to recheck the directory for every caller. It is rarely a useful default. Check provider limits, especially for managed DNS or load balancing.

Why DNS changes look stuck

“Propagation” is not one worldwide countdown. Each cache expires on its own schedule. A nameserver move can also involve parent-zone delegation data, which is separate from a website’s A record. Changing your device’s resolver is a different job from editing public records. See how to change your DNS server.

Negative caching is easy to miss. The SOA (Start of Authority) record carries zone information. Its TTL and minimum field decide how long an authoritative negative response may be cached, under the rule in RFC 2308. A nonexistent record cannot set its own cache time, like a “Back in five minutes” sign on a shop that never opened.

How to check a record’s TTL

Start with the hostname and record type, then query the authoritative nameserver and your recursive resolver. With dig, try dig www.example.com A. The TTL appears beside the answer. To ask a particular resolver, use dig @1.1.1.1 www.example.com A. A recursive response usually shows the remaining cache time.

On Windows, nslookup -type=A www.example.com shows the answer and the server that responded. The output varies, and it may not make the TTL easy to read. Microsoft documents Resolve-DnsName for more detailed checks. dig is common on macOS and Linux. These commands only inspect DNS. They do not change your device’s DNS server.

Compare the same name and type at the same time. If the authority is right but a recursive answer is old, that resolver’s cache is the likely cause. If the authority is wrong, clearing a laptop cache will not fix the zone. For background, read what DNS is, or check your public IP address.

DNS TTL myths that cause confusion

• “TTL is how long a packet travels.” No. DNS TTL measures cache time in seconds. The IP packet TTL, called the hop limit in IPv6, is a separate field that limits how many network hops a packet can make. Same abbreviation, different stopwatch.
• “A lower TTL makes every change instant.” No. It only affects answers fetched after the new value is published and old caches have expired. It cannot reach back and shorten existing entries.
• “One TTL covers the whole domain.” No. Different records, aliases, delegation, and negative answers can each have their own cache lifetime.
• “A slow website means its DNS TTL is too long.” Not necessarily. TTL can affect lookup freshness and how often your device asks again, but it does not add bandwidth or speed up page delivery. A speed test measures your internet connection, not the DNS TTL. If you are checking connection speed, try the Loqmi speed test.

DNS TTL is separate from HTTP or CDN cache lifetimes. DNS gets a device to an address, and a web cache can keep page files after that. Updating one timer does not purge the other. For the IP a name resolves to, see how to find a website’s IP address.