Why is my website not loading after changing DNS?

Sajjad
DNS
10 Oct, 2026

If your website isn't loading after you changed DNS, the most common reasons are that resolvers are still serving the old cached record, the new record has a mistake in it, you edited DNS at a provider your domain doesn't actually use, an old AAAA (IPv6) record still points at the previous host, or the new server hasn't been set up to serve your domain and its SSL certificate. Start by asking your authoritative nameservers what they're publishing, then test the new server directly with curl --resolve, which bypasses DNS entirely. Between those two checks, you'll know whether the problem is DNS or the server.

A DNS change touches several systems at once: your DNS provider, resolvers around the world, the new hosting server, and any CDN in between. When something breaks, it's easy to blame "propagation" and wait, when the real problem is a typo that will never fix itself. This guide walks through a methodical diagnosis, explains the most common causes in detail, and shows the exact commands to confirm each one.

First, Identify the Symptom

"Not loading" can mean several different things, and each points to a different cause. Note exactly what you see:

Symptom	What it usually means
Browser says the site can't be found (NXDOMAIN, ERR_NAME_NOT_RESOLVED)	The DNS record is missing, or the domain's nameservers are wrong
Old website still appears	Caching, or the record still points at the old server
Connection timed out or refused	DNS points to the wrong IP, or the server's firewall is blocking traffic
Certificate or privacy warning	DNS is correct, but the new server has no valid certificate for your domain yet
Host's default page, 404, or "domain not configured"	DNS is correct, but the new server doesn't know about your domain
Too many redirects	A redirect loop between the server, a CDN or a plugin
Works on some devices, not others	Caching, IPv6 differences, or a local hosts file entry

The first two rows are DNS problems. The rest are usually server or configuration problems that only became visible because DNS now points at the new server.

Step 1: Check What Your Nameservers Actually Publish

Before anything else, confirm the authoritative source. Find your domain's nameservers, then ask one directly:

dig example.com NS +short

ns1.example.net.
ns2.example.net.

dig @ns1.example.net example.com A +norecurse +noall +answer
dig @ns1.example.net www.example.com A +norecurse +noall +answer
dig @ns1.example.net www.example.com AAAA +norecurse +noall +answer

example.com.		300	IN	A	198.51.100.20
www.example.com.	300	IN	CNAME	example.com.
example.com.		300	IN	A	198.51.100.20

Compare these values with what your new host told you to set. If they don't match, the problem is in your DNS records, and waiting won't fix it.

Are You Editing the Right DNS Provider?

This catches many people. Your registrar, your old host and your new host may all offer DNS management. Only the provider whose nameservers appear in the NS lookup is actually serving your domain. Changes made anywhere else have no effect.

If dig example.com NS +short shows your registrar's nameservers but you edited records at your new host, either make the changes at the registrar, or change the nameservers to the host's and recreate all your records there.

Step 2: Test the New Server Directly

Next, find out whether the new server works at all, independently of DNS. curl --resolve sends a request to a specific IP address while still using your domain name for the HTTP Host header and TLS certificate check:

curl -sv --resolve www.example.com:443:198.51.100.20 https://www.example.com/ -o /dev/null

Look for these lines in the output:

* Connected to www.example.com (198.51.100.20) port 443
* Server certificate:
*  subject: CN=www.example.com
*  SSL certificate verify ok.
< HTTP/2 200

The results tell you where to look:

Connection works and returns your site: The server is fine. Any remaining problem is DNS or caching.
Connection refused or timed out: The server isn't listening on that IP, or a firewall is blocking it. This is a hosting problem.
Certificate error: The server is reachable but has no valid certificate for your domain yet.
Wrong site or a 404: The server doesn't have your domain configured.

To test in a real browser, you can add a temporary line to your hosts file that points the domain at the new IP. Remember to remove it afterwards:

198.51.100.20  example.com www.example.com

On macOS and Linux, the file is /etc/hosts. On Windows, it's C:\Windows\System32\drivers\etc\hosts.

Common Causes and How to Fix Them

1. Cached Old Records

Resolvers keep the old record until its TTL expires. If the old record's TTL was 24 hours, some visitors may see the old server for up to a day.

Check the remaining TTL on a public resolver:

dig @8.8.8.8 www.example.com A +noall +answer

www.example.com.	61432	IN	A	192.0.2.10

Google still has the old address 192.0.2.10 cached for about 17 more hours. On your own machine, flush the local caches so you're not fooled while testing:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

# Windows
ipconfig /flushdns

Keep the old server running until caches have expired. If it has already been switched off, visitors with cached records get timeouts rather than the old site.

2. A Mistake in the Record

Typos are common and easy to miss. Look for:

A wrong digit in the IP address: 198.51.100.2 instead of 198.51.100.20.
A doubled domain name: Entering www.example.com in a panel that appends the domain automatically creates www.example.com.example.com.
A missing trailing dot in a zone file, which has the same effect for CNAME targets.
The wrong record type, such as an A record where the host asked for a CNAME.

You can test for the doubled name directly:

dig www.example.com.example.com A +short

If it returns your new IP, fix the record name.

3. Only One of www and the Bare Domain Was Updated

example.com and www.example.com are separate DNS names. It's common to update one and forget the other, so the site loads at one address but not the other, or loads the old site at one of them.

dig example.com A +short
dig www.example.com +short

Both should lead to the new host. Usually that means an A record for @ and either an A record or a CNAME for www, as your host specifies.

4. A Leftover AAAA Record

This is one of the most confusing causes. If your old host gave you an IPv6 address and you only replaced the A record, the old AAAA record still points visitors with IPv6 connections at the old server. Most mobile networks and many home connections now prefer IPv6, so those visitors see the old site or a timeout while you, perhaps on an IPv4-only network, see the new one.

