Thanks, Doug,
I didn't connect the dots on this one, you are correct all these IP's
are IP's of the roots and the roots shouldn't be having problems with a
name ns3.dnsv2.net
I checked into this further and here's what I think is going on it's a
continuation of an old problem that cropped up several years ago.
I have several nameservers that are authoritative for a number of domain
names I have registered. These servers have public IPs but they are on
a Comcast copper cable business line with static IPs. I also use them as
nameservers for my network. For a decade this setup worked fine and
then one day I started getting intermittent name resolution from them
for random names on the Internet.
I finally "fixed" the problem by putting a forwarder in my nameserver to
the Comcast public nameservers. So, my nameservers still answer queries
from the Internet for my domains, and when they need to lookup other
names they go to the Comcast servers.
I'm pretty certain the problem lies in the mandatory required router
that Comcast supplies. While I have logged into it and turned it's
firewall off, and set it to firewall disabled - I don't actually think
that Comcast has truly disabled the firewall, I think they are tampering
with DNS traffic. I happen to have another nameserver on a Spectrum
cable business line in another location and there is not any requirement
to put a forwarders option in on that one. Spectrum also has a
mandatory router which of course I've disabled the firewall on.
In the normal case use of these mandatory router, the customer would be
using the Comcast DNS server IP's which are 75.75.75.75 but what I
actually think is going on is Comcast runs a caching nameserver on these
routers and they redirect DNS traffic to 75.75.75.75 to this caching
nameserver which saves the load on their actual nameservers.
I'm not big enough to afford a Comcast fiber connection where I would be
able to use my own router so I'm stuck with theirs.
Putting a forwarders line in the named.conf file did reduce some of the
log spamming. I'm still getting a lot of
2026-03-17T19:21:06.220060+00:00 clientmail named[129244]: lame server
resolving '58.9.98.141.in-addr.arpa' (in '141.in-addr.arpa'?): 193.0.9.5#53
2026-03-17T19:21:06.234900+00:00 clientmail named[129244]: lame server
resolving '58.9.98.141.in-addr.arpa' (in '141.in-addr.arpa'?):
202.12.31.53#53
2026-03-17T19:21:06.248119+00:00 clientmail named[129244]: lame server
resolving '58.9.98.141.in-addr.arpa' (in '141.in-addr.arpa'?):
200.3.13.14#53
2026-03-17T19:21:06.261894+00:00 clientmail named[129244]: lame server
resolving '58.9.98.141.in-addr.arpa' (in '141.in-addr.arpa'?):
204.61.216.100#53
2026-03-17T19:21:06.277821+00:00 clientmail named[129244]: lame server
resolving '58.9.98.141.in-addr.arpa' (in '141.in-addr.arpa'?):
199.253.249.53#53
2026-03-17T19:21:16.198379+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 198.97.190.53#53
2026-03-17T19:21:16.212720+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.33.4.12#53
2026-03-17T19:21:16.227084+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 193.0.14.129#53
2026-03-17T19:21:16.241057+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.36.148.17#53
2026-03-17T19:21:16.255491+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.5.5.241#53
2026-03-17T19:21:16.269020+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 199.7.91.13#53
2026-03-17T19:21:16.283791+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.203.230.10#53
2026-03-17T19:21:16.328930+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 202.12.27.33#53
2026-03-17T19:21:16.329012+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.112.36.4#53
2026-03-17T19:21:16.329107+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 199.7.83.42#53
2026-03-17T19:21:16.339054+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 170.247.170.2#53
2026-03-17T19:21:16.352491+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 192.58.128.30#53
2026-03-17T19:21:16.367700+00:00 clientmail named[129244]: lame server
resolving '.' (in '.'?): 198.41.0.4#53
2026-03-17T19:21:16.367878+00:00 clientmail named[129244]: resolver
priming query complete: failure
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.
Reverse lookups to IP addresses that actually have real PTR records
work, and all forward lookups even to the names that were failing
previously, are now working. Of course, they are merely being passed to
the Comcast DNS servers.
Obviously I would greatly prefer doing my own recursive queries from the
root nameservers instead of handing them off to Comcast, but I have no
access to sniff the network that's on the Cable side of the Comcast
router, and my guess is a packet capture on this side will reveal a
perfectly formed query and tell me nothing.
Ted
On 3/17/2026 9:56 AM, Doug Freed 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.
