DENIC .de DNSSEC outage

DENIC .de DNSSEC outage post-mortem — three private keys generated with the same Key Tag (33834); only one DNSKEY published

UPDATE · originally covered DENIC .de DNSSEC outage — faulty key rollover; 3.5 h disruption for German government and public-sector .de domains (2026-05-09)

DENIC published its formal technical post-mortem on 2026-05-08 (DENIC analysis blog (German), 2026-05-08 · heise online, 2026-05-08).

Confirmed root cause: a code defect in DENIC's third-generation custom signing infrastructure (deployed April 2026 atop Knot DNS). During a routine Zone-Signing-Key rotation the code generated three private key pairs all assigned the same Key Tag (33834) rather than a unique tag per key — and only one corresponding public DNSKEY record was published to the zone. The RRSIG records signed by the two unpublished keys were therefore unvalidatable; DNSSEC-validating resolvers marked all .de delegations as "Bogus", which through the bogus NSEC3 trust path also took down resolution for non-DNSSEC-signed .de domains.

The outage ran 2026-05-05 21:43 UTC → 2026-05-06 ~01:15 UTC (~3.5 h). Critically, DENIC notes the monitoring pipeline detected anomalous resolver behaviour but the alerting layer did not correctly forward the alerts — the SIEM-rule equivalent of a fire-but-don't-page failure. Knot DNS itself is not implicated; the bug was in DENIC's automation layer atop Knot.

Defender takeaway: DNSSEC registry-side errors are indistinguishable from attacker-induced trust failures from a resolver's perspective. Validating-resolver operators in DACH and EU public-sector environments should keep RFC 7646 Negative Trust Anchor capability live for continuity during registry incidents and ensure runbooks separate "registry KSK/ZSK rollover defect" from "zone-level attack on a downstream domain".

DENIC .de DNSSEC outage — faulty key rollover; 3.5 h disruption for German government and public-sector .de domains

On 2026-05-05 at 21:43 UTC, DENIC (the .de domain registry) began distributing invalid DNSSEC signatures for the .de TLD, making approximately 18 million .de domains unreachable for DNSSEC-validating resolvers for roughly 3.5 hours (DENIC blog post-incident report, 2026-05-08 · DENIC initial report, 2026-05-05). Root cause: a software defect in DENIC's HSM integration code introduced during a March 2026 migration to Knot DNS generated three key pairs sharing keytag 33834, but only one public key was published in the zone; inconsistent signing across name servers followed. Cloudflare deployed a Negative Trust Anchor under RFC 7646 for its resolvers within ~90 minutes; DENIC restored service by 01:15 UTC on 2026-05-06. Crucially, .ch was unaffected (heise online, 2026-05-08 · Cloudflare blog). This is an operational misconfiguration, not an attacker action.

DENIC .de DNSSEC outage — 3.5 h registry-side trust failure traced to keytag 33834 collision and an alerting-layer fire-without-page

On 2026-05-05 starting approximately 19:30 UTC (per Cloudflare's recorded incident-start timestamp), DENIC (the .de registry) began distributing invalid DNSSEC signatures for the .de TLD, making .de TLD resolution fail across DNSSEC-validating resolvers for roughly 3.5 hours; Cloudflare's write-up describes potential impact on "millions of domains" without quantifying the count. The 2026-05-08 post-mortem confirmed the root cause: a code defect in DENIC's third-generation custom signing infrastructure (deployed April 2026 atop Knot DNS) generated three private key pairs all assigned the same Key Tag (33834) during a routine Zone-Signing-Key rotation, while only one corresponding public DNSKEY record was published to the zone. RRSIG records signed by the two unpublished keys were therefore unvalidatable; resolvers marked all .de delegations as "Bogus", and the bogus NSEC3 trust path also took down resolution for non-DNSSEC-signed .de domains. Cloudflare deployed an RFC 7646 Negative Trust Anchor for its resolvers at 22:17 UTC — a roughly 2-hour-47-minute mitigation gap from the recorded incident start. Critically, DENIC notes the monitoring pipeline detected anomalous resolver behaviour but the alerting layer did not correctly forward the alerts — a fire-without-page failure. Knot DNS itself is not implicated; the bug was in DENIC's automation layer (DENIC analysis blog, 2026-05-08 · Cloudflare blog · heise online, 2026-05-08 · daily 2026-05-09 · daily 2026-05-10 post-mortem UPDATE).