Frankfurt am Main, 8 May 2026
During a routine DNSSEC key rollover on 5 May 2026, some non-validatable signatures were generated and distributed. As a result, validating resolvers were temporarily unable to successfully verify their DNS responses for .de domains. This led to noticeable restrictions in the accessibility of .de domains for approximately three hours. Normal operations were fully restored during the night.
What caused the invalid signatures to be generated?
The DNSSEC signing process for DE uses standard software (Knot) and in-house developments in conjunction with Hardware Security Modules (HSMs). In April 2026, we deployed the third generation of this system (since the introduction of DNSSEC in 2011). The systems were tested in advance and externally audited. During the implementation of improvements, a faulty piece of code was incorporated into the in-house development which was not fully covered by the test scenarios and was therefore not identified as defective during test runs or in ‘cold’ parallel operation prior to commissioning. Consequently, for the same “key tag” (33834), three different key pairs were generated instead of a single one, of which only the public key of a single pair was stored in the DNSKEY RR, meaning that only about a third of the RRSIG RRs could be validated. As the SOA record must be regenerated and therefore also signed with every zone change due to the serial number, it was at times validatable and at times not validatable.
Why was a non-validatable .de zone published?
The .de zone is regularly updated via the registration system, and the resulting changes to the RRSets are applied incrementally due to the size of the zone. The individual versions of the zone (by SOA serial number) are not available as a ‘zone file’. We use three different continuously running checking and validation tools on the production .de zone to detect any anomalies, including missing or non-validatable signatures. These systems detected the issues as intended, but the notifications were not processed correctly.
How can the impact be described?
The validation of DNS responses in a TLD zone, which predominantly returns ‘referral responses’ (i.e. delegation information), also depends on signed NSEC3 RRs, particularly when the absence of the DS record must be ‘proven’ for an unsigned child zone.
Invalidatable signatures over NSEC3 records result in the delegation information being classified by resolvers as bogus, meaning that even second-level domains for which DNSSEC is not used at all could not be resolved.
Some operators of large resolvers had temporarily deactivated the validation of .de domains, thereby mitigating the impact on their users. We would like to thank them for their help.
Further details will be shared on this blog once the analyses have been completed.
The information is based on current findings and details may be subject to change.
