How DNS Problems Can Make Your Website Unavailable

Some of the most confusing outages happen when the web server is running fine, the application has no errors, and yet nobody can reach the website. Very often the cause is the Domain Name System (DNS). This article explains how DNS works, which problems take websites offline, how to diagnose them and how to make DNS changes without causing downtime.

How DNS works, briefly

Computers connect to each other using IP addresses, such as 203.0.113.10 (IPv4) or 2001:db8::10 (IPv6). DNS translates human-friendly names like example.com into those addresses. The system is described in the original specifications RFC 1034 and RFC 1035, extended by many later standards.

When a visitor types your domain, roughly this happens:

1. The visitor's device asks a recursive resolver, usually run by their internet provider, company network or a public DNS service.
2. If the resolver doesn't have a cached answer, it asks the root servers, then the servers for the top-level domain (such as .com), which point it to your domain's authoritative name servers.
3. Your authoritative name servers answer with the records you configured, such as the A record holding your server's IP address.
4. The resolver caches the answer for the record's TTL (time to live) and returns it to the visitor's device, which then connects to your server.

If anything in this chain fails or returns the wrong answer, visitors never reach your server.

Records that matter for websites

Common DNS problems that cause outages

1. Expired domain registration

If the domain registration lapses, the registry stops publishing its name server delegation and the domain stops resolving entirely. This often happens because a renewal payment failed or reminders went to an old email address.

2. Wrong or missing records after a migration

Moving to a new host or DNS provider is one of the riskiest moments. Typical mistakes include pointing the A record at an old IP address, forgetting the www record, or switching name servers to a new provider before all records were recreated there.

3. Accidental deletion or typos

A single wrong digit in an IP address, or a deleted record while cleaning up, is enough to make a website unreachable.

4. DNS provider outage

If your authoritative DNS provider has an outage, resolvers can't get fresh answers once their cached copies expire. Using a reliable provider and, for critical domains, multiple providers reduces this risk.

5. Stale caches after changes

Resolvers cache answers for the TTL. If you change a record that had a TTL of 24 hours, some visitors may keep receiving the old answer for up to a day. If the old server is already switched off, those visitors experience an outage.

6. IPv6 records pointing to nothing

If a domain has an AAAA record but the server doesn't actually accept connections over IPv6, visitors on IPv6 networks may experience failures or slow fallbacks, while everyone on IPv4 sees a working website. This is a confusing "works for me" problem.

7. DNSSEC misconfiguration

DNSSEC adds cryptographic signatures to DNS answers. It improves security, but a mismatch between the keys at the registry and the signatures served by your provider, for example after changing providers, causes validating resolvers to reject your domain entirely.

8. CNAME at the zone apex

Standard DNS doesn't allow a CNAME at the root of a domain (example.com) alongside other required records. Some providers offer alternatives (often called ALIAS, ANAME or CNAME flattening). Getting this wrong can break the bare domain while www keeps working.

How to diagnose DNS problems

Recognise the symptoms

Browser errors such as "Server not found", "This site can't be reached" or DNS_PROBE_FINISHED_NXDOMAIN mean the name couldn't be resolved. An uptime monitor reports this as a DNS failure rather than a timeout or HTTP error.

Look up the records

Use our free DNS lookup tool to see the A, AAAA, CNAME, MX, NS and TXT records for a domain from our resolver. From a terminal, dig gives you more control:

# The A record as seen by your default resolver
dig example.com A +short

# Which name servers are authoritative for the domain?
dig example.com NS +short

# Ask an authoritative server directly, bypassing caches
dig @ns1.example-dns.net example.com A

# Follow the full delegation path from the root
dig example.com +trace

On Windows, nslookup example.com provides a basic equivalent.

Compare answers

• If the authoritative server returns the right answer but your resolver doesn't, you're probably looking at a cached old value. Wait for the TTL to expire.
• If the authoritative server returns the wrong answer, fix the record at your DNS provider.
• If +trace stops at the top-level domain, check the domain's registration and name server delegation at your registrar.

How to change DNS records safely

1. Document current records before changing anything. Export the zone if your provider allows it.
2. Lower the TTL in advance. A day or two before a planned change, reduce the TTL of the records you'll modify (for example to 300 seconds). Once the old, longer TTL has passed, changes will spread quickly.
3. Keep the old server running until traffic has fully moved to the new one.
4. When changing providers, recreate every record first, verify them by querying the new provider's name servers directly, and only then switch the name servers at the registrar.
5. Handle DNSSEC carefully during provider changes, following both providers' instructions.
6. Verify from outside with a DNS lookup and the website status checker, then restore a normal TTL.

Prevention checklist

• Enable auto-renewal for your domains and keep registrar contact details current.
• Use a reliable DNS provider and restrict who can edit records.
• Enable two-factor authentication on registrar and DNS accounts to reduce the risk of hijacking.
• Remove AAAA records unless the server is properly reachable over IPv6.
• Monitor your website from the outside so DNS failures are detected quickly.

UptimeStats classifies DNS failures separately from timeouts, SSL errors and HTTP errors, so a DNS problem is identified as such in your alert and incident history. For other causes of outages, see What Causes Website Downtime?