Ever changed a domain’s nameserver and waited … and waited? You triple-checked the settings at your registrar, but hours later, some visitors still see the old site. Welcome to the world of DNS TTL.

TTL — Time-To-Live — is the single most misunderstood concept in DNS. It’s also the reason seemingly simple changes can take days to fully take effect.

Let’s break down what TTL actually is, why NS records are the worst offenders, and how to plan changes that won’t keep you up at night.

What Is TTL, Really?

TTL is a number, measured in seconds, that tells DNS resolvers and clients how long they can cache (store) a DNS record before checking for a new version.

Think of it like the expiration date on a food product. Before the date, you consume what’s in the fridge. After the date, you check if it’s still good — and if not, you go buy a fresh one.

When your browser looks up example.com, the recursive resolver (your ISP’s DNS server, or Cloudflare’s 1.1.1.1) returns not just the IP address, but also the TTL for that record::

example.com.  3600  IN  A  93.184.216.34

The 3600 is the TTL — 3600 seconds = 1 hour. The resolver stores this record in its cache and serves it to anyone who asks for the next hour. After that hour, it discards the record and performs a fresh lookup.

Primitive Host captures: TTL values are part of every DNS record we resolve. When we enrich domain data across 276M+ domains, TTL helps us understand record stability — a very short TTL (60 seconds) often indicates a domain behind a load balancer or CDN, while very long TTLs (86400+ seconds) suggest static infrastructure.

How TTL Creates the “Propagation Delay”

When you update a DNS record at your registrar or DNS provider, the change takes effect instantly on the authoritative nameserver. The problem is that the old value is still cached in thousands — sometimes millions — of recursive resolvers around the world.

Here’s what happens step by step:

1. You change example.com’s A record from 1.2.3.4 to 5.6.7.8 at your DNS provider. The authoritative server now returns 5.6.7.8.

2. A user in New York requests example.com. Their ISP’s resolver has the old record cached (TTL hasn’t expired yet), so it returns 1.2.3.4. The user sees the old site.

3. A user in London requests the same domain. Their ISP’s resolver has no cached record (or its TTL expired), so it queries the authoritative server and gets 5.6.7.8. The London user sees the new site.

4. Over the next few hours, each resolver’s cache expires at a different time, and the new record gradually spreads worldwide.

This staggered rollout is what people call “DNS propagation.” It’s not a deliberate distribution mechanism — it’s simply the result of millions of independent caches expiring at different times.

See it in action: Use the DNS lookup services to query records across multiple resolvers simultaneously. You’ll often see different results depending on which resolver you query.

Why NS Record Changes Take the Longest

Nameserver (NS) records — the records that tell the world which DNS servers manage your domain — have the longest TTLs of any record type. Here’s why.

TTL Inheritance at the Registry Level

When you register a domain, the TLD registry (for example, Verisign for .com) stores your NS delegation with a TTL set by the registry — typically 172,800 seconds (2 days) or longer.

The registry-level TTL is what makes NS changes slow. Even if you lower the TTL on your DNS provider’s NS records, the delegation TTL at the registry level is what most resolvers actually cache. That TTL is outside your control.

Adding Insult to Injury: Glue Records

NS records often come with glue records — A records for the nameservers themselves. These also have TTLs. If your nameservers change IP addresses, both the NS record and the glue record need their TTLs to expire before the change is fully visible.

Primitive Host captures: We track NS record changes daily across all monitored domains in our Domain Lists. When a domain’s NS records change — indicating a DNS provider switch or potential hijack — we flag it immediately, regardless of TTL. This is one of the most valuable signals for threat detection.

Practical Example: Changing Nameservers

Say you’re moving yourcompany.com from GoDaddy’s DNS to AWS Route53 on a Friday afternoon.

1. You update the NS records at your registrar to point to Route53.
2. The registry (Verisign for .com) updates its delegation within minutes.
3. But most recursive resolvers cached the old delegation with a 2-day TTL.
4. For up to 48 hours, some visitors’ resolvers will still try to reach GoDaddy’s nameservers.
5. If you already deleted the zone at GoDaddy, those visitors get SERVFAIL — your site is down for them.

The golden rule of DNS migrations: always overlap your old and new DNS providers for at least 2–3 full TTL cycles.

“DNS Propagation” Is a Myth

The term “DNS propagation” implies there’s an active process pushing your change to every DNS server on the internet. There isn’t. There’s no central authority broadcasting updates.

What actually happens:

• You change a record on your authoritative nameserver (the one true source).
• Recursive resolvers query that server only when their cached copy expires.
• Until expiration, each resolver serves the stale value independently.

This is actually a feature, not a bug. Caching is what makes DNS fast. Without TTL caching, every single web page load would require a full DNS resolution chain — root servers to TLD servers to authoritative servers — adding hundreds of milliseconds to every request. The internet would be unusably slow.

TTL Best Practices

For Normal Operations

Before a Planned Change

Lower the TTL ahead of time. This is the single most effective strategy for fast DNS changes:

1. 72+ hours before: Lower all relevant record TTLs to 300 (5 minutes).
2. Make the change: Update the records during the low-TTL window.
3. Verify: Confirm the change propagated to your key resolvers.
4. After 24 hours: Raise TTLs back to normal operating values.

This approach works because by the time you make the change, all the resolvers that cached the old records have already expired them (since the TTL was reduced to 5 minutes).

Pro tip: Our DNS data services can help you verify propagation by querying multiple resolvers simultaneously to confirm your changes have taken effect everywhere.

How Primitive Host Deals with TTL

At Primitive Host, we deal with DNS data at scale — millions of domains, hundreds of millions of records, updated daily. TTL is a constant consideration:

• Record resolution: When we resolve A, NS, MX, CNAME, and TXT records, we respect TTL for staleness detection. Records with very short TTLs get re-resolved more frequently.

• Change detection: We compare current records against previous snapshots daily. A change in NS records (even if the old value is still cached across most resolvers) shows up in our data immediately — giving you early warning of infrastructure shifts.

Summary

TTL isn’t a bug in DNS — it’s what makes the system fast enough to power the modern internet. But understanding how it works is the difference between a smooth migration and a sleepless weekend.

Want to explore DNS data without waiting for TTL? Browse our Domain Lists for live records across all TLDs, or check out our pricing plans for API access and daily updates.