dig example.com AAAA +short
dig www.example.com AAAA +short

2001:db8:10::5

If an AAAA record points at the old host, either update it to the new host's IPv6 address, or delete it if the new host doesn't support IPv6.

5. Nameserver Change Still in Progress

If you changed the domain's nameservers rather than individual records, resolvers may still be using the old nameservers for up to 48 hours. If the old DNS provider still has your zone, visitors using the old nameservers get the old records.

Check what the TLD has on file:

dig +norecurse @a.gtld-servers.net example.com NS

During a nameserver move, make sure the new provider has every record before switching, and keep the old provider's zone in place, updated with the same values, until the move is complete.

6. Broken DNSSEC After Changing Providers

If DNSSEC was enabled at your old DNS provider and its DS record is still at your registrar, validating resolvers reject answers signed by the new provider, or answers that aren't signed at all. Your site fails for users of Google Public DNS, Cloudflare, Quad9 and many ISPs, while non-validating resolvers work fine.

Test with validation turned off:

dig @1.1.1.1 example.com A
dig @1.1.1.1 example.com A +cd

If the first returns status: SERVFAIL and the second returns an answer, DNSSEC is the problem. Remove the old DS record at your registrar, or add the new provider's DS record if it signs your zone.

7. The New Server Doesn't Know About Your Domain

Web servers host many sites on one IP address and pick the right one by the requested hostname. If the new host hasn't added your domain to your account, or the web server's configuration doesn't include it, you'll see the host's default page, a 404, or a "domain not configured" message.

Add the domain in your hosting control panel, including both example.com and www.example.com if you use both. If you manage the server yourself, make sure the virtual host includes every name. For Nginx:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
}

8. No SSL Certificate Yet

Many hosts issue a free certificate automatically, but only after DNS points at them, because the certificate authority checks the domain by connecting to it. Until that happens, visitors get a certificate warning.

Check which certificate the server is presenting:

openssl s_client -connect 198.51.100.20:443 -servername www.example.com </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

subject=CN=www.example.com
issuer=C=US, O=Let's Encrypt, CN=R11
notBefore=Oct 18 00:12:44 2026 GMT
notAfter=Jan 16 00:12:43 2027 GMT

If the subject is the host's default name rather than your domain, trigger certificate issuance in the hosting panel once DNS is correct. If your domain has a CAA record, make sure it allows the certificate authority your new host uses:

dig example.com CAA +short

0 issue "digicert.com"

In that example, a host that uses Let's Encrypt can't get a certificate until you add 0 issue "letsencrypt.org".

9. HSTS and Browser Caches

If the old site used HSTS (HTTP Strict Transport Security), browsers that visited it refuse to connect without a valid certificate, and won't let you click past the warning. This makes the certificate problem above look worse in browsers you've used before. Once the new server has a valid certificate, the problem disappears.

Browsers also cache pages and redirects. Test in a private window, or clear the browser's DNS cache at chrome://net-internals/#dns in Chrome and Edge.

10. A CDN or Proxy in Front of the Site

If your DNS points at a CDN, such as with Cloudflare's proxy turned on, visitors connect to the CDN, which then connects to your origin server. Changing DNS to the new host isn't enough if the CDN's origin setting still points at the old server, or if the CDN's SSL mode doesn't match the new server's setup. A mismatch between the CDN and origin SSL settings is a classic cause of "too many redirects".

Check whether a CDN is in front:

curl -sI https://www.example.com/ | grep -iE "^server:|^via:|^cf-ray:|^x-cache:"

If you see headers from a CDN, review its origin and SSL settings as well as your DNS.

A Diagnostic Checklist

Work through these in order and stop at the first one that fails:

dig example.com NS +short shows the provider where you edited records.
The authoritative nameservers return the new values for the bare domain and www, for both A and AAAA.
curl --resolve to the new IP returns your site with a valid certificate.
Public resolvers return the new value, or the old value with a TTL that's counting down.
dig +cd and a normal query give the same result, so DNSSEC isn't blocking resolution.
No CDN, hosts file entry or browser cache is getting in the way.

FAQ: Website Not Loading After a DNS Change

For record changes, up to the TTL of the old record, which is often between a few minutes and 24 hours. Nameserver changes can take up to 48 hours. If the authoritative servers are still showing the wrong value, waiting won't help.

Your computer may have a cached record, a hosts file entry, or a different DNS resolver. Your phone may also use IPv6 while your computer uses IPv4, so check for an outdated AAAA record. Flush your computer's DNS cache and compare.

Either your resolver still has the old record cached, or one of your records, often the AAAA record or the www record, still points at the old host. Check the authoritative nameservers to see which.

DNS is pointing at the new server, but that server doesn't have a valid certificate for your domain yet. Many hosts issue one automatically once DNS is correct. A restrictive CAA record can also block issuance.

No. Keep the old server running until the old record's TTL has passed everywhere, ideally a few days. Visitors with cached records still reach the old server during that time.

Yes. Use curl --resolve to send a request to the new IP address with your domain name, or add a temporary entry to your hosts file and browse normally. Remove the hosts file entry when you're done.

Conclusion

When a website stops loading after a DNS change, resist the urge to blame propagation straight away. Ask your authoritative nameservers what they're publishing, and test the new server directly with curl --resolve. Those two checks separate DNS mistakes, which you need to fix, from caching, which you only need to wait out, and from server problems, which have nothing to do with DNS at all.

The usual culprits are editing records at the wrong provider, a typo or doubled domain name, forgetting www or the AAAA record, an old DS record breaking DNSSEC, and a new server that hasn't been set up for the domain or issued a certificate. Keep the old host running until caches clear, and the switch will be invisible to your visitors.