Query about new bind install and it's chatty log
Doug Freed
dwfreed at isc.org
Tue Mar 17 20:16:02 UTC 2026
On 3/17/26 14:52, Ted Mittelstaedt wrote:
> 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
Yep, this indicates your external queries are definitely getting
intercepted. There's a few tells visible. First is the presence of the
RA flag and absence of the AA flag (Recursion Available and
Authoritative Answer, respectively). The second is the absence of any
NSID value. All the F root nodes have a distinct NSID value that
indicates which node you're reaching. Also the TTLs don't match what's
in the root zone.
This may be Comcast's "SecurityEdge" "feature" which can only be
disabled from their website, not the modem configuration. You might try
checking that.
-Doug
More information about the bind-users
mailing list