DENIC re-signed the affected NSEC3 hash range at 20:15 UTC using a new key (keytag 32911). Google DNS (8.8.8.8), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9) all return NOERROR. The issue is fully resolved.
Earlier status: a signing run at 20:33 UTC had only updated the SOA RRSIG, not the malformed NSEC3 RRSIG (keytag 33834). The final fix was delivered by a targeted re-signing run with keytag 32911 at 20:15 UTC.
Incident Summary
On May 5, 2026, several prominent .de domains became unreachable for users with DNSSEC-validating resolvers. Affected domains included bahn.de, spiegel.de and blackfort-tec.de — domains with no shared operator, no shared hosting and no shared DNS infrastructure.
The common denominator: all affected domains fell within the same NSEC3 hash range in the .de zone. An NSEC3 record in that zone was served with a malformed or corrupted RRSIG signature (keytag 33834). Validating resolvers then deemed the entire DNSSEC trust chain invalid and responded with SERVFAIL.
Evidence points to a transient fault in the DNSSEC signing infrastructure of DENIC — the German ccTLD registry for .de — rather than any misconfiguration by individual domain operators.
Observed Symptoms: SERVFAIL Despite Functional Infrastructure
The starting point was the browser error DNS_PROBE_FINISHED_NXDOMAIN for www.blackfort-tec.de. Initial diagnostics showed the domain itself was perfectly configured: A record present, nameservers reachable, no configuration error.
Browser error DNS_PROBE_FINISHED_NXDOMAIN or general unreachability for a subset of users, even though the DNS zone is correctly configured and the authoritative nameservers resolve the domain without issues.
$ dig @8.8.8.8 www.blackfort-tec.de A ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL ; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for ; a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834)) $ dig @9.9.9.9 blackfort-tec.de A ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL ; EDE: 6 (DNSSEC Bogus) $ dig @8.8.8.8 +cd blackfort-tec.de A # DNSSEC validation disabled ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; ANSWER SECTION: blackfort-tec.de. 600 IN A 178.104.208.93
With the +cd flag (Checking Disabled) the domain resolved immediately and correctly. The infrastructure problem was therefore clearly not with the domain operator but in the DNSSEC validation chain.
Technical Findings: Malformed RRSIG for NSEC3 in the .de Zone
Further analysis revealed a precise error pattern. When querying blackfort-tec.de with DNSSEC, the DENIC nameservers return an NSEC3 record to prove the absence of a DS record. This NSEC3 record must be signed with an RRSIG — and it was exactly this signature that was malformed:
# DENIC nameserver delivers NSEC3 for blackfort-tec.de DS absence
$ dig @f.nic.de +dnssec blackfort-tec.de DS
;; AUTHORITY SECTION:
a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN NSEC3 1 1 0 - A0D5F6VE... NS SOA RRSIG DNSKEY NSEC3PARAM
a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN RRSIG NSEC3 8 2 7200 \
20260519191938 20260505174938 33834 de. DZhBfHZt+n/IFEdUgog...
# Google refuses to validate this signature:
; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature found for
; a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834))The DENIC zone-signing infrastructure delivered an RRSIG signature with keytag 33834 for the NSEC3 record covering the hash range around blackfort-tec.de that multiple independent DNSSEC-validating resolvers classified as malformed. The signature was formally present but failed cryptographic verification.
The identical malformed NSEC3 signature pattern appeared for other domains in the same hash range — including spiegel.de and bahn.de — confirming a range-wide signing error in the .de zone.
Why Only Some Users Were Affected
DNSSEC validation is not a universal standard. Whether a resolver checks cryptographic DNS signatures depends entirely on its operator.
| Resolver | IP | DNSSEC Validation | Result |
|---|---|---|---|
| Google Public DNS | 8.8.8.8 | Yes (strict) | SERVFAIL / DNSSEC Bogus |
| Cloudflare | 1.1.1.1 | Yes | SERVFAIL |
| Quad9 | 9.9.9.9 | Yes (strict) | SERVFAIL / DNSSEC Bogus |
| German ISP resolvers | variable | No / partial | NOERROR – domain reachable |
Users running Google DNS, Cloudflare or Quad9 — typically tech-savvy users, developers, businesses with explicitly configured DNS, or modern operating systems with DoH/DoT — could not reach the affected domains. Users on default German ISP configurations were not affected.
Lessons Learned
Establish DNSSEC Monitoring
Regular automated queries of your own domains against multiple validating resolvers (Google, Cloudflare, Quad9) should be a fixed part of security monitoring. Alerting on SERVFAIL or DNSSEC-Bogus responses is not optional.
Monitor RRSIG Expiry
Expired DNSSEC signatures are a common cause of DNSSEC outages. Monitoring expiry dates of all relevant RRSIGs provides sufficient lead time to act before users are affected.
Incident Response for DNS Failures
Not every DNS outage stems from your own infrastructure. Incident response processes should explicitly cover the case where an external actor (registry, upstream resolver) is the root cause — including an escalation path to your registrar.
Know the Diagnostic Path
On DNS_PROBE_FINISHED_NXDOMAIN, always test against the authoritative nameserver first (+cd flag). Only if that returns correct answers does the problem lie upstream. Then: check DNSSEC validation, isolate the resolver.
Prepare Registrar Communication
For DNSSEC errors at TLD level, the registrar is the first point of contact. A documented error report (dig output, affected resolvers, timestamps) significantly speeds up escalation to the registry.
Integrate DNSSEC Status into SIEM
DNSSEC monitoring belongs in the same SIEM as certificate monitoring and availability checks. Only then are correlations between DNS outages and other security events visible.
Frequently Asked Questions
What does SERVFAIL mean in DNS?
What does DNSSEC Bogus mean?
What is NSEC3?
Why were some users affected and others not?
How should organisations monitor for DNSSEC problems like this?
Conclusion: DNSSEC Monitoring Belongs in Every Security Programme
This incident illustrates an important, often underestimated attack surface of modern internet infrastructure: the DNSSEC trust chain. Even correctly configured domains can become selectively unreachable due to errors in an upstream zone — for precisely those users who apply the highest security standards. DNS is not set-and-forget infrastructure. The dependence on a correct DNSSEC signature chain — from the root zone through the TLD registry to your own nameserver — requires continuous monitoring, documented incident response processes and clear escalation paths to your registrar.