To fix a DNS misconfiguration, work from the source outward. Ask the authoritative nameserver what it actually serves, compare that with what public resolvers return, correct the wrong record or delegation at the right place, then confirm the change with fresh queries. Most of the pain comes from skipping the first step and editing records while a stale cache or a wrong nameserver is the real culprit.
This guide walks through that process for site owners, developers and sysadmins. It covers the commands to run, the errors you will see, the records that break most often, and how a DNS mistake can quietly knock out SSL and email too.
TL;DR
- A DNS misconfiguration is a wrong, missing or stale record, or a broken nameserver setup. It shows up as NXDOMAIN, SERVFAIL, old content, certificate warnings or bouncing email.
- Query the authoritative nameserver first. It bypasses every cache and tells you what is really configured.
- Compare answers from at least two public resolvers, and flush local caches before you trust what your own machine says.
- Document the old record and TTL before you change anything, so you can roll back.
- After the fix, check DNS, the certificate and the live site together. A correct record can still point at a server with the wrong certificate.
Table of Contents
- What a DNS misconfiguration looks like
- Step 1: Decide whether the fault is DNS at all
- Step 2: Ask the authoritative server what is configured
- Step 3: Check nameservers and delegation
- Step 4: Correct the record itself
- Step 5: Separate cache from configuration
- Step 6: Verify the fix, then check SSL
- How long until the fix shows up
- Our perspective: monitor, don't just fix
- Catch the next DNS problem earlier
- Prevention checklist
- FAQ
- Sources
What a DNS misconfiguration looks like
A DNS misconfiguration happens when the system fails to translate a domain name into the right IP address or service target. The result ranges from a site that is completely unreachable to intermittent failures, email delivery problems and broken subdomains. Security-focused definitions go wider: an incorrect, weak or outdated record or server setting can also cause spoofing, traffic redirection, subdomain takeover or information exposure.
The symptoms you are most likely to meet:
- NXDOMAIN or DNS_PROBE_FINISHED_NXDOMAIN. The name does not resolve. Cloudflare notes that misspelled or incorrect records, or missing essential information, can cause this.
- SERVFAIL. The resolver could not get a usable answer. A mismatched nameserver delegation at the registrar is a classic trigger, because resolvers fail to receive authoritative answers from the servers named there.
- Old content after a migration. The domain resolves, but to the previous host.
- Hosting-provider error pages. The request reaches a server that does not know your hostname.
- Undelivered or rejected email. MX, SPF or reverse DNS records are wrong.
The problem is old. RFC 1912, published in 1996, already catalogued incorrect or missing records, bad delegations and inconsistent authoritative data as errors that prevent reliable name resolution. The tools have improved, but the failure modes are the same.
Step 1: Decide whether the fault is DNS at all
Before touching a zone file, rule out the cheap explanations. Microsoft's Azure DNS guidance frames troubleshooting as layer isolation: first distinguish incorrect DNS content from a network path problem, then eliminate caching before you interpret results.
Run these quick checks:
- Try another device or network. If your phone on mobile data loads the site and your laptop does not, the problem is local: your resolver, your cache or your router.
- Check the exact error. "Server not found" points to DNS. A 500 or 503 means DNS worked and the server answered badly. Our reference pages on the 500 Internal Server Error and 503 Service Unavailable will help you tell those apart from a resolution failure.
- Check the network path. Resolution failures can also come from a network path that blocks UDP or TCP port 53. If DNS answers look right but the host is unreachable, a traceroute shows where packets stop. Our playbook on fixing network slowness with traceroute explains how to read the hops.
If the name fails to resolve from several networks, you have a real DNS problem. Move on.
Step 2: Ask the authoritative server what is configured
The authoritative nameserver holds the truth. Querying it directly is, per Cloudflare's documentation, the definitive way to verify a configuration change because it bypasses all caching layers.
First find out which nameservers the world believes are authoritative:
dig NS example.com +short
Then ask one of them for the record in question:
dig @ns1.exampledns.net example.com A +noall +answer
dig @ns1.exampledns.net www.example.com CNAME +noall +answer
dig @ns1.exampledns.net example.com MX +noall +answer
On Windows, nslookup -type=A example.com ns1.exampledns.net does the same job. Microsoft points out that nslookup does not use the client's DNS cache and uses the DNS server configured on the client, which makes it useful for comparing against what your browser sees.
Three outcomes are possible:
- The authoritative answer is wrong. The record itself is misconfigured. Go to Step 4.
- The authoritative answer is right but public resolvers disagree. You are looking at caching or propagation. Go to Step 5.
- The authoritative server does not answer, or says it is not authoritative. The delegation is broken. Go to Step 3.
For a deeper command set, our guide on five commands to find DNS faults goes further than this walkthrough.
Step 3: Check nameservers and delegation
Wrong nameservers are the most damaging misconfiguration because every record behind them becomes irrelevant. The registrar holds the NS records that point the internet at your zone. If they point at a provider where your zone does not exist, nothing you edit will matter.
Compare the two sides:
dig NS example.com +short
dig NS example.com @ns1.exampledns.net +short
dig example.com +trace
The first shows what the parent zone delegates. The second shows what your zone claims about itself. They should match. If they do not, or if a listed server refuses to answer for the zone, you have what RFC 1912 calls a lame delegation: a nameserver listed in NS records but not configured to serve the zone authoritatively. The consequences include unresolved hosts and potentially bounced email.
Common causes:
- You moved DNS hosting but never updated the registrar.
- You updated the registrar but never created the zone at the new provider.
- An old nameserver was left in the list and no longer carries current data.
- Only one nameserver is listed. RFC 1912 says each domain needs at least two nameservers, with more preferred, ideally in different geographic locations.
Fix it by editing the nameserver list at the registrar so it matches the provider that hosts your live zone. Our reference pages on the NS record and SOA record explain what each field means and how they relate.
A DNSSEC warning before you switch providers
If your domain is signed with DNSSEC, do not change nameservers carelessly. Cloudflare's guidance is to remove old DS records and wait for their full TTL, preferably 1.5 times it, before changing nameservers. Skip that and validating resolvers may find the domain unreachable. Also note that NXDOMAIN or no answer can indicate a DNSSEC failure, so if records look correct but validating resolvers still fail, check DNSSEC.
Step 4: Correct the record itself
Once the right nameservers answer, inspect the records. Bluehost lists the usual suspects: incorrect A, CNAME or MX records, wrong or missing nameservers, DNSSEC errors and reverse-DNS mismatches. Azure adds wrong, missing or stale records and broken zone delegation.
| Symptom | Likely misconfiguration | What to check |
|---|---|---|
| Site shows old content | A record points at the previous host | Confirm the current server's public IP and update the A record |
www fails, apex works | Missing or wrong CNAME for www | Query the CNAME and confirm the target resolves |
| Subdomain returns NXDOMAIN | Record deleted or never created | Look for typos in the label and the zone |
| Email bounces or lands in spam | Wrong MX, weak SPF, missing DKIM or DMARC, PTR mismatch | Query MX and TXT, then check reverse DNS |
| Certificate warning | Record points at a server without a matching certificate | Compare hostname with the certificate's names |
| Intermittent failures | Stale record on one nameserver | Query every listed nameserver and compare |
A few specifics worth knowing:
- A versus CNAME. A CNAME cannot sit alongside other records at the same name, and the apex usually needs an A record or a provider-specific alias. Our guide to the A versus CNAME decision covers when to use each.
- Reverse DNS. PTR mismatches often cause outgoing mail to be flagged as spam or rejected, because the mail server's IP must resolve back to the expected hostname. PTR records are usually set by whoever owns the IP block, so ask your hosting provider.
- Dangling records. A CNAME pointing at a service you have cancelled can let someone else claim that target. CloudSEK lists dangling records alongside open resolvers, exposed zone transfers, weak SPF and missing DKIM or DMARC as common misconfigurations with security or availability consequences. Delete records you no longer use.
Change one thing, and write it down
Treat a DNS edit like a code deploy. ManageEngine recommends documenting the existing record, TTL and zone, and planning a rollback before making controlled changes. Cached answers can preserve a bad value after you correct it, so a careless edit can extend an outage rather than end it.
Before you save:
- Copy the current record, its TTL and the zone export into your notes.
- Change one record at a time.
- Keep the old value ready to paste back.
- Record what you changed, when and why.
If the DNS change is part of a bigger move, plan the whole cutover. A site migration SEO plan that maps every URL helps you avoid losing rankings while records change underneath you.
Step 5: Separate cache from configuration
You corrected the record and your browser still fails. That is usually caching, not a second mistake.
Negative caching
If a record did not exist when a resolver first asked, the resolver may remember that. Cloudflare explains that negative caching keeps newly created records unreachable because resolvers cache the empty "non-existent" response for a duration set by the SOA record's MINIMUM field. If you just added a record that was missing, expect a delay before every resolver sees it.
Compare resolvers
Query the same name through a few public resolvers and compare with the authoritative answer:
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @ns1.exampledns.net example.com A +short
This follows the advice to query the authoritative server and then compare several recursive resolvers for differences in resolution or caching. If both public resolvers match the authoritative answer, your DNS is fixed and the remaining problem is local.
Flush your local cache
On Windows, ipconfig /flushdns discards negative and other dynamically added entries from the DNS client resolver cache. In PowerShell, Clear-DnsClientCache does the same, and on a Windows DNS server Clear-DnsServerCache or dnscmd /clearcache clears the server cache. Flushing is harmless: it only forces your machine to ask again, so the next few lookups may be marginally slower.
Changing your device's resolver to a public one such as 1.1.1.1 or 8.8.8.8 is a legitimate test and is safe in the sense that these are major public resolvers. It only helps if your ISP resolver is the problem. It does nothing for a broken zone.
Bypass DNS to test the server
To prove the server is fine while DNS is still settling, force the connection:
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
Forced routing tests like curl --resolve are essential for distinguishing DNS and cache problems from backend application or proxy failures. If this works, the origin is healthy and you are waiting on DNS.
Step 6: Verify the fix, then check SSL
A fix is not done when the record is saved. Azure's guidance is to validate delegation and check the authoritative zone before concluding a record is fixed. RFC 1912 makes the same point: verify the data with dig after a change and double-check it to avoid trouble and lost mail.
A verification pass:
- Query every authoritative nameserver and confirm they agree.
- Query two or three public resolvers.
- Check forward and reverse DNS for mail hosts.
- Load the site from a clean network.
- Check the certificate.
That last step matters because DNS and TLS fail together. If a record points at a server that lacks a valid certificate for the hostname, visitors get certificate warnings or connection errors. Confirm the hostname appears in the certificate's Subject Alternative Names and that DNS points at the server where that certificate is deployed. To see which certificate a server presents for a name:
openssl s_client -servername example.com -connect example.com:443
Sending the server name via SNI is a critical step for learning whether you reached the right server or got a default certificate. Our SSL Checker runs this kind of check from the browser, and the guides on SSL handshake failures and checking an SSL chain cover the command-line side. If you changed redirects during the move, test them too.
How long until the fix shows up
Propagation is really cache expiry. Each resolver keeps the old answer until the record's TTL runs out, and resolvers that cached a negative answer hold it for the SOA minimum. You cannot force other people's resolvers to forget.
What you can do is prepare. Cloudflare recommends lowering TTLs on critical records at least 24 to 48 hours before a planned migration, so resolvers hold old records for less time. That only helps if you do it in advance. For emergencies after the fact, the authoritative check above tells you the fix is live, and you wait out the old TTL. Our article on cutting propagation time with TTL math shows how to plan this.
Our perspective: monitor, don't just fix
Most DNS incidents we see described by developers are not exotic. Someone moves hosting, forgets one record, and the site is down for hours before a customer reports it. The fix takes five minutes. Finding out takes the time.
We built Pingfloat around that gap. Our tools are free, need no installation and need no account for core use, so the checks in this guide are available at the moment you need them. We think a DNS change should be followed by three habits: query the authoritative server rather than trusting your browser, check the certificate in the same sitting, and put an uptime check on the hostname so the next mistake finds you first. Cached answers hide problems and then reveal them later, usually at a bad time. A monitor that tests from outside your network does not care what your laptop remembers.
— Andreas
Catch the next DNS problem earlier
The Pingfloat Website Uptime Monitor checks that your site responds, so a broken record or bad delegation does not go unnoticed. Pair it with the SSL Checker after any DNS change. Both are free for core use, and the rest of the toolkit, including traceroute and an IP lookup, is on the Pingfloat homepage. If you want to script checks, the Pingfloat Public API is there too.
Prevention checklist
- Keep at least two nameservers, and confirm the registrar list matches your live zone.
- Lower TTLs a day or two before planned changes, and raise them again afterward.
- Remove records for services you no longer use.
- Review SPF, DKIM, DMARC and PTR records whenever you change mail providers.
- Keep a change log with old values.
- Monitor the hostname and its certificate continuously.
The NIST draft on secure domain name systems, since withdrawn, made a related point: it advised continuously monitoring and validating public-domain integrity and noted that attackers can exploit misconfiguration and lapsed domain registrations. Treat it as direction rather than a binding standard.
FAQ
How do I fix a corrupted DNS?
Usually nothing is corrupted. You are looking at a bad cache or a wrong record. Flush the local cache with ipconfig /flushdns on Windows, then query the authoritative nameserver to see what is configured. If that answer is wrong, edit the record at your DNS provider.
Is changing DNS to 8.8.8.8 safe?
Yes, switching to a major public resolver such as 8.8.8.8 or 1.1.1.1 is a normal diagnostic step and is easy to undo. It can rule out a faulty ISP resolver. It cannot repair a misconfigured zone, because the records are served by your domain's own nameservers.
What happens if I flush the DNS cache?
Your device discards stored lookup results, including negative entries, and asks resolvers again on the next request. Nothing is deleted from your domain's records. The only cost is slightly slower first lookups.
How do I reset DNS back to normal?
On your device, set the adapter's DNS to automatic so it uses the router or ISP resolver, then flush the cache. For a domain, restore the documented previous record and TTL from your change notes, then verify against the authoritative server.
Sources
- Common DNS issues and how to fix them (Cloudflare)
- RFC 1912: Common DNS Operational and Configuration Errors
- Common DNS Issues and How to Solve Them (Bluehost)
- What is a DNS Misconfiguration? (CloudSEK)
- Troubleshoot DNS SERVFAIL responses in Route 53 (AWS)
- Troubleshoot Azure DNS (Microsoft Learn)
- Troubleshooting DNS clients (Microsoft Learn)
- Troubleshooting DNS Servers (Microsoft Learn)
- ipconfig (Microsoft Learn)
- General DNS issues (Cloudflare DNS docs)
- Phase 2: Preparation (Cloudflare Learning Paths)
- DNS, TLS and Deployment Triage (Saylor Innovations)
- DNS Management Best Practices (ManageEngine OpUtils)
- NIST SP 800-81r3 initial public draft