Investigate DNS SERVFAIL using controlled resolver comparisons, authoritative nameserver checks and DNSSEC evidence rather than switching DNS servers blindly. The safest recovery is the one supported by a repeatable test: establish the failure boundary, apply a single scoped change and compare the exact original action.
Symptoms: recognize the exact failure
Use the actual error text and product context before applying advice found for a similar-looking code. A meaningful diagnosis establishes when the failure starts, which users or devices are affected, and what continues to work.
- One hostname returns SERVFAIL while other domains resolve normally.
- The failure appears after DNSSEC key rollover, NS migration or a delegation change.
- Different recursive resolvers return different answers or error states.
Capture the affected product/version, timestamp, recent installation or configuration change and a sanitized error message. If a failed operation may have created an order, payment, data change or email, check for a successful earlier attempt before trying again.
Before changing settings: protect your data and access
Do not globally disable DNSSEC validation, publish private DNS zones or blindly delete DS records. Incorrect DNS changes can affect email and all hosted services.
Save relevant configuration or files before altering them. On managed devices or production services, follow the owner’s approval and backup policy. Prefer a staging or test account for risky comparisons. One change at a time lets you distinguish cause from coincidence and provides a clear rollback.
Step-by-Step Troubleshooting
Select Beginner for low-risk checks. Use Advanced for targeted diagnostics once you have captured the original error and protected your data.
Record the exact name and query type
Capture the fully qualified domain, whether the request is A, AAAA, MX or TXT, the resolver used and time. Avoid exposing private internal zone names publicly.
Separate SERVFAIL from NXDOMAIN
NXDOMAIN indicates that the queried name does not exist in the answer context; SERVFAIL indicates the server could not complete a resolution. Browser “site not found” messages can hide this distinction.
Compare one other trusted resolver
Use an approved second recursive service, not a random public resolver demanded by a “fix DNS” website. If results differ, retain the evidence before any configuration edit.
Check hosting and domain change history
Look for recent registrar nameserver changes, DNSSEC activation, DS updates, zone signing or expired authoritative DNS service. A plain device reboot cannot repair a broken delegation.
Query via dig or nslookup
Run dig against the current recursive resolver, recording response code and flags. Compare nameservers returned from the parent zone with those actually serving the domain.
dig example.com Adig example.com +traceTrace delegation and authoritative availability
For public zones you operate, use dig +trace with the understanding it bypasses ordinary recursive behavior. Confirm glue, NS records and UDP/TCP port 53 reachability.
Inspect DNSSEC validation chain
Check DS and DNSKEY alignment, RRSIG validity and time synchronization. If signatures are invalid, fix signing or delegation records through the authorized DNS operator.
Correlate resolver logs and packet symptoms
On your own resolver, review timeout, truncation, filtering and validation errors. Correct the confirmed problem, then allow TTL/caching effects to settle before retesting.
Diagnosis: how to distinguish the likely causes
The numbered Beginner and Advanced procedures above produce evidence. Use it with the following decision table rather than applying every possible fix. An apparent match is a hypothesis until the original action succeeds after the isolated correction.
| Possible cause | Evidence to look for | Safer next action |
|---|---|---|
| DNSSEC validation problem | A validating resolver returns SERVFAIL while evidence suggests a broken signature or DS chain. | Inspect chain-of-trust records rather than disabling validation. |
| Authoritative server unreachable or inconsistent | Several resolvers fail to obtain authoritative answers. | Review nameserver delegation, firewall and DNS service health. |
| Recursive resolver outage or policy | One resolver fails but independent trusted resolvers answer normally. | Check resolver logs, filtering or upstream transport reachability. |
What to record if the first checks are inconclusive
When comparing attempts, keep the input and environment as similar as possible. Document which device, user, endpoint, account or server was tested, the exact command or menu action, its result and any new message. A symptom disappearing once is useful evidence but not proof of a durable repair.
If a change has no effect, revert it before testing another theory. Repeated reinstallations, account resets or broad security exceptions can introduce new problems that obscure the original cause.
How to verify that the repair worked
Repeat the original failure scenario, not a loosely related test. Then check a nearby function that could have been affected by the change. This distinguishes a real repair from a workaround that only avoids the broken step.
- The original queried records resolve correctly through the intended validating resolver.
- The authoritative chain and other record types remain healthy after cache expiry.
Keep the result in a short incident record: original symptom, environment, confirmed cause, exact fix, follow-up test and rollback method. If the cause was never confirmed, label it as unresolved even when one retry succeeds.
Complete the following article-specific checklist while checking the original operation; the progress counter is a reading aid, not a guarantee that every configuration or account is healthy.
Solution Checklist
If it still fails: rollback and escalation
If a DNSSEC or delegation change worsens resolution, restore the known-good signed zone/registrar configuration and coordinate with the DNS provider on propagation.
Escalate with the exact error, sanitized logs or screenshots, time of failure, product/version, affected scope and what each controlled test changed. Do not send passwords, session cookies, recovery codes, authentication tokens, private customer data or unrestricted database dumps.
How to prevent the problem from returning
- Document zone signer, registrar DS owner and NS delegation responsibilities.
- Monitor DNSSEC signature expiration and probe resolvers from more than one network.
Schedule updates and configuration changes with a known-good backup, a narrow verification procedure and a rollback owner. Alerts should target the observable failure, not just a generic service-up indicator.
Frequently asked questions
Does this error always have one cause?
No. DNS SERVFAIL describes an observed failure in a particular product or workflow; surrounding log entries, update history and the scope of the problem determine which cause is most likely.
Should I reinstall or reset the device immediately?
Usually not. Reinstallation or a reset can erase useful diagnostic evidence and affect files or settings without addressing a remote service, account, permission or network cause. Exhaust read-only and reversible checks first.
When should I ask the vendor or administrator?
Escalate when the issue follows an account across devices, needs privileged access, affects production data, involves potential hardware failure or continues after the supported troubleshooting steps.
Related PRBLEM troubleshooting
For a distinct but related failure, compare the diagnosis in Chrome ERR_NAME_NOT_RESOLVED. Different error codes can share symptoms but still require separate, evidence-based fixes.
Further reading: official documentation
Instructions and menus can change by version, hosting provider and policy. Verify the current manufacturer documentation for your exact environment before following privileged or data-changing examples.
Disqus hosts the discussion. Comments load automatically as you approach this section and may use cookies.