Changed NS and the site won't open: a troubleshooting checklist

If your site will not open after changing nameservers, do not panic. Most of the time the change simply has not reached every resolver yet. Sometimes, though, the problem is real: the zone is missing on the new servers, the A record is wrong, the domain was not added to hosting, or an old DNSSEC record is left behind. This checklist goes from the most likely cause to the least likely, and usually gives a clear answer within 10 to 15 minutes.

Quick diagnosis by symptom

1. Has the registry got the change?

dig +trace follows the query from the root servers and ignores caches, while whois shows the registrar's current data and the domain status:

dig +trace maktab-misol.uz
whois maktab-misol.uz | grep -iE "name server|status|expir"

If trace still shows the old nameservers, the change was not saved or not yet published. If whois shows the domain expired or suspended, the problem is not DNS at all and the domain must be renewed first.

2. Are the NS names spelled correctly?

dig +short A ns1.provayder.uz
dig +short A ns2.provayder.uz

An empty answer means a typo. Also make sure old and new providers' nameservers are not mixed, which makes the site work for some visitors and fail for others.

3. Does the zone exist on the new servers?

If delegation points to servers that do not host your zone, you have a lame delegation. Ask each server directly:

dig @ns1.provayder.uz maktab-misol.uz SOA
dig @ns2.provayder.uz maktab-misol.uz SOA

NOERROR with an SOA record means the zone is there. REFUSED or SERVFAIL means the domain was never added to the new DNS service.

4. Are the A and www records right?

dig @ns1.provayder.uz maktab-misol.uz A +short
dig @ns1.provayder.uz www.maktab-misol.uz +short

The IP must match your hosting server. Seeing the old server's IP means records were copied without updating.

5. Flush caches and test from another network

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
resolvectl flush-caches

Chrome has its own cache at chrome://net-internals/#dns. Try mobile data or query public resolvers with dig @8.8.8.8 maktab-misol.uz A +short. If they return the right IP, all that is left is waiting.

6. Is the domain added to the hosting account?

Bypass DNS and send the request straight to the server, replacing 203.0.113.10 with your hosting IP:

curl -I --resolve maktab-misol.uz:443:203.0.113.10 https://maktab-misol.uz/

Correct site headers mean the server is ready and the issue is DNS caching. A default page or 404 means the domain is not set up as a site; sayt.uz customers attach the domain to hosting from the cabinet.

7. Is the SSL certificate issued yet?

Let's Encrypt can only validate the domain once DNS points to the new server, so a certificate warning is common during the transition, and HSTS may stop you from bypassing it. Check the certificate with:

openssl s_client -connect maktab-misol.uz:443 -servername maktab-misol.uz </dev/null | openssl x509 -noout -subject -dates

8. Is an old DNSSEC record left over?

A DS record at the registry with an unsigned new zone makes validating resolvers return SERVFAIL, so the site works on some networks only:

dig DS maktab-misol.uz +short
dig @8.8.8.8 maktab-misol.uz A +dnssec

Remove the DS record at the registrar or enable DNSSEC at the new provider.

Example: a school in Namangan

A private school in Namangan moved its site and changed NS. The next day some parents could open it while others saw "site not found". Trace showed the new nameservers and the zone was in place. dig DS revealed the cause: a DS record from DNSSEC enabled at the old provider was still at the registry, so users of validating ISPs could not resolve the domain. Once the DS record was removed, the problem disappeared within hours. "Works for some, not for others" is not always just cache, and following the list in order finds the real cause quickly.