What Is TTL? Time to Live in Networking and DNS Explained
TTL — Time to Live — is one of those terms that means two related but different things, and both show up in everyday troubleshooting. One lives in every packet your device sends; the other governs how long the internet remembers a DNS answer.
TTL #1: the packet hop limit
Every IP packet carries a TTL number. Each router that forwards the packet decreases it by one; if it ever hits zero, the packet is discarded and an error goes back to the sender. Purpose: without it, a routing mistake could send packets circling the internet forever, multiplying until links choke. TTL guarantees every packet dies eventually.
Operating systems start packets at characteristic values — commonly 64 (Linux, Mac, phones), 128 (Windows), or 255 (network gear). That's why a ping reply showing ttl=57 suggests a Linux-ish host 7 hops away (64 − 7). Traceroute weaponises this field deliberately — sending TTL 1, 2, 3… to make each router along the path identify itself.
TTL #2: DNS caching lifetime
Every DNS record also has a TTL — in seconds — telling resolvers how long they may cache the answer before asking again. A record with TTL 3600 can be served from cache for an hour; TTL 300, five minutes.
This is the mechanism behind two familiar experiences:
- "DNS propagation" — after changing a domain's records, old cached answers keep serving until their TTLs expire around the world. It's not really propagation; it's caches draining on schedule.
- Fast failover — services that must switch servers quickly keep TTLs low (60–300s), trading more lookup traffic for agility.
Practical TTL wisdom
- Before changing DNS records, lower the TTL a day in advance (e.g. to 300), make the change, then raise it back — the standard migration trick.
- Diagnosing "site moved but I see the old one" — your resolver's cache hasn't expired; flush local DNS or wait out the TTL.
- Reading ping TTLs — sudden changes in the TTL of replies from the same host can reveal a changed route or an interfering middlebox.
Two meanings, one idea: nothing on a network should live forever — packets die after enough hops, and cached answers expire on schedule. When either behaves unexpectedly, knowing which TTL you're looking at is half the diagnosis.
Frequently asked questions
What's a good DNS TTL to use?
3600s (1 hour) balances freshness and efficiency for most records. Use 300s or lower around planned changes; 86400s (a day) suits records that never change.
Can I change my device's packet TTL?
It's tunable in OS settings, but there's rarely a good reason for ordinary users. Carriers sometimes inspect TTLs to detect tethering, which is why the topic surfaces in that context.