All tools

Guides Domains

How long do DNS changes take?

Updated 5 min read

Short answer

A changed record is live for every resolver that respects TTLs once the old record’s TTL has run out. Resolvers keep a cached answer for the TTL it came with, such as 300 seconds, then ask your DNS host again and get the new one.

A nameserver change usually takes up to 48 hours, because the .com registry hands out your nameservers with a TTL of 172,800 seconds, and nothing in your own DNS settings can shorten it.

What to do: lower a record’s TTL well before you change it, keep the old DNS provider serving the same records for two days after a nameserver change, and ask the authoritative servers directly.

Changed nameservers? The domain expiration checker shows when the registry last updated the domain, with its registrar and statuses. Free, no account. Check a domain

Check what the servers say now

Your DNS host’s nameservers have the new answer as soon as you save it. Ask one of them directly, with recursion off, to see what it serves:

dig +norecurse +noall +answer @hera.ns.cloudflare.com A example.com
example.com.		300	IN	A	172.66.147.243
example.com.		300	IN	A	104.20.23.154

The second column is the TTL: how long, in seconds, a resolver may keep this answer. Now ask a public resolver, which answers from its cache:

dig +noall +answer @1.1.1.1 A example.com
example.com.		140	IN	A	104.20.23.154
example.com.		140	IN	A	172.66.147.243

Captured on October 24, 2026 with dig 9.10.6. Cloudflare’s resolver had this answer cached with 140 seconds left. When that reaches zero, it asks the nameservers again. A second query a moment later showed 30 seconds: a large resolver runs many caches, and each counts down on its own.

If the authoritative answer is right and a resolver’s is old, the change is done; the resolver just hasn’t asked again yet.

A changed record: the old TTL

The TTL is defined in the DNS standard as “the time interval (in seconds) that the resource record may be cached before it should be discarded” (RFC 1035, section 3.2.1). What counts is the TTL of the old record, the one resolvers already hold. Lowering the TTL at the same moment as the change doesn’t help, because caches still have the old record with its old TTL.

So plan ahead:

  1. Lower the TTL, for example to 300 seconds, at least one old TTL before the change. A record with a TTL of 86,400 needs a day’s notice.
  2. Make the change. It reaches every resolver that respects TTLs within the new, short TTL.
  3. Raise the TTL again once you’re sure.

A nameserver change: usually up to 48 hours

Nameservers are set at your registrar, which sends them to the registry. Resolvers learn them from the registry’s servers, and for .com those servers attach their own TTL:

dig +norecurse +noall +authority @a.gtld-servers.net NS example.com
example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.

172,800 seconds is 48 hours, and the registry sets it, not you. Resolvers also see the NS records in the zone itself, with your DNS host’s TTL:

dig +norecurse +noall +answer @hera.ns.cloudflare.com NS example.com
example.com.		86400	IN	NS	elliott.ns.cloudflare.com.
example.com.		86400	IN	NS	hera.ns.cloudflare.com.

A resolver that looked the domain up before the change keeps asking the old nameservers until its cached copy runs out: up to 48 hours for the registry’s copy, or the old provider’s own NS TTL if it kept that one instead. Meanwhile, resolvers that ask for the first time get the new nameservers at once. That split is why a nameserver change can look finished from one network and not from another.

The old nameservers keep answering in the meantime, from their own copy of the zone. example.com shows it: IANA’s nameservers, named in their own copy of its zone, still serve different addresses from the ones Cloudflare serves now:

dig +norecurse +noall +answer @a.iana-servers.net A example.com
example.com.		300	IN	A	23.192.228.80
example.com.		300	IN	A	23.192.228.84
example.com.		300	IN	A	23.215.0.136
example.com.		300	IN	A	23.215.0.138
example.com.		300	IN	A	23.220.75.232
example.com.		300	IN	A	23.220.75.245

So for a nameserver change:

  • Before: recreate every record at the new provider, and check it with dig @<new nameserver>.
  • During the 48 hours: change nothing, or change it at both providers. Leave the old zone in place.
  • After: delete the old zone.

The registrar’s part can add time before the clock even starts. Cloudflare tells new customers to “wait up to 24 hours while your registrar updates your nameservers” (Primary setup). The dig @a.gtld-servers.net command above shows when the registry has the new ones. Other endings have their own registry servers and TTLs; dig +short NS org. lists .org’s, for example.

A record you just created: negative caching

A brand-new record should work at once, unless someone looked it up before it existed. Resolvers cache “no such name” too. An authoritative server includes its zone’s SOA record with that answer, and “its TTL is taken from the minimum of the SOA.MINIMUM field and SOA’s TTL” (RFC 2308, section 5):

dig +norecurse @hera.ns.cloudflare.com A new-name.example.com \
  | grep -E 'status:|IN\s+SOA'
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40172
example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800

The SOA’s TTL and its last field, the minimum, are both 1,800 here, so a resolver that asked too early keeps saying the name doesn’t exist for up to 30 minutes. Create a record before anyone, you included, looks it up.

Clear a public resolver’s cache

Two big public resolvers let anyone ask them to forget a name:

  • Google Public DNS: Flush Cache. Google’s note: “If the registrar or DNS hosting for a domain changed recently, flush the main domain name first before flushing subdomains.”
  • Cloudflare 1.1.1.1: Purge Cache, for one name and record type at a time.

That helps people who use those resolvers. Every other resolver, including your ISP’s and the one in your office, still waits for its own copy to expire.

Sources

All sources were checked on October 24, 2026. The command output comes from our own runs on that date.

Keep reading