DNSSEC and SERVFAIL: Find the Cause of Resolution Failure

SERVFAIL indicates a resolution failure, without providing a complete diagnosis. When a domain works on some networks and fails on others, DNSSEC is one possibility: a validating resolver can reject data that others return. Establish that cause before changing a zone or client settings.

The following procedure applies to a public domain you administer or whose public data you can examine. The .example names and documentation addresses are fictional. Replace them with authorized values from your environment, keeping internal names out of public diagnostic tools.

Preserve the failure before making changes

Start with the exact name and query type affected. An application can fail on a subdomain or a CNAME target while the main domain still resolves. Record the time, resolver, client network and complete status.

Capture answers with their options and sections, rather than recording only whether an address appeared. Retain a control name known to work through the same path. If every query fails, investigate the broader outage before focusing on a particular signature.

# Fictional examples using a documentation resolver address and domain.
dig @192.0.2.53 portail.service.example. A +dnssec
dig @192.0.2.53 portail.service.example. AAAA +dnssec

The +dnssec option requests available DNSSEC data. It does not turn dig into a complete chain validator. A visible RRSIG record is data to examine; its presence alone does not prove that validation succeeded.

Read the resolver’s detailed errors

Look for additional diagnostics in the output and resolver logs. Extended DNS Errors can indicate an expired signature, a missing key or unreachable authoritative servers. RFC 8914 defines these indications as additional information alongside DNS response codes.

Preserve the received number and text. Missing detail does not rule out DNSSEC. Conversely, a precise indication still needs checking against the affected zone and period, particularly when several caches or intermediate servers are involved.

Avoid interpreting SERVFAIL as “domain does not exist.” If the actual code is NXDOMAIN, the investigation concerns a different condition. Combining these errors in a dashboard can send a validation outage to a team expecting to correct mistyped names.

Compare with validation disabled for one test

Using the same resolver at approximately the same time, a query with the Checking Disabled bit can help isolate the validation step:

# A diagnostic test, not a production configuration.
dig @192.0.2.53 portail.service.example. A +dnssec +cdflag

If the ordinary request fails while this test returns data, validation becomes a priority for investigation. The Google Public DNS troubleshooting guide uses this comparison to identify DNSSEC problems. The result does not prove that the returned data is trustworthy.

Do not browse to the destination on the strength of this test. Save both outputs, then examine the delegation and signature data. If both requests fail, investigate authoritative server availability, delegation and network transport as well.

Locate the break in the chain of trust

For a signed zone, examine the DS records published by its parent, the DNSKEY records published by the zone and the signatures on the relevant record sets. RFC 4035 describes validation processing and the role of this data in the chain of trust.

Focus your investigation on recent changes: a registrar transfer, DNS migration, key rollover, restoration of an older zone or signing service failure. Ask the technical owner for the expected configuration and compare it with the data actually being served.

Consider a fictional migration of service.example to a new DNS provider. The parent retains a DS associated with the old key, while the new authoritative servers publish different DNSKEY records. Clients receive errors after their earlier cached data expires. Repair requires restoring a consistent chain with the zone operator and registrar; changing user resolvers would conceal the defect.

Also check signature validity periods and the resolver’s system time. A clock discrepancy can produce a misleading result. Archive the exact data before replacing it so the incident can be reviewed later.

Check authoritative servers and the network

Query the authoritative servers individually from an authorized location. Different responses can reveal an incomplete deployment or a server retaining an old zone. Record which server responds, the record set it supplies and the SOA serial number where relevant.

If large responses fail, compare UDP and TCP behavior and inspect filtering along the path. Simultaneous network and DNSSEC changes make the diagnosis harder. Change one variable at a time and record the expected result before each test.

A public diagnostic tool can illustrate the chain for a public domain. Treat its result as an additional observation, with its own timestamp and vantage point. It cannot replace the response received by affected clients or the logs of the enterprise resolver.

Verify the repair through the original path

After a correction, repeat the original request with validation enabled. Check the exact name, affected record types and different networks that previously failed. Retain the before and after outputs, the modification time and details of any cached data still being served.

The expected result is correctly validated resolution that does not depend on +cdflag. If a cache flush is needed to accelerate a local check, record that explicitly. Other clients can still be affected by different caches and need appropriate follow-up monitoring.

The DNS hardening guide covers preventive measures after the incident. If the investigation involves a suspicious destination, also use the method for correlating DNS and process events.

DNSSEC does not certify website content. Consult a domain reputation report to investigate that separate question, retaining distinct conclusions about DNS integrity and any observed evidence of abuse.