Re: Unsupported DNSSEC algorithms should not lead to SERVFAIL.
Petr Menšík via bind-users <[email protected]>
| Newsgroups | gmane.network.dns.bind9.user |
|---|---|
| Message-ID | <09b4d73c-7b43-4306-ad1a-46186551b4e8__4551.72366216488$1762254364$gmane$org@redhat.com> |
Yes, this is broken by recent 9.18.41 release and 9.20.15 release as well. Domains signed by unsupported algorithm first, then supported algorithms second, incorrectly generate servfail. This case happens on RHEL9 and RHEL10 by default, because they consider algorithm 5 and 7 insecure. This is discussed in thread RHEL9+, RSASHA1 and CVE-2025-8677. Temporary fix is enabling SHA1 verification again. On RHEL9 by choosing DEFAULT:SHA1 crypto policy. RHEL10+ does not have policy created for it, but you can enable only signatures by custom OPENSSL_CONF file with contents: .include = /etc/ssl/openssl.cnf [evp_properties] rh-allow-sha1-signatures = yes Or can you test by copr build of 9.20: https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.20/ Alternatively, patch your build with: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/11202 It does help on my build, even without SHA1 enabled policy enabled. Thank you for sharing domain name with this problem, simplifies verification a lot. I would suggest owners of that domain to switch to more recent algorithm. Algorithm 8 is supported even by our ancient bind 9.8.2rc2 in RHEL 6. I know no supported version, which would not support at least algorithm 8. I see no point of double-signing algorithms 1 and 8. Instead 8 and 15, that would make more sense to me! If you can suggest it to owners of that zone, please do. Sorry for inconveniences caused by security fixes. These cases did not yet had tests, which would capture the behaviour change. Petr On 30/10/2025 23:13, Kelsey Cummings wrote: > Ondřej, any insight that you can shed into this behavior is > appreciated. These two systems have identical configuration other > than local addressing and version of bind installed: > > # named -v && delv -v && delv usfca.edu. && dig @localhost usfca.edu > BIND 9.18.41 (Extended Support Version) <id:1ed27e8> > delv 9.18.41 > ;; validating usfca.edu/A: no valid signature found > ;; no valid RRSIG resolving 'usfca.edu/A/IN': 69.12.208.107#53 > ;; algorithm is unsupported resolving 'usfca.edu/A/IN': 64.142.105.34#53 > ;; resolution failed: algorithm is unsupported > > ; <<>> DiG 9.18.41 <<>> @localhost usfca.edu > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12084 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: 63bbb3f67813f27e010000006903e1da959f03e4098ea706 (good) > ;; QUESTION SECTION: > ;usfca.edu. IN A > > ;; Query time: 39 msec > ;; SERVER: ::1#53(localhost) (UDP) > ;; WHEN: Thu Oct 30 15:08:26 PDT 2025 > ;; MSG SIZE rcvd: 66 > > > # named -v && delv -v && delv usfca.edu. && dig @localhost usfca.edu > BIND 9.18.28 (Extended Support Version) <id:1ed27e8> > delv 9.18.28 > ; fully validated > usfca.edu. 3372 IN A 23.185.0.2 > usfca.edu. 3372 IN RRSIG A 5 2 3600 > 20251103131709 20251030131458 43212 usfca.edu. > D0FH6+92IHpcStYKEYqH+A5yxo30Eb4mAuE6TKaA9CD2rGgsiP384UYx > Qp3xDwKQO0W3+G2w//FC5sEMZPYq6wYTrK3W/AnPUJHtVEVCDxbS5Gql > 910D2Px1G4QyZSbFnP/bvCGmr8ulALTPqa0IOvKXuzY2i7V/bieYZK9k 9ps= > usfca.edu. 3372 IN RRSIG A 8 2 3600 > 20251103131709 20251030131458 25299 usfca.edu. > ktVLOFl6EsRcCQPWtK4ApmnPr5/ETEfyiaXFQMFMgQ45kWuLjhUIBTUo > u8cV3/Z/jPa30kJKaldLi1vFrJJsvEpzrjw0n8ruuewYpfzokJVyg4k8 > 4vyAiHkrzR1QMY8UXBTa5edG29p0CHqrx8Y+dMZHopwXve0NgzAWpNa3 vLI= > > ; <<>> DiG 9.18.28 <<>> @localhost usfca.edu > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4655 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ; COOKIE: 0ef1927ba6bb40c1010000006903e1e311aceb0f7252d3d6 (good) > ;; QUESTION SECTION: > ;usfca.edu. IN A > > ;; ANSWER SECTION: > usfca.edu. 3545 IN A 23.185.0.2 > > ;; Query time: 0 msec > ;; SERVER: ::1#53(localhost) (UDP) > ;; WHEN: Thu Oct 30 15:08:35 PDT 2025 > ;; MSG SIZE rcvd: 82 > > > > On 10/30/2025 2:39 PM, Ondřej Surý wrote: >> No, you have not been caught by this. The issue you are referring to >> affects only a development >> version of BIND 9 (9.21), so whatever you are experiencing is not >> related to this. >> >> You need to provide evidence (logs, reproducer) about what is going >> on, so we can help you >> diagnose the issue you are experiencing. >> >> Ondrej >> -- >> Ondřej Surý (He/Him) >> [email protected] >> >> My working hours and your working hours may be different. Please do >> not feel obligated to reply outside your normal working hours. >> > -- Petr Menšík Senior Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.