Start with the failure you can measure
If direct authoritative answers work but validating resolvers return SERVFAIL, check the parent DS record and DNSSEC chain before editing website records.
After an NS move, a validating resolver may return SERVFAIL even if the new zone contains correct A and MX records. A stale parent DS pointing to old signing keys is one possible cause; unreachable servers, inconsistent delegation and broken zones are others. Compare these paths before another DNS edit.
Because the fault can affect the whole domain, capture a timestamp and avoid repeated unplanned nameserver edits. The registrar and DNS provider control different parts of the chain; identify both before asking either to change settings.
Record delegation, answers and DS state
Write down the registrar’s currently configured nameservers, the provider’s assigned nameservers and any recent change time. Run dig NS example.com +short and dig DS example.com +short, replacing example.com with your domain. A DS record belongs to the parent-side DNSSEC delegation, usually managed through the registrar; it is not an ordinary website record in the new DNS zone. Query a real delegated server directly, such as dig @ns1.provider.example example.com A +noall +answer, and repeat for MX. If the authoritative server itself cannot answer, investigate its zone and delegation before blaming validation.
Keep copies of the original NS and DS settings. Do not paste an illustrative DS digest into a registrar form: it must match the signing provider’s actual key and supported algorithm.
Test for DNSSEC validation failure
- Ask a validating recursive resolver for a record:
dig @1.1.1.1 example.com A +dnssec. Note the status in the reply header, not merely an empty answer section. - Repeat with DNSSEC checking disabled for that query:
dig @1.1.1.1 example.com A +dnssec +cd. If the first query returns SERVFAIL but the second returns the expected answer, a validation problem is likely. The+cdoption is diagnostic; it does not fix visitors’ resolvers. - Compare the parent DS with the new provider’s documented DNSSEC state and key details. Ask the DNS provider to check the full chain if you cannot interpret the values.
- Test another record type or hostname. A domain-wide validation failure differs from a single missing A record, which more often returns NOERROR without an answer or NXDOMAIN for an absent name.
Results can differ while old NS or DS values remain cached. Save full output, resolver identity and timestamps. A SERVFAIL with both checks enabled and disabled points to a wider DNS problem rather than proving stale DS.
A validating resolver's SERVFAIL paired with an answer when checking is disabled is a clue to a DNSSEC validation fault; it is not confirmation that the DS alone is wrong.
Coordinate the DNSSEC repair
If an old DS is confirmed, the domain owner should ask the registrar and new DNS provider for their supported migration sequence. The usual non-multisigner path is to remove the old DS at the registrar, wait for its prior TTL to expire, complete the nameserver move and then enable signing at the new provider before publishing its new DS. For an already broken move, removing a stale DS may restore resolution after caches expire, but it temporarily removes the parent DNSSEC validation link. A coordinated multisigner move can preserve validation if both providers support it. Do not switch off signing at a provider while a matching DS remains cached; that can prolong the outage.
If no DS exists, compare the registrar delegation with the parent response and query every delegated nameserver. A server missing the zone or serving different data needs provider correction. Do not change website A, MX or application configuration solely because a validating resolver returns SERVFAIL.
Confirm recovery across the chain
Query authoritative nameservers and at least two recursive resolvers again without +cd. Confirm A, AAAA where used, MX and a TXT record relevant to mail. Recheck dig DS example.com +short: an absent DS is expected during an intentionally unsigned transition, while a published DS should match the new provider’s key. Test website and incoming mail once DNS resolves; DNS restoration alone does not prove application delivery.
If a registrar change is needed, provide the exact domain, the old and new provider, NS and DS observations, validating and checking-disabled results, and the change time. Never include registrar credentials. If recovery is urgent, keep both providers available until the operator has a verified rollback or repair path; restoring old nameservers can fail while cached DS or NS sets disagree.
Common questions
Does SERVFAIL always mean DNSSEC? No. It is a server failure status with several possible causes; the paired validation test narrows the diagnosis.
Can I fix this in DirectAdmin DNS Management? Only if that panel is authoritative and the fault is in its zone. Parent DS records are managed through the registrar or registry route.
Is waiting enough? Waiting helps caches expire after a correct repair. It cannot fix a permanently mismatched DS or broken delegated server.
Does an answer with checking disabled justify deleting DS? It suggests validation trouble; compare the full chain and provider migration instructions first.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.