View plans

Domains and DNS

DNS propagation: why your domain change is not showing yet

DNS changes are not pushed out to the internet. Resolvers keep old answers until their cache time (TTL) runs out, so a change can look live for you and stale for someone else for anywhere from a few minutes to 48 hours.

Updated 4 min readApplies to: All plans

What is happening when DNS "propagates"

You changed your nameservers or a DNS record, and the website still opens the old server, or opens for you but not for a customer in another city. Nothing is broken. DNS answers are cached by resolvers (the DNS servers run by your ISP, your office router, Google, Cloudflare and others), and each cached answer carries a TTL (time to live) in seconds. Until that TTL runs out, the resolver keeps serving the old answer.

So "propagation" is really old caches expiring one by one. If you are new to how DNS fits together, read what DNS is and how it works first.

How long it usually takes

What you changed Typical wait Why
An A, CNAME, MX or TXT record in the same DNS zone Up to the old record's TTL, often 1 to 4 hours Resolvers drop the old answer when its TTL ends
Nameservers at your registrar A few hours, up to 48 hours The registry's NS records for your domain are cached for longer (for .com the delegation TTL is 48 hours)
A record that did not exist before Up to the zone's negative cache time Resolvers also cache "this record does not exist" answers (RFC 2308)

The last row catches many people: if you visited shop.yourbusiness.in before creating it, your resolver may remember that it did not exist for a while.

How to check propagation

  1. Find which nameservers your domain uses now:

    dig NS yourbusiness.in +short

    On Windows without dig, use nslookup -type=ns yourbusiness.in.

  2. Query one of those nameservers directly. Replace the nameserver with one returned in step 1:

    dig @ns1.your-dns-provider.example yourbusiness.in A +short

    If this shows the new value, your change is published correctly and the rest is just caching. If it shows the old value, the change was not saved, or you edited DNS at a provider your domain no longer uses.

  3. Compare with large public resolvers:

    dig @8.8.8.8 yourbusiness.in A
dig @1.1.1.1 yourbusiness.in A

    The number before IN A in the answer section is the remaining TTL in seconds. That is roughly how long that resolver will keep the old answer.

  4. Use an online DNS propagation checker that queries resolvers in several countries. Treat it as an indication only, because it shows those specific resolvers, not your customers'.

  5. Flush your own caches so you are not fooled by your own computer:

    # Windows (Command Prompt or PowerShell)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

    Chrome also keeps a cache: open chrome://net-internals/#dns and click Clear host cache.

  6. Preview the site on the new server before DNS finishes by adding a line to your computer's hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS and Linux) with the server IP from your welcome email, for example 203.0.113.10 yourbusiness.in www.yourbusiness.in. Remove the line when you are done.

How to make the next change faster

  1. Lower the TTL of the records you plan to change to 300 seconds (5 minutes) at least one full old TTL before the change. If the current TTL is 14400 (4 hours), lower it more than 4 hours in advance.
  2. Change individual records instead of nameservers when you only need to move the website. An A record update follows the record TTL, while a nameserver change depends on the registry. See A record vs CNAME for which record to edit.
  3. Avoid flipping values back and forth. Each change starts a new caching cycle in different resolvers.
  4. Keep the old hosting and mailboxes running for 48 hours so visitors and emails reaching the old server are not lost. This matters most during a website migration.
  5. Raise the TTL back to a normal value, such as 3600 or 14400, once everything is stable.

How to confirm it worked

  • dig @8.8.8.8 and dig @1.1.1.1 both return the new value.
  • The site loads from a phone on mobile data with Wi-Fi switched off.
  • A test email sent from an outside account (Gmail, Outlook.com) arrives in the new mailbox if you changed MX records.

If it still is not working after 48 hours

Something other than caching is usually wrong: the nameservers at the registrar were not saved, the record was added in the wrong DNS zone, or DNSSEC at the registrar still points at the old DNS provider. Check the steps in pointing your domain to ODHOST nameservers, then open a support ticket with:

  • The domain name and what you changed (nameservers or which record), with the old and new values
  • When you made the change, with date and time in IST
  • The output of dig NS yourbusiness.in +short and dig @8.8.8.8 yourbusiness.in A
  • What you see in the browser, including any error message

Frequently asked questions

How long does DNS propagation take?

A record change inside an existing zone usually shows everywhere within the old record's TTL, often under four hours. A nameserver change can take up to 48 hours because the registry's delegation records are cached for longer.

Can I force DNS propagation to finish faster?

Not for other people's resolvers. You can flush your own computer's cache and test against public resolvers, and next time you can lower the TTL a day before the change so caches expire sooner.

Why does my site work on mobile data but not on my office Wi-Fi?

Each network uses its own DNS resolver, and each resolver cached the old answer at a different moment. The office resolver will update once its cached copy expires.

Will my email stop during propagation?

It can be split for a while, with some senders delivering to the old mail server and some to the new one. Keep the old mailbox active for at least 48 hours after changing MX records or nameservers.

Sources and further reading

Contact us