Query about new bind install and it's chatty log

[Nick Tait]

On 18/03/2026 08:39, Ted Mittelstaedt wrote:
> But in all of the cases if I check the lookup with Google Public DNS 
> servers, there's no name - for example the PTR record above for 
> 141.98.9.58 does not exist - so, a lame server resolving is completely 
> normal.  What I think is going on is the Comcast forwarders are 
> responding with domain not found and BIND is trying a last ditch 
> effort of querying the roots after getting that failure back, and of 
> course, also failing.

Hi Ted.

Your theory sounds entirely plausible. Are you aware of the "forward" 
option 
(https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-forward)?:

    *Grammar: *|forward ( first | only );|

    *Blocks: *options, template, view, zone (forward, primary,
    secondary, static-stub, stub)

    *Tags: *query

    Allows or disallows fallback to recursion if forwarding has failed;
    it is always used in conjunction with the |forwarders|
    <https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-forwarders>
    statement.

    This option is only meaningful if the |forwarders|
    <https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-forwarders>
    list is not empty. A value of |first| is the default and causes the
    server to query the forwarders first; if that does not answer the
    question, the server then looks for the answer itself. If |only| is
    specified, the server only queries the forwarders.

i.e. If you wanted to stop BIND from making the 'last ditch effort', you 
could try setting the forward option to "only".

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260322/fa276dd8/attachment.htm>