Query about new bind install and it's chatty log

[Dan Mahoney]

At first, I thought these were old nameservers, with perhaps an ancient root.hints file.  But not, 192.5.5.241 is definitely F (i.e. ISC).  I suspect a middleware box or firewalling issue here.

If you want to do a query like:

dig +nsid @192.5.5.241 . NS, I'd be curious to see the results.

-Dan

> On Mar 17, 2026, at 9:56 AM, Doug Freed <dwfreed at isc.org> wrote:
> 
> On 3/17/26 10:49, Ted Mittelstaedt wrote:
>> I replaced an older nameserver with an upgrade and now I'm getting my syslog filled with:
>> 2026-03-17T15:45:35.606648+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 198.97.190.53#53
>> 2026-03-17T15:45:35.607940+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 198.97.190.53#53
>> 2026-03-17T15:45:35.619575+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 192.5.5.241#53
>> 2026-03-17T15:45:35.623514+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 192.5.5.241#53
>> 2026-03-17T15:45:35.632650+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 192.112.36.4#53
>> 2026-03-17T15:45:35.637040+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 192.112.36.4#53
>> 2026-03-17T15:45:35.646140+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 193.0.14.129#53
>> 2026-03-17T15:45:35.650222+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 193.0.14.129#53
>> 2026-03-17T15:45:35.658509+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 192.203.230.10#53
>> 2026-03-17T15:45:35.666644+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 192.203.230.10#53
>> 2026-03-17T15:45:35.671146+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 199.7.83.42#53
>> 2026-03-17T15:45:35.681376+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 199.7.83.42#53
>> 2026-03-17T15:45:35.684777+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 192.58.128.30#53
>> 2026-03-17T15:45:35.696406+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 192.58.128.30#53
>> 2026-03-17T15:45:35.698457+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 170.247.170.2#53
>> 2026-03-17T15:45:35.709773+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 170.247.170.2#53
>> 2026-03-17T15:45:35.714916+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 202.12.27.33#53
>> 2026-03-17T15:45:35.722599+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 202.12.27.33#53
>> 2026-03-17T15:45:35.730643+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 198.41.0.4#53
>> 2026-03-17T15:45:35.735529+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 198.41.0.4#53
>> 2026-03-17T15:45:35.743723+00:00 clientmail named[109862]: lame server resolving 'ns3.dnsv2.net' (in '.'?): 199.7.91.13#53
>> 2026-03-17T15:45:35.748110+00:00 clientmail named[109862]: lame server resolving '.' (in '.'?): 199.7.91.13#53
>> Since the server appears to otherwise be working am I correct in assuming this is just automated attacks from lame losers who have nothing productive to do with their CPU cycles?
>> Is there a trick to shut up these pointless warnings spamming my log? What do others do?
>> Thanks!
>> Ted
> 
> The message indicates your server is receiving what's known as a "lame delegation", which is a delegation that does not progress resolution, in response to queries to the root nameservers.  These messages are usually uncommon, and generally indicate an error in the zones or configuration of the authoritative nameserver, but are useful in troubleshooting user complaints, so generally shouldn't be disabled.
> 
> However, getting them for the root nameservers, which we can assume are correct in almost all cases, suggests that something else is going on. I would get a packet capture of the queries this server is sending and their responses to inspect what the responses contain, which may provide clues about their real origin.
> 
> -Doug
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20260317/f637f96c/attachment-0001.htm>