What Is TTL? IP Hop Limit and DNS Cache TTL Explained
The three-letter acronym TTL (Time to Live) means two completely different things depending on context. In IP networking, TTL is a hop counter in the IP packet header that prevents routing loops from consuming the network indefinitely. In DNS, TTL is a cache duration attached to resource records that controls how long resolvers and clients may cache a response. Both concepts use the same name and share the same fundamental purpose — limiting the lifespan of data in a system — but they operate by entirely different mechanisms and have nothing to do with each other beyond the name.
IP TTL: The Hop Counter
The IP TTL field occupies 8 bits in the IPv4 header (defined in RFC 791) and the equivalent Hop Limit field in IPv6 (RFC 8200). The field was originally conceived as a time measurement — the name "Time to Live" comes from the idea that a packet would be discarded after it had been in the network for too many seconds. In practice, routers always decrement the field by exactly 1 per hop rather than by elapsed time, making it a pure hop counter. The IPv6 specification acknowledged this reality by renaming the field "Hop Limit."
The purpose is loop prevention. Without TTL, a packet caught in a routing loop — caused by a transient misconfiguration, a BGP route leak, or a software bug — would circulate forever, consuming bandwidth and router CPU on every iteration. With TTL, the packet is dropped after traversing a bounded number of hops.
When a router decrements the TTL and the result is zero, it drops the packet and sends an ICMP Time Exceeded message (type 11, code 0) back to the packet's source. The ICMP message includes the IP header and first 8 bytes of the original packet, allowing the sender to identify which packet triggered the response.
Default TTL Values by Operating System
| Operating System | Default TTL |
|---|---|
| Linux (most distributions) | 64 |
| macOS | 64 |
| Windows (all modern versions) | 128 |
| Cisco IOS (routers) | 255 |
| Solaris / AIX | 255 |
| FreeBSD / OpenBSD | 64 |
| Android / iOS | 64 |
These defaults are not enforced by any standard; they are implementation choices. RFC 1122 recommends a default of at least 64. The common values 64, 128, and 255 reflect practical reasoning: 64 is large enough for any real internet path (the maximum traceable path length is rarely above 30 hops), 128 provides extra headroom, and 255 is used where the device wants to ensure packets are never accidentally dropped due to TTL exhaustion.
How Traceroute Exploits TTL Expiry
Traceroute is the canonical example of a tool built entirely on TTL mechanics. The technique works by deliberately sending probes with TTL values starting at 1 and incrementing. Each probe expires at a successive hop, and that hop's router sends back an ICMP Time Exceeded message. By capturing these messages and recording the source IP of each one, the tool builds a map of the route to the destination.
The classic Unix traceroute sends UDP probes to high-numbered ports (33434 and above). When the destination receives a probe with a surviving TTL, it sends back ICMP Port Unreachable because no service is listening on that port. Windows tracert uses ICMP Echo Request (ping) probes instead. Both rely on the same TTL expiry mechanism for intermediate hops.
TTL-Based OS Fingerprinting
Because different operating systems use different default TTLs, observing the TTL of incoming packets allows inference of the sender's OS. A packet arriving with TTL 118 was almost certainly sent by Windows (default 128, minus 10 hops = 118). A packet arriving with TTL 54 is likely from a Linux or macOS host (default 64, minus 10 hops = 54). Tools like p0f and nmap use TTL as one input in passive and active OS fingerprinting respectively. This technique is imprecise — TTL can be manually set, and the hop count from source to observer varies — but it is useful as a probabilistic signal for intrusion detection, abuse analysis, and traffic characterization.
GTSM: TTL Security for BGP Sessions (RFC 5082)
The Generalized TTL Security Mechanism (GTSM, RFC 5082) uses TTL to provide a lightweight authentication check for BGP sessions and other routing protocols. The mechanism is simple: both BGP peers configure their sessions to send packets with TTL 255. The receiving router accepts the packet only if the TTL is 254 or higher (allowing for one decrement by the remote router's own IP stack before forwarding, or checking after decrement). An attacker attempting to inject spoofed BGP packets from anywhere on the internet would need to route packets through the target's immediately adjacent router — the TTL would arrive far below 254 unless the attacker is on the same physical link.
For eBGP sessions between directly connected peers, GTSM is highly effective. An attacker more than one hop away physically cannot forge a BGP packet that will pass the TTL check, because any packet they send will have had its TTL decremented at every intermediate router. The check is enforced at the receiving router's IP layer before the packet reaches the BGP daemon, making it robust against software vulnerabilities. GTSM is sometimes called "TTL hack" informally, and is supported on all major router platforms. It is complementary to — not a replacement for — proper BGP MD5 or TCP-AO authentication.
DNS TTL: Cache Duration
The DNS TTL is an entirely separate concept — a 32-bit value in every DNS resource record that specifies how many seconds a resolver or client may cache that record. When a DNS resolver receives a response, it starts a countdown timer at the TTL value. Until the timer reaches zero, the resolver may answer queries from cache without contacting the authoritative server. Once it expires, the resolver must query the authoritative server again.
DNS TTLs are set by the zone operator — the owner of the domain. They appear in zone files as a field in every record:
www 3600 IN A 203.0.113.5
^^^^
TTL: cache for 1 hour
The authoritative server does not enforce the TTL; it only publishes it. Resolvers are trusted to honor it, and essentially all compliant resolvers do. The actual cache lifetime visible to a client depends on how long ago the resolver fetched the record — a record with TTL 3600 that was fetched 3000 seconds ago will arrive at the client with TTL 600 (the remaining time).
DNS TTL Strategy
Choosing appropriate DNS TTLs involves a latency/agility tradeoff. Long TTLs mean fewer DNS queries, lower load on authoritative servers, and faster responses from cache. Short TTLs mean that changes propagate quickly at the cost of more queries.
| TTL Value | Typical Use Case |
|---|---|
| 30–60 seconds | Rapid failover, CDN edge entries, pre-migration window |
| 300 seconds (5 min) | Active services needing quick updates |
| 3600 seconds (1 hour) | Common default for most records |
| 86400 seconds (1 day) | Stable infrastructure, MX records, NS records |
| 604800 seconds (1 week) | Rarely changing records, TXT/DKIM |
The standard operational playbook before a DNS migration is: lower the TTL several days in advance (to 60–300 seconds), perform the change, then raise the TTL back after verification. This ensures that the old TTL has expired everywhere before the change occurs, preventing stale cache entries from persisting after the migration.
CDNs typically set very short TTLs on their edge entries — Cloudflare, Akamai, and Fastly often use 60–300 seconds — because they need the ability to shift traffic quickly between points of presence or during incidents. The CDN's authoritative DNS uses short TTLs, but the CDN itself may cache content with separate HTTP cache headers for much longer durations.
Negative Caching: RFC 2308
When a DNS query returns NXDOMAIN (no such domain) or NOERROR with no records (NODATA), the response also carries a TTL — the negative cache TTL. RFC 2308 specifies that resolvers should cache these negative responses for the TTL value found in the SOA record's minimum field (or the SOA TTL itself, whichever is smaller). This prevents repeated queries for nonexistent names from hammering authoritative servers.
The negative TTL is set in the zone's SOA record:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2024010101 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
300 ) ; negative TTL ← this value
Operators sometimes set negative TTLs very low (60–300 seconds) to allow rapid recovery if a domain or record is accidentally deleted and quickly restored. A large negative TTL means NXDOMAIN responses are cached for a long time, causing errors to persist even after the authoritative data is corrected.
DNS TTL and CDN Behavior
Understanding the difference between DNS TTL and HTTP cache TTL (set via Cache-Control and Expires headers) is important. They operate independently. A DNS record pointing to a CDN edge might have a TTL of 60 seconds, allowing rapid traffic steering. But the content served from that edge might be cached for 86400 seconds via HTTP headers. The DNS TTL controls how often clients re-resolve the hostname; the HTTP TTL controls how long the content itself is cached by browsers and CDN nodes.
A common confusion: operators lowering the DNS TTL before a migration expect changes to propagate in TTL seconds. This is correct for new DNS resolutions, but existing connections (established before the TTL change takes effect) and persistent resolvers with their own caching layers may hold the old answer longer. Real-world change propagation often takes 2–3× the TTL value due to resolver caching behavior, negative caching of the old TTL value itself, and load balancers that maintain persistent upstream connections.
TTL in Other Protocols
The TTL concept appears in several other networking contexts, always meaning "how long should this data be considered valid":
- BGP NEXT_HOP reachability — the IGP route to a BGP next-hop has an associated metric and is subject to withdrawal; conceptually similar to a TTL expiring
- ARP cache TTL — ARP entries (IP-to-MAC mappings) age out after a configurable period (typically 4 minutes on Linux) and require re-resolution
- OSPF LSA MaxAge — Link State Advertisements in OSPF have a MaxAge of 3600 seconds; an LSA that is not refreshed within MaxAge is considered stale and removed from the topology database
- Multicast TTL threshold — multicast routers can be configured to require a minimum TTL before forwarding to a scope boundary, providing a crude geographic scoping mechanism
In all cases, TTL serves the same function: bounding the lifetime of state in a distributed system to prevent stale data from causing incorrect behavior indefinitely.
Explore It Live
IP TTL is visible in traceroute output and influences the hop counts visible from BGP path data. DNS TTLs are visible in any DNS query response: