Query about new bind install and it's chatty log

Tue Mar 17 19:39:10 UTC 2026

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