You just pointed your domain to new nameservers and the site still shows the old host. Or nothing at all. That wait is DNS propagation, and it trips up everyone the first time.
DNS propagation is the period after you change DNS records—usually nameservers—during which the update spreads across thousands of DNS servers worldwide. It's not instant because the internet caches DNS data to stay fast. Think of it as updating a phonebook that millions of people keep local copies of; the publisher sends the new edition, but readers pick it up at different times.
What DNS actually does
The Domain Name System translates human-friendly names like example.com into IP addresses like 192.0.2.45 that servers understand. Without DNS, you'd type IP addresses into your browser for every site.
When you visit a domain, your device asks a DNS resolver (usually your ISP's or a public one like Google's 8.8.8.8) where to find it. That resolver checks its cache first. If the answer is there and still fresh, it returns immediately. Cache miss? The resolver walks up the DNS hierarchy: root servers, then TLD servers for .com or .org, then the authoritative nameservers you configured for your domain. Those authoritative servers hold the real records—A, CNAME, MX, TXT—and hand them back with a TTL.
TTL: the timer that controls caching
TTL stands for Time To Live, measured in seconds. Every DNS record includes one. A TTL of 3600 means "cache this answer for one hour." After an hour, resolvers must fetch it again.
Low TTL (300 seconds, for example) means faster propagation when you change records, but more query traffic to your nameservers. High TTL (86400 seconds, a full day) reduces load and speeds up lookups but makes changes slow to spread. Most hosts default to 3600 or 14400.
Before a big change—migrating hosts, switching nameservers—drop the TTL to 300 a day in advance. After the change propagates, raise it back to reduce query load.
Your first nameserver setup
Let's walk through pointing a new domain to a hosting account. You'll need access to your domain registrar (where you bought the domain) and the nameserver addresses from your host.
Step one: get the nameservers from your host
Log into your hosting control panel. Look for "Account Information," "Nameservers," or a welcome email. You'll see something like:
ns1.yourhost.com
ns2.yourhost.com
Some hosts use IP addresses instead. Either works. Copy both.
Step two: update at the registrar
Log into the registrar account where you registered the domain. Find "DNS Management," "Nameservers," or "Domain Settings." The interface varies (GoDaddy, Namecheap, Google Domains all look different) but the concept is the same.
You'll see a section labeled "Nameservers" with a dropdown: "Default," "Custom," or similar. Switch to custom and paste the two nameserver addresses your host gave you. Some registrars ask for three or four; if your host only provided two, leave the extras blank.
Save. That's it on the registrar side.
Step three: wait and check
Propagation starts immediately but takes time to finish. The registrar pushes the change to the TLD registry (the organization managing .com, .net, etc.), which can take minutes to a few hours. Then every resolver that cached the old nameservers must let that cache expire before querying again.
Worst case? Up to 48 hours if old records had a very high TTL. Typical case: 4 to 24 hours.
You can check propagation with command-line tools or web-based checkers. Open a terminal (or Command Prompt on Windows) and run:
nslookup example.com 8.8.8.8
Replace example.com with your domain. The 8.8.8.8 forces the query through Google's public DNS instead of your ISP's, which might still be cached. You'll see output like:
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
Name: example.com
Address: 192.0.2.45
If the IP matches your new host, propagation reached Google's resolvers. If it's still the old IP or you get NXDOMAIN (domain not found), keep waiting.
Alternatively, use dig on Linux or macOS:
dig example.com @8.8.8.8
Look for the ANSWER section. The IP in the A record should match your new host.
Web-based checkers query DNS servers in multiple countries and show a table of results. Search "DNS propagation checker" and pick any; they all do the same thing. Plug in your domain and record type (usually A for the main domain). Green checkmarks mean that location sees the new data.
Why propagation takes time
Three factors slow it down: TTL on the old records, resolver caching behavior, and registry update speed.
If the previous nameservers set a 24-hour TTL, every resolver that queried before your change won't ask again until tomorrow. You can't force them to drop the cache early. Patience is the only fix.
Some ISPs ignore TTL and cache longer than specified to save bandwidth. Not common with reputable ones, but it happens. If your ISP's DNS seems stuck, manually switch your device to 8.8.8.8 or 1.1.1.1 (Cloudflare) in network settings as a temporary workaround.
The TLD registry update isn't instant either. When you change nameservers at the registrar, the registrar sends an update to the registry database. That can take 15 minutes to several hours depending on the TLD and registrar.
What happens during propagation
Your site might load for some visitors and not others. It's not broken—different resolvers are at different stages. Someone in New York might see the new host while someone in London still hits the old one.
Email can behave the same way if you changed MX records. Messages might deliver to the old server or the new one depending on the sender's resolver. Plan for this: keep the old host active (if possible) until propagation completes, or at least monitor both inboxes.
Common mistakes that extend propagation
Typo in the nameserver address
Double-check spelling. ns1.yourhost.com and ns1.yourhast.com are not the same. A typo means queries fail and your domain stops resolving entirely once the old NS records expire.
Test immediately after saving at the registrar:
nslookup -type=NS example.com
You should see the new nameservers listed. If not, recheck the registrar panel.
Changing nameservers but forgetting to add DNS records at the new host
Pointing to new nameservers only tells the world where to ask. If the new nameservers don't have A records, CNAME records, MX records, etc., queries return empty. I've seen this dozens of times in support tickets: the propagation worked fine, but the zone file on the new host was blank.
After changing nameservers, log into the new host's DNS manager (often in cPanel under "Zone Editor" or a dedicated DNS panel) and confirm your A record points to the right IP, MX records point to the mail server, and any subdomains have the correct entries.
Mixing up A records and nameservers
Some registrars let you manage DNS records directly (A, CNAME, MX) without changing nameservers. That's fine if you want the registrar to remain authoritative. But if you point nameservers elsewhere, records at the registrar are ignored. The new nameservers are authoritative, so records must live there. Trying to manage records in two places causes confusion and doesn't work.
Pick one: manage DNS at the registrar (and don't change NS records), or point NS to your host and manage everything there.
How to speed up future changes
Lower TTL in advance. If you know you'll be migrating next week, set all TTLs to 300 seconds (five minutes) a few days beforehand. After the old high-TTL records expire and everyone has cached the short-TTL versions, your actual change propagates much faster.
Once the migration is stable, raise TTL back to 3600 or 14400 to reduce DNS query load and speed up lookups for visitors.
Checking propagation globally
Your local nslookup or dig only shows one resolver's view. Use a propagation checker or query multiple public DNS servers manually:
nslookup example.com 8.8.8.8 # Google
nslookup example.com 1.1.1.1 # Cloudflare
nslookup example.com 208.67.222.222 # OpenDNS
If all three return the new IP, propagation is well underway. If results differ, some resolvers are still cached on old data.
When the domain just won't resolve
DNS propagation explains delays, not total failures. If 48 hours pass and the domain still returns NXDOMAIN or SERVFAIL everywhere, propagation isn't the issue.
Check these:
- Nameservers are live. Run
nslookup -type=NS example.comand thennslookup ns1.yourhost.comto confirm the nameserver itself resolves to an IP. - Zone file exists. Log into the hosting control panel and verify DNS records are actually configured.
- Registrar lock or hold. Some domains have status codes (clientHold, serverHold) that prevent updates. Check WHOIS or the registrar dashboard.
- DNSSEC mismatch. If the old host used DNSSEC and you didn't disable it before switching nameservers, validation breaks. Disable DNSSEC at the registrar if you're not actively using it.
Frequently asked questions
How long does DNS propagation take?
Typically 4 to 24 hours. The maximum is 48 hours, but that's rare. Most modern infrastructure updates within a few hours if the old TTL wasn't excessively high.
Can I make DNS propagation instant?
No. You can minimize it by lowering TTL before changes, but you can't force cached resolvers to refresh early. The decentralized design of DNS prevents instant global updates.
Why does my computer still see the old IP but online checkers show the new one?
Your operating system caches DNS separately. Flush the local cache with ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, or sudo systemd-resolve --flush-caches on most Linux distros with systemd.
Do I need to do anything after propagation finishes?
Not usually. Once the new nameservers are authoritative and records resolve correctly everywhere, the setup is done. If you lowered TTL before the change, consider raising it back to reduce query traffic.
What if email stops working during propagation?
MX records propagate like any other DNS record. If you changed MX or nameservers, some senders might still deliver to the old server while others use the new one. Keep both mail servers running until propagation completes, or forward mail from the old server to the new one temporarily.
What to check first
When DNS doesn't behave as expected, verify the nameservers updated at the registrar, confirm the new host has a complete zone file with all necessary records, and query multiple public resolvers to see if propagation is partial or stalled. Flush your local DNS cache so your device picks up changes. If 24 hours pass with no progress, the problem usually isn't propagation—it's a configuration mistake, a registrar lock, or a missing record.
DNS propagation is waiting, not troubleshooting. Once you've confirmed the setup is correct, let the internet's caches do their thing.