.de zone serving malformed RRSIGs over NSEC3

[Nils Lind]

Posting in case anyone else is seeing this and to give DENIC additional
visibility. As of ~2026-05-05 21:43 UTC, validating resolvers are returning
SERVFAIL with EDE 6 (DNSSEC Bogus) for a substantial fraction of .de names,
including denic.de itself. == Symptom == $ dig denic.de @8.8.8.8 +noall
+comments ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL ; EDE: 6 (DNSSEC
Bogus): (RRSIG with malformed signature found for
a0d5d1p51kijsevll74k523htmq406bk.de/nsec3 (keytag=33834)) $ dig denic.de @
8.8.8.8 +cd +short # bypass validation -> resolves Reproduces against
8.8.8.8, 1.1.1.1, 9.9.9.9. Quad9's non-validating endpoint 9.9.9.10 returns
the answer with EDE 6 set. CD=1 always works. == Scope (quick sample,
8.8.8.8) == google.de NOERROR (cached/working for now) heise.de NOERROR
(cached/working for now) denic.de SERVFAIL EDE 6 bahn.de SERVFAIL EDE 6
spiegel.de SERVFAIL EDE 6 bmw.de SERVFAIL EDE 6 telekom.de SERVFAIL EDE 6
nonexistent-test-zzz.de SERVFAIL EDE 6 (NXDOMAIN proof also fails) The
"still working" set is presumably whatever still has good cached
signatures; expect it to shrink as TTLs expire. == Where the chain breaks
== root -> .de DS OK .de DNSKEY rrset, signed by KSK 26755 OK .de NSEC3 +
SOA RRSIGs, signed by ZSK 33834 <-- malformed Chain of trust is intact down
to the DNSKEY rrset; the per-record signatures generated by ZSK keytag
33834 do not validate. RRSIG inception 2026-05-05 17:49:38 UTC, expiry
2026-05-19 19:19:38 UTC, so fresh signatures, not an expiry. Looks like a
ZSK / signer mismatch (private signer key not corresponding to the
published DNSKEY with that tag) or a botched ZSK rollover. == Not a
nameserver distribution issue == I queried four .de authoritatives at
different operators / networks for the same NSEC3 RRSIG: a.nic.de
194.0.0.53 f.nic.de 81.91.164.5 s.de.net 195.243.137.26 n.de.net
194.146.107.6 All four return BYTE-IDENTICAL RRSIGs (same
inception/expiry/keytag, identical base64). So the bad data left the signer
already broken — it is not a primary/secondary sync issue, anycast
inconsistency, or on-the-wire corruption. == Sample bad RRSIG (from
194.0.0.53) == a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN NSEC3 1 1 0 -
A0D5F6VETKD4HE1UG3NJGF20U4QMCIAQ NS SOA RRSIG DNSKEY NSEC3PARAM
a0d5d1p51kijsevll74k523htmq406bk.de. 7200 IN RRSIG NSEC3 8 2 7200
20260519191938 20260505174938 33834 de.
DZhBfHZt+n/IFEdUgogT4NpxzdkzLjUMslehShbTAbH6n4qaRnMH9zGu
gRutdlxWrtEywgA6XEpU+vsE2wBkS3BWXA1D1BWoLqmxETwqZSmXnJ30
IM16mtRwp9nxbWOMWAr/KfTiyoa+xPivpFl6Rg8jSzX3HIGGlLHAFVgZ KaY= == Repro ==
for r in 8.8.8.8 1.1.1.1 9.9.9.9; do dig denic.de @"$r" +noall +comments |
grep -E '(status|EDE)' done # check the bad RRSIG is identical across .de
authoritatives for ns in 194.0.0.53 81.91.164.5 195.243.137.26
194.146.107.6; do echo "--- $ns ---" dig denic.de DS @"$ns" +dnssec +noall
+authority \ | grep -E 'NSEC3 1 1|RRSIG NSEC3' done == Asks == 1. Anyone
else seeing this from other vantage points? Any reports of it clearing up,
or has it just started? 2. DENIC: a parallel report has been sent to
dns-operations at denic.de. 3. If anyone has a current contact at DENIC
outside that address, please ping them. Thanks


-- 

<https://www.assertiveyield.com/>

Nils Lind

Founder & CEO

nils at assertive.ai

<https://www.assertiveyield.com/>
<https://www.linkedin.com/company/assertive-yield>
<https://www.youtube.com/@assertiveyield>


<https://lp.assertiveyield.com/publishers-traffic-shaping>

-- 


*
*
Assertive Yield B.V.
Van Speijkstraat 44B
2518 GD Den Haag, NL


CoC: 
74301268, VAT: NL859845655B01



The content of this e-mail is intended 
exclusively for the designated addressee. Any form of knowledge, 
publication, duplication, or transmission of the contents of this e-mail by 
unauthorized third parties is prohibited. Please contact the sender of this 
e-mail if you are not the addressee of this e-mail and delete the material 
from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20260505/5fd54825/attachment.html>