twice as many RRs in 9.20?

[Peter 'PMc' Much]

On Wed, Dec 03, 2025 at 07:13:15PM -0500, Ben Scott wrote:
! On 12/3/25 11:04, Peter 'PMc' Much wrote:
! > ! are now seeing the additional work BIND puts in to compensate for
! > ! CVE-2025-40778.
! > 
! > Thank You, that looks ugly. But doesn't tell much.
! 
!   Briefly: BIND can no longer safely trust glue records for a domain it did
! not ask about, so it has to make more queries to learn the addresses of name
! servers.  For some of the ridiculously long referral chains out there, this
! can easily mean 10 or more new outgoing queries.

Thank You. In the meantime I found some substantial paper in the
gitrepo, and so far fail to see why this would be an engineering
issue (and not rather a lack of strict administration somewhere),
but never mind, I don't want to deep-dive into this for now.

! > And, actually there is an impact with this ( s/NXDOMAIN/SERVFAIL/ ):
! > 
! > # rndc flush temptest
! > # host -t NAPTR tel.t-online.de
! > Host tel.t-online.de not found: 3(NXDOMAIN)
! 
!   I see similar when I try "dig NAPTR tel.t-online.de. @127.0.0.1" against a
! freshly started "named", for both 9.20 and 9.18.
! 
!   My first few attempts (dig invocations) got SERVFAIL, but within three or
! so repeats, I get the answer.  Those symptoms usually means
! max-recursion-queries, combined with the cache filling with each successive
! query attempt.  BIND keeps the cached answers it gets, even if it SERVFAILs
! later, so repeating the query gets closer each time.

So this means, the concerning queries are to be run multiple times
until they work?

I fear that is not an option in this case. I had a kind of race
condition with a client, concerning the TTL. I did not fully
analyze it (the plan is that the client shouldn't even talk to the
internet, but I don't get around to craft a better solution), and
the practical approach that solved the issue was then this:
        max-cache-ttl 900;
I.e., throw the cache away before the client asks again, and then it
will always get a fresh TTL.

!   In my case, I could make it worse/better by disabling BIND's use of IPv6.

Okay, but here, no way! I *love* IPv6! (Actually it was named/BIND
that initially motivated me to implement it, because it was whining
that it can and would like to use it, years ago.)
In IPv6 I finally can run the site in the old campus fashion where every
coffee-maker was directly reachable. And I get proper rDNS delegation
to run the authoritative reverse zones on my own servers (which means,
E-Mail can work again). That is so much more fun!

So it seems I have two issues:
1. hardware (devices) that does not like to repeat queries
2. wetware (people) who do not like to repeat queries

For 1. it seems the appropriate solution is what I already did:
create a separate view and there level up the max-recursion-queries
until things work.

Case 2. is the phenomenon when e.g. we click on some link, and the
browser says <resolver failed, try again>. While this can be lived
with, it is annoying. And that concerns all machines with interactive
use.

>From what I've learned, it is not a good idea to just level up
max-recursion-queries, because then some evil-doers could abuse my
site for DDoS attacks - anybody hacking onto my servers' ssh (and
there are lots of idiots doing that) will trigger outgoing queries for
their (possibly faked) IPs. I think that was CVE-2020-8616.

So, what can be done?

I did try that patch (with doesn't seem to exist anymore) for about
14 days, and while it still brought up issue 1. (with default
max-recursion-queries), at least I didn't see cases of issue 2.
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/11205

Maybe that is an improvement?

!   As an aside: Now that you're on 9.20, a very useful technique is "delv"
! with the "+ns" option.  This creates a full nameserver instance inside the
! "delv" process, more-or-less the same way "named" would, and then runs the
! query using that nameserver.  This lets one examine what "named" would do,
! without the hassle of starting/flushing the daemon, reading the logs, etc.
! Set the debug level to see more.  "-d3" is usually a good start.  "-d99"
! will show you more than you ever wanted to know about how BIND works.

Thanks! Getting debug output without restarting the server sounds cool
indeed.

rgds,
PMc