Site not loading after a DNS update

A site that worked yesterday and stopped the moment a DNS or nameserver change went in is almost never a random crash. DNS changes are the most common cause of a sudden and unexpected outage because the change affects how every visitor finds the site, and it propagates unevenly. The good news is that this class of break is predictable, so it has a reliable diagnosis order.

Why a DNS change can take a site down

When you update an A, CNAME, or AAAA record, or move nameservers, you are telling resolvers where the site lives. Several things can go wrong:

• The new record points to an IP that has no web server answering on port 80 or 443.
• The record was typed wrong, for example a double dot, a trailing space, or an IPv6 address the host does not use.
• Nameservers changed but the new provider does not host the zone records yet, so queries return NXDOMAIN.
• The site moved behind a proxy or CDN, but the old records or cached values still resolve to the old origin.
• Email and website records were mixed up during the edit, and the change silently broke more than the page.

Because caching differs per ISP and device, some visitors may see the new site while others still see the old one or nothing at all. That split behaviour is often the first clue it is DNS.

Diagnose in order

Work from the closest layer to the farthest so you do not chase a host problem when the record is simply wrong.

1. Check the record at authoritative resolvers, not your local device. Use a public lookup tool or dig at the official nameservers to confirm the record is actually live and correct.
2. Flush your local DNS cache, then test on a few separate networks such as phone data and a different Wi-Fi. If only one network fails, propagation or caching is usually the cause rather than a broken record.
3. Confirm the target IP actually serves the site. Open the IP directly, with the host header if your server uses virtual hosts, and check port 443 as well as 80.
4. If you moved nameservers, verify the zone exists on both nameservers of the new provider and that the records render identically.
5. Check the SSL certificate. A valid A record that resolves to a server with no matching certificate gives certificate errors, which owners often describe as "the site is down".

Confirm and prevent

When the new record is correct at the authoritative level, the fix is usually waiting for propagation to catch up. If the record is wrong, correct it at the DNS provider and double-check the value against a record from the old setup.

Prevent the problem on the next change: lower the TTL of the record you will change a day in advance, verify the new host is serving the site before switching DNS, and keep the old environment live until propagation is complete. Keeping the old A record as a fallback is often enough to survive a bad manual edit. See check DNS propagation for the exact tools and thresholds to confirm a change has fully landed.

The key habit: always verify the destination is healthy before pointing DNS at it, and always have a way to point back.