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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
