What are the most common DNS mistakes that take websites offline?
The most common DNS mistakes that take websites offline are letting the domain expire, changing nameservers without copying every record to the new provider, leaving an old DNSSEC DS record at the registrar after switching DNS hosts, making changes with a long TTL still in place, typing the wrong IP address or hostname, deleting records you didn't realise were in use, missing the trailing dot in zone files, and relying on a single DNS provider or a single nameserver. Almost all of them come down to small, rushed changes made without checking what the world will actually see afterwards.
DNS outages are frustrating because the site itself is usually fine. The server is running, the code hasn't changed, but nobody can find it. In this article you'll learn the mistakes that cause most DNS-related downtime, how to recognise each one quickly with dig, and the habits and checks that stop them happening in the first place.
Why DNS Mistakes Hurt So Much
DNS mistakes have two properties that make them worse than most configuration errors.
- They're cached: A bad record is copied into resolvers all over the world and kept for its TTL. Fixing the record at your provider doesn't fix those caches instantly.
- They affect everything: Your website, API, email, and third-party services all depend on the same zone. A single wrong change can take all of them down at once.
That combination means the best fix is prevention, and the second best is noticing quickly. Keep both in mind as you read through the list.
Mistake 1: Letting the Domain Expire
This is the most basic mistake and still one of the most common. When a domain expires, the registry eventually stops publishing its NS records, and the whole domain stops resolving. Depending on the registrar, you might also find your site replaced by a parking page.
Typical causes include an expired card on the registrar account, renewal reminders going to a former employee's mailbox, or auto-renew being switched off.
How to Check
Use RDAP, the modern replacement for WHOIS, to see the expiry date and status:
curl -s https://rdap.verisign.com/com/v1/domain/example.com |
jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'
2027-08-13T04:00:00Z
That endpoint covers .com. For other TLDs, IANA publishes a bootstrap file of RDAP servers, or you can use the whois command and look for the expiry date.
How to Avoid It
- Turn on auto-renew for every domain you care about.
- Renew important domains for several years at a time.
- Use a shared mailbox or distribution list as the registrar contact, not a personal address.
- Keep a valid payment method on file and check it when cards are replaced.
Mistake 2: Changing Nameservers Without Copying Every Record
When you move DNS hosting, for example to a CDN or a new DNS provider, you change the nameservers at the registrar. From that moment, the new provider's zone is the only one that matters. Any record that wasn't recreated there simply stops existing.
The classic version of this mistake is copying the website records but forgetting the MX records, so email stops arriving. Others include losing TXT records for SPF, DKIM or domain verification, or missing a subdomain used by an API or a mobile app.
How to Check
Before switching, compare the old and new zones by querying each provider's nameservers directly:
#!/usr/bin/env bash
# Compare records between the current and new nameservers.
old="ns1.oldprovider.example"
new="ns1.newprovider.example"
names="example.com www.example.com api.example.com mail.example.com"
types="A AAAA CNAME MX TXT CAA"
for name in $names; do
for type in $types; do
a=$(dig @"$old" "$name" "$type" +short | sort)
b=$(dig @"$new" "$name" "$type" +short | sort)
if [ "$a" != "$b" ]; then
echo "DIFF $name $type"
echo " old: ${a:-<none>}"
echo " new: ${b:-<none>}"
fi
done
done
DIFF example.com MX
old: 10 mx1.mailprovider.example.
new: <none>
Any line starting with DIFF needs attention before you change the nameservers.
How to Avoid It
Export the full zone from the old provider rather than relying on what the dashboard shows on screen. Many providers support a BIND-format export, and most new providers can import one. Then run a comparison like the one above for every name you know about.
Mistake 3: Leaving a Stale DNSSEC DS Record
If your domain uses DNSSEC, the registrar holds a DS record that matches a key at your DNS provider. If you move to a new provider while the old DS record is still in place, validating resolvers will reject every answer from the new provider's servers. Users of those resolvers, which includes most major public resolvers, get SERVFAIL and can't reach the site at all.
How to Check
dig @1.1.1.1 example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31337
Now ask the same resolver to skip validation:
dig @1.1.1.1 example.com A +cd +short
192.0.2.10
If the normal query fails but the +cd (checking disabled) query works, the DNSSEC chain is broken. Compare the DS record at the parent with the DNSKEY records your current provider publishes:
dig example.com DS +short
dig example.com DNSKEY +short
How to Avoid It
When changing DNS providers, remove the DS record at the registrar first, wait at least the DS record's TTL (often a day or two for many TLDs), then switch providers. Re-enable DNSSEC with the new provider and add the new DS record once everything is working.
Mistake 4: Making Changes With a Long TTL
TTL (time to live) controls how long resolvers cache a record. If your A record has a TTL of 86400 seconds (24 hours) and you point it at a new server, some visitors will keep going to the old server for up to a day. If you then switch off the old server, those visitors see an outage.
The same applies in reverse. If you make a mistake with a long TTL, the bad answer stays cached for just as long.
How to Avoid It
Check the current TTL a few days before a planned change:
dig www.example.com A +noall +answer
www.example.com. 86400 IN A 198.51.100.20
Then follow this order:
- Lower it to something like 300 seconds, and wait for at least the old TTL to pass.
- Make the change, verify it, and keep the old server running until the old TTL has expired since the change.
- Raise the TTL again once you're confident.
Mistake 5: Typos in IP Addresses and Hostnames
A single wrong digit in an IP address points your site at someone else's server, or at nothing. A misspelt CNAME target sends lookups to a name that doesn't exist. These are easy to make when copying values by hand from documentation or a support ticket.
How to Check
Always verify a change against your authoritative nameserver and then test the actual service:
dig @ns1.example.net www.example.com A +norecurse +short
curl -sI --resolve www.example.com:443:192.0.2.10 https://www.example.com/ | head -n 1
The --resolve option tells curl to connect to a specific IP for that hostname, which lets you confirm the new server answers correctly for your domain, with a valid certificate, before or immediately after the DNS change.
How to Avoid It
Copy and paste values rather than typing them, and ask someone else to review changes to critical records. If you manage DNS as code, the review step happens naturally in a pull request.
Mistake 6: Missing the Trailing Dot in a Zone File
In BIND-style zone files, a name without a trailing dot is relative to the zone's origin. It's an easy mistake to make and produces names you didn't intend:
$ORIGIN example.com.
www 3600 IN CNAME example.cdn.example.net
Because the target lacks a final dot, the server appends the origin, so the CNAME actually points to example.cdn.example.net.example.com., which doesn't exist. The correct line is:
www 3600 IN CNAME example.cdn.example.net.
The same applies to MX and NS targets. You can spot this mistake quickly because the answer contains your own domain name twice:
dig www.example.com CNAME +short
example.cdn.example.net.example.com.
Run named-checkzone before reloading. It won't flag this as an error, because the result is technically valid, but its output with -D shows every name fully expanded, which makes the problem obvious:
named-checkzone -D example.com db.example.com | grep -i cname
Mistake 7: Forgetting to Increase the SOA Serial
If you run your own primary and secondary nameservers, secondaries only fetch an updated zone when the SOA serial increases. Edit the zone without changing the serial, and the primary serves the new data while the secondaries keep serving the old version. Visitors get different answers depending on which nameserver their resolver asks.
How to Check
Compare the serial on every nameserver:
for ns in $(dig example.com NS +short); do
printf '%-22s' "$ns"
dig @"$ns" example.com SOA +short | awk '{print $3}'
done
ns1.example.net. 2026101801
ns2.example.net. 2026101501
Mismatched serials mean the zones are out of sync. Most managed DNS providers handle serials for you, so this mainly affects self-hosted setups.
How to Avoid It
Use the YYYYMMDDnn convention and increase the serial with every change, or let your tooling manage it. BIND can do this automatically for dynamically updated zones, and most DNS-as-code tools handle it for you.
Mistake 8: Mismatched Nameservers at the Registrar
The nameservers listed at your registrar (the delegation in the parent zone) should match the NS records inside your zone, and every one of them should answer authoritatively for your domain. Common problems include:
- A nameserver that was decommissioned but never removed from the registrar.
- A typo in a nameserver hostname.
- Nameservers from an old provider mixed with the new provider's.
When resolvers pick a broken nameserver, lookups slow down or fail. This is known as a lame delegation.
How to Check
dig example.com NS @a.gtld-servers.net +norecurse +noall +authority
dig example.com NS +short
The first command shows what the .com registry delegates to, and the second what your zone itself says. They should list the same servers. Then confirm each one answers with the aa (authoritative answer) flag:
dig @ns2.example.net example.com SOA +norecurse | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
Mistake 9: Deleting Records You Didn't Recognise
During a tidy-up, it's tempting to delete records that look old or unexplained. Some of them are quietly important:
- TXT records for SPF, DKIM, DMARC and domain verification. Removing a verification record can cause a service to unverify your domain.
- CNAMEs for DKIM such as
selector1._domainkey, which break email signing when deleted. - Records used by mobile apps or IoT devices, which may not appear in any web analytics.
- CAA records, which control which certificate authorities can issue for your domain. Removing them is less dangerous, but changing them carelessly can block certificate renewal.
How to Avoid It
Before deleting a record, search your code, configuration and documentation for the name. Lower its TTL, then remove it and keep the value so you can restore it quickly. Better still, add a comment field or a record inventory that explains what each record is for.
Mistake 10: A Single Point of Failure
All your nameservers can be perfectly configured and still go offline together if they belong to a single provider that has an outage, or if they're all in one network. Large DNS provider outages have taken thousands of websites offline at once.
Options to reduce the risk include:
- Choose a provider with an anycast network and a strong reliability record.
- Use a secondary DNS provider that receives a copy of your zone by zone transfer or via an API sync, and list both providers' nameservers at the registrar.
- If you self-host, put your nameservers in different networks and locations, not on the same server or subnet.
You can check how diverse your nameservers are:
for ns in $(dig example.com NS +short); do
printf '%-22s %s\n' "$ns" "$(dig "$ns" A +short | head -n 1)"
done
If every nameserver resolves to addresses in the same small range, a single network problem can take them all down.
Mistake 11: Losing Access to the Registrar or DNS Account
If an attacker gets into your registrar or DNS provider account, they can change nameservers or records and take your site offline or redirect it. Equally, if the only person with the password leaves the company, a simple fix can turn into a long account recovery process.
How to Avoid It
- Enable two-factor authentication on registrar and DNS accounts.
- Turn on the registrar lock to prevent unauthorised transfers. For high-value domains, ask about a registry lock.
- Use a shared organisational account owner and give individuals their own logins with appropriate permissions.
- Keep recovery details current.
Habits That Prevent Most DNS Outages
Most of the mistakes above share the same causes: rushing, not checking, and not knowing what records exist. A few habits address all of them:
- Keep an up-to-date export of every zone, ideally in version control.
- Lower TTLs before planned changes, and raise them afterwards.
- Verify every change against the authoritative nameservers and then a public resolver.
- Review critical changes with a second person or through DNS as code.
- Monitor DNS from outside your network, so you hear about a broken record before customers do.
A simple external check you can run from cron is a good start:
#!/usr/bin/env bash
# Alert if a critical record changes or stops resolving.
name="www.example.com"
expected="192.0.2.10"
actual=$(dig @1.1.1.1 "$name" A +short | tail -n 1)
if [ "$actual" != "$expected" ]; then
echo "DNS check failed for $name: expected $expected, got ${actual:-nothing}" |
mail -s "DNS alert: $name" ops@example.com
fi
The tail -n 1 keeps only the final address, which matters if the name is a CNAME, because dig +short prints the alias target first.
FAQ: Common DNS Mistakes
Changes made without verification are the most common cause, especially nameserver changes that leave records behind and record edits with typos. Expired domains and stale DNSSEC records after a provider move are close behind.
You can correct the record immediately, but resolvers that cached the bad answer will keep it until its TTL expires. That's why low TTLs during planned changes make mistakes much cheaper to recover from.
Usually because the MX records, and often the SPF and DKIM records, weren't recreated at the new DNS provider. Once the nameservers change, only the new provider's zone is used, so missing records simply disappear.
Query a validating resolver such as 1.1.1.1 with dig. If the normal query returns SERVFAIL but the same query with +cd returns an answer, the DNSSEC chain is broken, often because of an outdated DS record at the registrar.
For business-critical domains, a secondary DNS provider removes a single point of failure. It adds some complexity, because both providers must serve identical zones, so use zone transfers or an automation tool to keep them in sync.
A trailing dot marks a name as fully qualified. Without it, the server appends the zone's origin, so a CNAME target such as host.example.net becomes host.example.net.example.com, which doesn't exist.
Conclusion
The DNS mistakes that take websites offline are rarely exotic. Expired domains, forgotten records during a provider move, stale DS records, long TTLs, typos and missing trailing dots account for most outages. Each one is easy to make under time pressure, and each one is easy to spot with a few dig commands if you look before and after every change.
Treat DNS changes with the same care as code deployments. Keep exports of your zones, lower TTLs before planned work, verify against authoritative servers, protect your registrar account, and monitor your most important records from outside your network. Those habits turn most DNS mistakes from outages into quick, harmless corrections.
