Unsupported DNSSEC algorithms should not lead to SERVFAIL.

Fri Oct 31 01:40:27 UTC 2025

Hi,

I see this in my 9.18 logs (named with -d3) on first attempt with cold cache:

31-Oct-2025 02:28:54.997 exceeded max queries resolving 'usfca.edu/A' (max-recursion-queries, querycount=53, maxqueries=50)

because of the various indirections between the nameservers.

But the query actually succeeds on second try just fine.

Same happens with delv:

$ ./bin/delv/delv -p 12345 @::1 usfca.edu.
; fully validated
usfca.edu.              3600    IN      A       23.185.0.2
usfca.edu.              3600    IN      RRSIG   A 5 2 3600 20251103131709 20251030131458 43212 usfca.edu. D0FH6+92IHpcStYKEYqH+A5yxo30Eb4mAuE6TKaA9CD2rGgsiP384UYx Qp3xDwKQO0W3+G2w//FC5sEMZPYq6wYTrK3W/AnPUJHtVEVCDxbS5Gql 910D2Px1G4QyZSbFnP/bvCGmr8ulALTPqa0IOvKXuzY2i7V/bieYZK9k 9ps=
usfca.edu.              3600    IN      RRSIG   A 8 2 3600 20251103131709 20251030131458 25299 usfca.edu. ktVLOFl6EsRcCQPWtK4ApmnPr5/ETEfyiaXFQMFMgQ45kWuLjhUIBTUo u8cV3/Z/jPa30kJKaldLi1vFrJJsvEpzrjw0n8ruuewYpfzokJVyg4k8 4vyAiHkrzR1QMY8UXBTa5edG29p0CHqrx8Y+dMZHopwXve0NgzAWpNa3 vLI=

If I run named with

options { max-recursion-queries 100; };

it actually succeeds on the first try.

If that doesn't help, perhaps we need more information about your system?

Operating System version, OpenSSL version, etc...  e.g. output of named -V

Ondrej
--
Ondřej Surý (He/Him)
ondrej at isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

> On 30. 10. 2025, at 23:13, Kelsey Cummings <kgc at corp.sonic.net> 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)
>> ondrej at isc.org
>> My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.
>>> On 30. 10. 2025, at 18:21, Kelsey Cummings <kgc at corp.sonic.net> wrote:
>>> 
>>> We think that we got caught by this change as part of our roll out to 9.18.41.  The basic gist is, that in a service provider context, our job is to do our best to resolve DNS as quickly and as well as possible for our customers.  If google and cloudflare resolve the domains and we can't, the customer does not care in the slightest why, only that they're not able to get to their work, school or other public resource. This just results in them migrating away from our recursive clusters to these public resources for good.
>>> 
>>> There certainly may be context where the new behavior is justified, but default or not, we need the ability to enable more relaxed behavior.
>>> 
>>> "be conservative in what you do, be liberal in what you accept from others"
>>> 
>>> https://gitlab.isc.org/isc-projects/bind9/-/issues/5570
>>> 
>>> -- 
>>> kelsey.cummings at sonic.com                 sonic.net, inc.
>>> System Architect                          2260 Apollo Way
>>> 707.522.1000                              Santa Rosa, CA
>>> 
>>> -- 
>>> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.