A DNS response with the AD flag set carries a resolver's assertion that the relevant data was authenticated according to its validation process. It does not mean the browser independently verified every signature, and it does not mean the website reached through that answer is safe.
To investigate DNSSEC, follow the chain from a configured trust anchor through parent delegation records to the child's signing keys and signed data. Keep resolver behaviour, record publication and application connectivity separate. A failure in one layer can appear as a generic name-resolution error in another.
Identify who performed validation
The DNSSEC inspector queries through the site's server and Google Public DNS. It reports resolver results, including authentication-related flags and requested DNS data. It does not implement an independent validating resolver inside the browser.
That distinction gives the result a clear scope. You are observing what a particular resolver returned at a particular time. Another resolver can have different cache contents or validation policy. A local network can also use a different resolver from the diagnostic service.
Record the queried name, record type, response status and flags. An AD flag without the question and response context is incomplete evidence. Likewise, an absent AD flag alone does not identify a broken signature; the zone may be unsigned or the resolver may not be asserting validation in that response.
Follow DS, DNSKEY and RRSIG roles
A DNSKEY record publishes a zone's public signing key. An RRSIG record contains a signature over a particular record set. A DS record in the parent identifies a child key through a digest and associated fields, connecting the child zone to the parent's authenticated delegation.
The chain matters because a signature verified with an arbitrary key proves only a relationship to that key. The resolver needs a trusted path to the key it accepts. Publishing DNSKEY records in a child zone without the appropriate delegation does not automatically create a chain from the root.
Conversely, publishing a DS record at the parent before the child is correctly signed can break resolution for validating clients. The parent is asserting a secure delegation that the child cannot satisfy. This is why DNSSEC changes must coordinate registrar and authoritative DNS settings.
| Record or flag | Role | Review point |
|---|---|---|
| DS at the parent | Connects delegation to a child key | Does it identify a currently valid published key? |
| DNSKEY in the child | Publishes verification key material | Is the expected key present during rollover? |
| RRSIG | Signs a record set | Are validity times and signing relationships correct? |
| AD flag | Resolver authentication assertion | Which resolver, query and response produced it? |
| SERVFAIL | Resolution could not complete | Is validation the cause, or another resolver failure? |
Diagnose a failure after a DNS provider change
Suppose a domain moves authoritative DNS providers and begins failing only for some users. Ordinary records look correct at the new provider. The registrar still publishes a DS record for the old provider's key. A validating resolver follows that delegation and cannot authenticate the new zone with the expected key.
Check the parent DS record independently of the new provider's control panel. Then inspect the DNSKEY records served by the new authoritative nameservers. Compare the key tag, algorithm and digest relationship using appropriate DNSSEC tooling rather than comparing only a visible fragment of a key.
Follow the provider's migration procedure to establish a consistent chain. The safe sequence depends on whether keys can be shared, whether both providers can serve the zone and how the parent update is managed. Do not copy a generic remove-and-readd sequence into a production migration without accounting for cached delegation data.
After the correction, check multiple validating resolvers and record remaining TTLs. Some clients may retain earlier answers or failures temporarily. A successful direct query to one authoritative server does not show that every recursive resolver has refreshed its cached chain.
Check signature time and key rollover
DNSSEC signatures have inception and expiration times. A signing system with a clock problem or failed refresh can publish signatures that are not yet valid or have expired. The ordinary record values can remain unchanged while validation begins failing.
Monitor signing and rollover processes, not just the presence of DNSKEY records. A dashboard that confirms a key exists can miss expired signatures. Keep alerts tied to the validity window and the nameservers actually serving the zone.
During rollover, old and new data may coexist in caches. The publication sequence must allow validators to find the keys needed for signatures they can still encounter. Follow the authoritative provider's documented process and verify parent updates before retiring old key material.
Distinguish unsigned from bogus
An unsigned zone under a delegation that does not establish a secure chain is different from a signed zone whose chain fails validation. The first can resolve normally without authenticated data. The second can produce a validation failure for a resolver that expects a valid chain.
Do not label every response without AD as broken. Review whether the delegation is intended to be secure. Also check the resolver's behaviour and query options. An unavailable service, timeout or unsupported response field should remain a separate result from a DNSSEC failure.
Negative answers can also be authenticated through DNSSEC mechanisms. A signed proof that a name or type does not exist is different from simply receiving no record. When debugging a missing record, preserve the complete response and use a validating diagnostic tool that can explain the denial evidence.
Keep DNS authenticity separate from service trust
DNSSEC protects the authenticity and integrity of DNS data within its trust model. It does not encrypt the query, hide the requested hostname or inspect the content of a website. A correctly signed answer can point to a service with an expired TLS certificate or a compromised application.
After resolving the DNS issue, test the service separately. Check the requested hostname, TLS certificate identity and the actual application response. An AD flag is useful evidence about DNS, but it is not a substitute for those checks.
The path to the resolver also matters to the client interpreting the assertion. This tool observes a response obtained through its documented service path. If you need assurance for a different client environment, inspect that environment's resolver configuration and transport rather than assuming the same path applies.
Prepare an actionable DNSSEC incident note
Include the affected names, record types, authoritative nameservers, observed parent DS records, child key details and signature validity times. Record which resolvers fail and which succeed, with timestamps. State the recent change, such as provider migration or key rollover, if known.
Keep the note factual: validating resolver A returned SERVFAIL while authoritative server B returned the expected record is a useful starting point. It becomes a diagnosis only after evidence connects the failure to the chain. This prevents teams from disabling validation to conceal an unrelated outage.
For the follow-up review, document who owns registrar changes and who owns zone signing. A technically sound rollover can still fail when those responsibilities are split and nobody confirms the final parent state. Make that confirmation part of the operational procedure.
Check authoritative consistency during a rollover
Query each authoritative nameserver for the relevant DNSKEY and signed record set. If one server still serves an old view, a recursive resolver can encounter a different chain depending on which server it contacts. Record the server and response time with each sample. Repair publication consistency before interpreting resolver differences as random behaviour. The parent delegation and child signing state must remain compatible throughout the planned rollover window.
Frequently asked questions
Does AD mean this tool validated the chain itself?
No. The tool reports the upstream resolver's authentication assertion. It does not independently perform the full DNSSEC validation process in the page. Keep that attribution in reports so readers understand which component supplied the evidence and can reproduce the query through the same or another validating resolver.
Is SERVFAIL proof of a DNSSEC problem?
No. Resolution can fail because of timeouts, unreachable servers and other conditions. DNSSEC validation is one possible cause. Compare complete resolver evidence, authoritative responses and delegation records before changing signing settings. A single status code does not identify the failing part of the chain.
Can I fix a stale DS record in the child zone?
The delegation's DS record is published at the parent, commonly through the registrar's interface for a registered domain. Editing a similarly named record only inside the child does not update that parent state. Coordinate the correct control plane and verify the authoritative parent response after the change.
Does DNSSEC encrypt DNS traffic?
No. Authentication of DNS data and confidentiality of the transport are separate concerns. DNSSEC signatures do not hide the query name. Encrypted DNS transports address a different part of the path, and neither mechanism establishes that the destination application is trustworthy.
What should I monitor after enabling DNSSEC?
Monitor validation from representative resolvers, signature expiration, authoritative consistency and key rollover state. Include the parent delegation in checks. A one-time successful setup does not guarantee later renewals or provider changes will preserve the chain, so operational ownership matters as much as the initial configuration.