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.
