Created attachment 2059517 [details]
Bind9 configuration file

I am not able to give you any tips for this behaviour. I have seen strange behaviour on single address family networks. Adding -4 or -6 option to named startup parameters helps often in that case.

I suspect it resolves it by caching failing name servers eventually, stopping using them later. rndc dumpdb with some parameter should help you finding more.

Can you use:
rndc dumpdb -fail
or
rndc dumpdb -bad

then looking at contents of file /var/named/data/cache_dump.db, which servers are there and whether some of them may have suspicious cache flags in comments?
File path might be reconfigured by dump-file.

I think rndc flush affects also bad servers cache, but flushtree only cached resource records. Not remote server feature information cache.

Unless you share what you see for the servers, I doubt I can help you.

Additional problem might be using forwarder(s) stripping DNSSEC signatures while signing is enabled.

(In reply to Petr Menšík from comment #2)
> I am not able to give you any tips for this behaviour. I have seen strange
> behaviour on single address family networks. Adding -4 or -6 option to named
> startup parameters helps often in that case.
> 
> I suspect it resolves it by caching failing name servers eventually,
> stopping using them later. rndc dumpdb with some parameter should help you
> finding more.
> 
> Can you use:
> rndc dumpdb -fail
> or
> rndc dumpdb -bad

Neither of these commands turned up anything of interest, or indeed anything at all:

;
; Start view _default
;
;
; SERVFAIL cache
;
;
; Start view _bind
;
;
; SERVFAIL cache
;
; Dump complete

and

;
; Start view _default
;
;
; Bad cache
;
;
; Start view _bind
;
;
; Bad cache
;
; Dump complete

> Additional problem might be using forwarder(s) stripping DNSSEC signatures
> while signing is enabled.
It is not.

Meanwhile, I had a closer look at the server log (journalctl -l -b -u named.service) and found many occurrences of sequences like this one:

Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns1.zdns.google/A'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns4.zdns.google/A'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns2.zdns.google/A'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns3.zdns.google/A'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns4.zdns.google/AAAA'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns2.zdns.google/AAAA'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns1.zdns.google/AAAA'
Jan 26 18:34:43 sarkovy named[1544]: loop detected resolving 'ns3.zdns.google/AAAA'

These occur quite frequently. I tried to reproduce the error using the dig command, but had no success so far.

Over a time span of two days, there were quite a number of those events:

[root@sarkovy cups]# journalctl -l -b -u named.service | grep -Fe 'loop detected resolving' | grep -e 'ns[1234]\.zdns\.google' | wc -l
184

Almost all of them involved the google name servers, but there also were a few others:

[root@sarkovy cups]# journalctl -l -b -u named.service | grep -Fe 'loop detected resolving' | grep -ve 'ns[1234]\.zdns\.google'
Jan 26 22:22:52 sarkovy named[1544]: loop detected resolving 'ns5.pinterest.com/A'
Jan 26 22:22:52 sarkovy named[1544]: loop detected resolving 'ns6.pinterest.com/A'
Jan 26 22:22:52 sarkovy named[1544]: loop detected resolving 'ns6.pinterest.com/AAAA'
Jan 26 22:22:52 sarkovy named[1544]: loop detected resolving 'ns5.pinterest.com/AAAA'
Jan 27 17:12:44 sarkovy named[1544]: loop detected resolving 'ns4.apnic.net/A'
Jan 27 17:12:44 sarkovy named[1544]: loop detected resolving 'ns4.apnic.net/AAAA'

loop detected should mean that you are forwarding to (at least some) servers, which (in some cases) will forward back to your server. Creating then endless loop. That would be configuration issue on some servers used in the chain. Not necessary on your server.

Try enabling query logging on your server and try domain you have used. You should see there who queries back on you. Without knowing more about your forwarding configuration, it is hard to tell.

rndc querylog on

named-checkconf -px output might help, but without your server publicly reachable, probably not.

Created attachment 2074093 [details]
Bind9 configuration file

Created attachment 2074094 [details]
query log file

Created attachment 2074095 [details]
output of 'rndc checkconf -px'

(In reply to Petr Menšík from comment #4)
> Try enabling query logging on your server and try domain you have used. You
> should see there who queries back on you. Without knowing more about your
> forwarding configuration, it is hard to tell.
> 
> rndc querylog on
I have been logging queries for quite a while now - output attached. AFAICT there is nothing interesting there.

> named-checkconf -px output might help, but without your server publicly
> reachable, probably not.
It is of course reachable as sarkovy.krokinole.de. Output of 'named-checkconf -px' is attached. Again, I do not see anything of interest there.

Okay, no forwarders to create any loops. Some overrides to blackhole common zones, but nothing should make it failing.

Can you try command:
dig -4 @localhost +trace www.hpd.de.

Does it remain broken this way? I would guess it could be issue in handling just flushing domain info, like mentioned at upstream issue:

https://gitlab.isc.org/isc-projects/bind9/-/issues/3885

It seems like it could be the same problem you have. Because NS record addresses for hpd.de. might not be flushed when you flush just that domain.

This have been fixed in 9.18.33, which is already available in f41 updates, since update:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-3551f3ba1b

Can you please confirm that the problem is fixed or whether it remains?

If it remains, could you try rawhide branch rebuilds from COPR https://copr.fedorainfracloud.org/coprs/pemensik/bind/? That should contain the most recent bind package we have. I do not have yet normal testing update for f41.

FEDORA-2025-4922878d8c (bind-9.18.39-3.fc41.1 and bind-dyndb-ldap-11.10-34.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-4922878d8c

FEDORA-2025-4922878d8c has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-4922878d8c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-4922878d8c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2025-4922878d8c (bind-9.18.39-3.fc41.1 and bind-dyndb-ldap-11.10-34.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.