KeyTrap fix breaks resolving semi-bogus paste.debian.net/snow-crash.org

[Matt Nordhoff]

Hello,

I'm not sure if this is a bug or a feature, but the recent CVE fixes
prevent resolving paste.debian.net with DNSSEC validation on.

It is a CNAME:

$ dig +short paste.debian.net
apu.snow-crash.org.
p.snow-crash.org.
148.251.236.38

debian.net is fine, but snow-crash.org is misconfigured: It has an
algorithm 13 DS record, is correctly signed with algorithm 13, but is
also signed using algorithm 8 with signatures that expired a year
ago(!).

<https://dnsviz.net/d/paste.debian.net/ZczXYw/dnssec/>

Other resolvers, and older versions of BIND, ignore the bad/irrelevant
signatures and can still resolve the zone.

With the recent CVE fixes, BIND sees the expired RRSIGs, decides it's
bogus, logs the below, and returns SERVFAIL. I imagine it hits
max-validation-failures-per-fetch or some internal limit.

named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
bad signature (keyid=41523): RRSIG has expired
named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
37.120.176.165#53
named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
bad signature (keyid=41523): RRSIG has expired
named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
148.251.236.38#53
named[2540]: validating apu.snow-crash.org/CNAME: verify failed due to
bad signature (keyid=41523): RRSIG has expired
named[2540]: validating apu.snow-crash.org/CNAME: no valid signature found
named[2540]: RRSIG has expired resolving 'apu.snow-crash.org/A/IN':
2a01:4f8:201:3437::2#53

snow-crash.org is clearly misconfigured, but resolvers usually succeed
when they encounter both valid and invalid DNSSEC signatures. And this
domain has no algorithm 8 DS records at all, so the signatures and
keys can be ignored entirely.

Regarding DoS attacks, a resolver can ignore signatures that are
expired or use algorithms not included in the DS record without any
expensive cryptography.

I'm not necessarily saying this is a bug, but it might be an
interesting data point regarding the experimental new limits, and you
might want to consider changing the default or the accounting.

I noticed the issue using Quad9's 9.9.9.11 DNS resolver, and then
reproduced it on an Ubuntu 23.10 (amd64) VM by installing Ubuntu's
bind9 1:9.18.18-0ubuntu2 package with the default configuration and
then upgrading it to 1:9.18.18-0ubuntu2.1.

Some copy-and-pasted information at
<https://gist.github.com/mnordhoff/9286a264633fc12a262213a8d389f517>.
(Since I couldn't use <https://paste.debian.net/>...)

(I also did/will tell Quad9 about it for their information.)

Cheers,
-- 
Matt Nordhoff