DENIC published an invalid RRSIG over an NSEC3 record for nic.de, causing signature verification failure against ZSK 33834 and SERVFAILs on all .de lookups from validating resolvers.
Key Takeaways
Verisign DNSSEC Debugger confirms: RRSIG=33834 over the nic.de DS RRset does not verify, and all four DENIC nameservers (ns1-ns4) are unreachable.
The .de zone DS chain itself is intact at the root; the break is at the nic.de delegation, not the TLD apex.
dig +cd amazon.de @8.8.8.8 and queries direct to a.nic.de succeed, confirming zone data is present but DNSSEC validation is the failure point.
Any resolver enforcing DNSSEC validation returns SERVFAIL for every .de name until DENIC re-signs or TTLs expire.
Hacker News Comment Review
Commenters identified the precise fault quickly: a single bad RRSIG on an NSEC3 record, not a nameserver outage, with the extended DNS error citing keytag=33834 and a malformed signature.
Cloudflare disabled DNSSEC validation on 1.1.1.1 as a mitigation, illustrating the operational playbook when a registry-level signing error has economy-wide blast radius.
The incident reignited debate about DNSSEC’s centralization tradeoff: one signing mistake at a registry serializes all downstream validation, undermining DNS’s distributed fault-tolerance model.
Notable Comments
@tptacek: “Sometimes the world does my ranting for me” – then separately confirmed: “I think can call it on DNSSEC now.”
@qazwsxedchac: Frames the incident as a political risk – a single config mistake wiped reachability for a major economy overnight, with cache TTLs as the only blast-radius limiter.
