Query about new bind install and it's chatty log
Ted Mittelstaedt
tedm at ipinc.net
Tue Mar 17 19:52:19 UTC 2026
Dig results:
root at clientmail:/etc/bind#
root at clientmail:/etc/bind# dig +nsid @192.5.5.241 . NS
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> +nsid @192.5.5.241 . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35280
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518400 IN NS m.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS l.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 604403 IN A 198.41.0.4
a.root-servers.net. 604420 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 40068 IN A 170.247.170.2
b.root-servers.net. 63592 IN AAAA 2801:1b8:10::b
c.root-servers.net. 47675 IN A 192.33.4.12
c.root-servers.net. 53956 IN AAAA 2001:500:2::c
d.root-servers.net. 45943 IN A 199.7.91.13
d.root-servers.net. 41391 IN AAAA 2001:500:2d::d
e.root-servers.net. 42013 IN A 192.203.230.10
e.root-servers.net. 67321 IN AAAA 2001:500:a8::e
f.root-servers.net. 42013 IN A 192.5.5.241
f.root-servers.net. 45767 IN AAAA 2001:500:2f::f
g.root-servers.net. 38090 IN A 192.112.36.4
g.root-servers.net. 130580 IN AAAA 2001:500:12::d0d
h.root-servers.net. 51031 IN A 198.97.190.53
h.root-servers.net. 51833 IN AAAA 2001:500:1::53
i.root-servers.net. 604541 IN A 192.36.148.17
i.root-servers.net. 41880 IN AAAA 2001:7fe::53
j.root-servers.net. 38304 IN A 192.58.128.30
j.root-servers.net. 44868 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 41600 IN A 193.0.14.129
k.root-servers.net. 63782 IN AAAA 2001:7fd::1
l.root-servers.net. 46056 IN A 199.7.83.42
l.root-servers.net. 79390 IN AAAA 2001:500:9f::42
m.root-servers.net. 38156 IN A 202.12.27.33
m.root-servers.net. 43744 IN AAAA 2001:dc3::35
;; Query time: 16 msec
;; SERVER: 192.5.5.241#53(192.5.5.241) (UDP)
;; WHEN: Tue Mar 17 12:51:16 PDT 2026
;; MSG SIZE rcvd: 811
root at clientmail:/etc/bind# dig +nsid @localhost . NS
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> +nsid @localhost . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5273
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 128f680669e3bf5a0100000069b9b0b6f2074da78aba55da (good)
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 518347 IN NS h.root-servers.net.
. 518347 IN NS m.root-servers.net.
. 518347 IN NS b.root-servers.net.
. 518347 IN NS k.root-servers.net.
. 518347 IN NS g.root-servers.net.
. 518347 IN NS i.root-servers.net.
. 518347 IN NS f.root-servers.net.
. 518347 IN NS c.root-servers.net.
. 518347 IN NS d.root-servers.net.
. 518347 IN NS a.root-servers.net.
. 518347 IN NS j.root-servers.net.
. 518347 IN NS e.root-servers.net.
. 518347 IN NS l.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 37896 IN A 198.41.0.4
b.root-servers.net. 42391 IN A 170.247.170.2
c.root-servers.net. 40915 IN A 192.33.4.12
d.root-servers.net. 48375 IN A 199.7.91.13
e.root-servers.net. 43310 IN A 192.203.230.10
f.root-servers.net. 37912 IN A 192.5.5.241
g.root-servers.net. 38590 IN A 192.112.36.4
h.root-servers.net. 41933 IN A 198.97.190.53
i.root-servers.net. 38389 IN A 192.36.148.17
j.root-servers.net. 38863 IN A 192.58.128.30
k.root-servers.net. 38624 IN A 193.0.14.129
l.root-servers.net. 48087 IN A 199.7.83.42
m.root-servers.net. 38311 IN A 202.12.27.33
a.root-servers.net. 37999 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 45685 IN AAAA 2801:1b8:10::b
c.root-servers.net. 64767 IN AAAA 2001:500:2::c
d.root-servers.net. 44478 IN AAAA 2001:500:2d::d
e.root-servers.net. 71838 IN AAAA 2001:500:a8::e
f.root-servers.net. 65295 IN AAAA 2001:500:2f::f
g.root-servers.net. 139986 IN AAAA 2001:500:12::d0d
h.root-servers.net. 50146 IN AAAA 2001:500:1::53
i.root-servers.net. 38616 IN AAAA 2001:7fe::53
j.root-servers.net. 39910 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 42856 IN AAAA 2001:7fd::1
l.root-servers.net. 40328 IN AAAA 2001:500:9f::42
m.root-servers.net. 43726 IN AAAA 2001:dc3::35
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Tue Mar 17 12:51:18 PDT 2026
;; MSG SIZE rcvd: 851
root at clientmail:/etc/bind#
Ted
On 3/17/2026 12:39 PM, Ted Mittelstaedt wrote:
> 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
More information about the bind-users
mailing list