Re: Query about new bind install and it's chatty log
Ted Mittelstaedt <[email protected]> Tue, 17 Mar 2026 12:52:19 -0700
| Newsgroups | gmane.network.dns.bind9.user |
|---|---|
| Message-ID | <c72e97f1-e5c6-4f89-bc98-19a636045ce2__15967.6675962814$1773777160$gmane$org@ipinc.net> |
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 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.