Domain Resolves Fine for You, So It Can't Be DNSSEC? Test Against 1.1.1.1

A common first move when users say a site is down with SERVFAIL is to run a quick lookup from your own laptop or server, see a correct IP come back, and conclude it can't be DNSSEC. The logic seems sound: if the records were broken, they would be broken for everyone. With DNSSEC that logic fails, because the result depends on whether the resolver you asked actually checks signatures. Plenty of resolvers don't, and they will happily hand you an answer that a validating resolver refuses to accept.

Why your lookup says yes while others say no

When you type a domain into a browser, your device rarely talks to the domain's nameservers directly. It asks a recursive resolver (the DNS server your OS is configured to use) to go find the answer. That resolver might be your ISP's, your office router, a corporate DNS server, or a public service. Some of those resolvers perform DNSSEC validation and some don't. A non-validating resolver fetches the A record, caches it, and returns it. It doesn't look at the signatures at all. A validating resolver does extra work. It follows the chain of trust from the root zone down to your domain and checks that every link holds. If any link fails, it treats the whole answer as bogus and returns SERVFAIL instead of an IP. The chain of trust works roughly like this. Your zone publishes DNSKEY records, which are public keys. The Key Signing Key (KSK) signs the DNSKEY set, and the Zone Signing Key (ZSK) signs everyday records like A, MX, and TXT. Those signatures are stored as RRSIG records. The parent zone (for example .com) holds a DS record, which is a hash of your KSK. The validator checks that the DS at the parent matches a KSK in your DNSKEY set, that the KSK signature over the DNSKEY set is valid, and that the RRSIGs over your records are valid and not expired. So when an admin checks from a non-validating environment, they are testing whether the records exist. Users behind validating resolvers are testing whether the records can be trusted. Those are different questions, and during a DNSSEC break they have different answers.

Why it looks like a partial or random outage

This split produces confusing helpdesk reports. Some users can't reach the site at all, others have no problem, and the admin sees nothing wrong. Users on resolvers like Cloudflare's 1.1.1.1, Google's 8.8.8.8, enterprise security gateways, or ISPs that enforce validation get SERVFAIL. Users on non-validating resolvers keep working. Caching makes it messier. A validating resolver that cached a good answer before the break may keep serving it until the TTL runs out. Then that resolver starts failing too. The outage can look like it is spreading, when really caches are expiring one by one. The onset is usually sudden, and it often lines up with a change: a scheduled key rotation, a maintenance window, a move to a new DNS provider, or a migration to a self-managed nameserver. In support, the timing of the first reports is often the most useful clue. If tickets started right after someone touched DNS or keys, DNSSEC should be near the top of the list even if the zone looks fine.

Testing against validating resolvers

The test is simple. Ask a validating resolver for the record twice: once normally, and once with the CD (Checking Disabled) bit set. The CD bit tells the resolver to skip validation and return whatever it gets. If the normal query fails and the +cd query returns a correct answer, the records exist but the resolver rejected them on DNSSEC grounds.

BASH

# Normal query to validating resolvers
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

# Same queries with validation disabled (CD bit set)
dig @1.1.1.1 example.com A +cd
dig @8.8.8.8 example.com A +cd

Replace example.com with the affected domain. Look at the status: field in the header, not only the answer section. A DNSSEC failure typically looks like the first output below, while the +cd version comes back with NOERROR and the expected IP. On a healthy signed domain, the normal query returns NOERROR with the ad (Authenticated Data) flag set, which means the resolver validated the answer.

TEXT

Illustrative output format (normal query, DNSSEC broken):
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41822
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDE: 6 (DNSSEC Bogus)

Illustrative output format (same query with +cd):
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50317
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The EDE line is an Extended DNS Error, a newer mechanism that lets resolvers explain why they returned SERVFAIL. Whether you see it depends on your dig version and on whether the resolver sends it. When it is present, it saves time: codes like DNSSEC Bogus, Signature Expired, or DNSKEY Missing point you toward the broken link. If you don't see it, the SERVFAIL-versus-+cd comparison is still enough to confirm the category of problem. Two things are worth checking before you trust your earlier lookup. First, find out whether your own resolver validates. Query a domain you know is correctly signed through it and see whether the ad flag appears. If it never appears, your resolver probably isn't validating, and it can't tell you anything about DNSSEC health. Second, test both public resolvers. If both fail without +cd and both succeed with it, you can be confident it isn't a quirk of a single provider. If the failing name is a subdomain that points through a CNAME to an external service, the broken signatures might belong to the target zone rather than yours. That case is covered in How to Test If a Broken CNAME Target Is Causing DNS SERVFAIL.

Finding which link in the chain broke

Once validation is confirmed as the cause, the next question is where it breaks. The most common spot is the handoff between parent and child: the DS record at the registry no longer matches any KSK your nameservers publish. This tends to happen after a KSK rollover where the DS was updated too early, too late, or with the wrong digest. It also happens after a DNS provider move where the old DS was left at the registrar while the new provider signs with different keys. You can compare the two sides directly.

BASH

# DS record held at the parent zone, seen through a validating resolver
dig @1.1.1.1 example.com DS +short

# DNSKEY set served by your authoritative nameserver, with key IDs shown
dig @ns1.example.net example.com DNSKEY +multi

Replace ns1.example.net with one of the domain's actual authoritative nameservers. The first field of each DS line is the key tag. In the +multi DNSKEY output, dig prints a comment on each key showing whether it is a KSK or ZSK and its key id. The DS key tag should match the key id of a KSK in the served set, and the algorithm number should match too. If no KSK matches any DS, that is your break. Run the DNSKEY query against each authoritative nameserver. If they disagree, one of them is serving a stale or unsigned copy of the zone. If the DS and KSK line up, look at the signatures themselves. Expired RRSIGs are another common cause. This often happens when a zone was signed by one system and then moved somewhere that doesn't re-sign automatically, which is covered in Thinking DNSSEC Re-Signs Itself After Moving DNS to BIND, Until RRSIGs Expire. The third usual suspect is removing an old key before resolvers have stopped relying on it. If the old key disappears while cached signatures or a cached DS still reference it, validators lose the link until those caches expire. Tools like delv, which ships with BIND, can also walk the chain and report a validation verdict. It is useful when you want a direct explanation rather than inferring one from flags.

Building this into the routine

The pattern that holds up in production is to stop treating your local lookup as proof of anything DNSSEC-related. Your local resolver is a convenience, not a test environment. When a signed domain gets SERVFAIL reports, the first check should go to validating resolvers, with and without +cd, before anyone starts looking at the web server, the firewall, or the hosting account. The same check belongs in change procedures. Before a key rollover or a nameserver move, confirm that the DS at the parent matches what the new or current setup will serve. Afterwards, run the validating-resolver queries again, and repeat them after the old TTLs have passed. Many breaks only appear once caches expire. If you run monitoring, it is worth having at least one check that resolves through a validating resolver and alerts on SERVFAIL. Otherwise the monitor can stay green while a large share of users are locked out. On the support side, explaining this to a customer is easier than it sounds. Their site isn't down. The records are there. But some of the internet's resolvers no longer trust the signatures, so they refuse to answer. That framing usually stops the back-and-forth over whose network is broken. The practical rule: if a signed domain resolves for you but users report SERVFAIL, don't rule out DNSSEC until you have asked 1.1.1.1 and 8.8.8.8 directly and compared the result with +cd. If the +cd query works and the normal one doesn't, stop debugging the server and go compare the DS record with the DNSKEY set.