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