Thanks!
With Comcast Business they don't give you a website to disable that
stuff, you only get that if you use Comcast Xfinity. You have to call
in to them for the Business stuff and you can only get static IP's on a
business plan. I actually have a /28. It's very time-consuming to call
in and work up the chain. But, I have to change the IPv6 PTR record for
that nameserver so I'll have to call them regardless, and I'll ask about
turning off that "feature"
The one saving grace of using them is at least they DO support actual
real IPv6 and DHCP-PD. Spectrum does not and many other SOHO ISP's
don't, either. There are, of course, a bunch of caveats on their IPv6
support that you have to work around.
Ted
On 3/17/2026 1:16 PM, Doug Freed wrote:
On 3/17/26 14:52, Ted Mittelstaedt wrote:
Dig results:
root@clientmail:/etc/bind#
root@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@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@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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
