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)
[email protected]
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 <[email protected]> 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.
>>> On 30. 10. 2025, at 18:21, Kelsey Cummings <[email protected]> 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
>>>
>>> --
>>> [email protected] 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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
