linux troubleshooting guide

DNS Changed but Not Working: What to Check

DNS troubleshooting works best when you separate authoritative records, resolver cache, local cache, and the web server response path.

Problem

A domain was updated, but some users still reach the old site, get certificate warnings, or cannot connect. The change may be correct at the authoritative nameserver and still not visible everywhere.

First rule

Do not assume DNS is fixed because one resolver returns the answer you expected.

Audience

website owners, developers moving hosts, and students practicing network troubleshooting

Cert context

Good unofficial practice for DNS, HTTP, and network troubleshooting objectives without using exam-provider material.

quick start

Safe first commands

dig +short example.com
dig @1.1.1.1 +short example.com
dig @8.8.8.8 +short example.com
curl --resolve example.com:443:203.0.113.10 -I https://example.com/

Compare more than one resolver

Public resolvers can disagree during propagation windows. Comparing answers helps you separate a global record problem from cache delay.

dig @1.1.1.1 +short example.com
dig @8.8.8.8 +short example.com
dig @9.9.9.9 +short example.com

Check the direct server response

If the new server responds when you force the hostname to its IP, the web server path is probably alive. If it fails, DNS may not be the only problem.

curl --resolve example.com:443:203.0.113.10 -I https://example.com/
curl -I https://example.com/

Remember that certificates follow names

A DNS change can expose certificate mismatch problems if the new server is not configured for the same hostname. Check the HTTP/TLS response after the DNS answer looks right.

curl -Iv https://example.com/ 2>&1 | head -40

Watch for split authority

The registrar, authoritative nameservers, DNS provider UI, CDN, and local resolver cache may all be different systems. The right question is not only what record you edited, but who is authoritative for the name.

dig NS example.com +short
dig SOA example.com +short

triage logic

How to read the result

public resolvers disagree

Propagation or cache behavior is still in progress, or one resolver has stale data.

Next: Check TTLs and authoritative nameservers before making more edits.

all resolvers return the wrong address

The authoritative DNS configuration is probably not what you think it is.

Next: Check the active nameservers and record set at the DNS provider.

DNS is right but HTTPS fails

The server, virtual host, certificate, firewall, or CDN path still needs work.

Next: Use forced curl, port checks, and web server logs.

safety notes

Slow down here

Avoid changing several DNS records at once while testing; it becomes hard to know which change mattered.
Lower TTL before planned migrations when possible, not during panic.
Document old and new answers before changing records again.

related lessons