Retrying in spite of ECONNREFUSED might make sense when the server side runs some kind of loadleveling/roundrobin scheme presented under a single IP, and the subsequent tries might not reach the same unresponsive physical instance. I'd prefer that v9_18 behaviour.
When a query to the first nameserver in /etc/resolv.conf fails, /usr/local/bin/host terminates silently.
Only bind-tools of this version: package version is 9.18.3
Connecting the first NS in resolv.conf returns EHOSTUNREACH or EPERM (ECONNREFUSED does not create the problem).
no output from "host whatever"
The second nameserver from resolv.conf should be asked
Correct behaviour is present in 9.16.29, and also when invoking "host -T"
A combined nameserver for authoritative and recursive tasks, for intranet and public service, plus root-slave etc., may need six or more partially interconnected views. Dnstap is the perfect tool to debug and verify that all of it actually does what is intended. But for this to be successful, information about which view is currently acting, would be needed in each dnstap message.
The 'dnstap-identity' option should work within a view statement. (The documentation does not state that it does /not/ work, but it gets rejected by the software.) Then the admin could choose an appropriate name to their liking individually in each view.
https://lists.isc.org/pipermail/bind-users/2022-June/106295.html
https://lists.isc.org/pipermail/bind-users/2022-June/106296.html