lame server resolving - repeats 280 times

Bill Larson bind9 at comcast.net
Tue Nov 23 22:14:05 UTC 2004


There really isn't much that you can do about this, unless you are 
managing the server for the domains that are being logged as "lame".  
This is just a fact of life when dealing with DNS.

Somebody is asking your server for DNS information and your server is 
contacting servers that are identified as "authoritative" for a zone 
but aren't.  This is the definition of a "lame server".

Now, there are a few things that you could do to help yourself out.

First, you could complain to the person responsible for the DNS 
services for the zones that are identified as lame.  You can get this 
information by running "dig ZONE SOA" to get the SOA record for the 
zone.  Now, at the moment, it appears to me that the root servers for 
the ".us" TLD are broken, so this may be part of your problem and there 
really isn't anything that you can do about this.

Second, you could simply ignore these "lame server" messages.  This is 
what is commonly done.  You can even define a logging category for lame 
servers and send this information to /dev/null.  This would use the 
category "lameservers" and could have a configuration similar to:

	category "lameservers" { "null"; };

The problem is that this would cause you to loose any of this lame 
server information, which may be important.

Third, you are getting hammered by somebody.  850 queries/sec, your 
440000 queries per 15 minutes, is a lot, although your server should 
easily be able to handle it.  I'd spend some time trying to find out 
who is doing this and why.  I would suspect that this may be somebody's 
web server that is trying to log the name for every connection being 
made to it.  Your log is indicating that there are 379 times is under 
two seconds.  I'd have a hard time believing that there are that many 
people trying to get to the same site at the same time, although I 
could be easily wrong.  Notice also the IP addresses that these queries 
are coming from, 4.2.49.2, and 4.2.49.4.  Both of these IP addresses 
are servers for gtei.net.

Now, to get back to the first point.  It appears that there is a 
definite problem with the "tower-hill.pvt.k12.de.us" zone.  By tracking 
down this zone using DNS, the last functioning delegation appears to be 
from the "i2.state.de.us" server, and it reports that this zone is 
supposed to be served by "knock.ser.bbnplanet.net" and 
"chela.tower-hill.pvt.k12.de.us".  The BBNPlanet server doesn't provide 
any information for this zone and there is no IP address for the 
"tower-hill" server.  So, things are really broken and there really is 
nothing that you can do about it.

If your server is only a DNS server, not running Apache, SMTP, or other 
service, you shouldn't be getting pegged at 90% CPU.  The only thing 
that you can do is to try and limit your workload.  This can be done by 
trying to simplify your client base.  If you have legitimate clients 
using your server, talk nicely to the administrator and have them shut 
down any additional DNS queries that aren't really necessary.  (Web 
logging can record just IP addresses and then the log files can be 
post-processed to identify heavy users and then the IP addresses of the 
heavy users can be looked up - but only once.  Or, they can operate 
their own DNS services, which would actually be an advantage to them 
because they wouldn't have to be talking on the network all of the time 
to your servers to get DNS information, especially with repetitive 
queries.)

Finally, since you do say that this is a caching server, you appear to 
be responding recursively to queries outside of your network.  You 
should configure your server to provide recursive DNS services to only 
your legitimate clients, not the world.  Let the world provide their 
own DNS servers and not load down your system.

These "lame server" query logs indicate that these queries are coming 
from:

	200.72.1.253
	200.72.1.254
	211.134.181.104
	211.134.181.105
	212.100.224.247
	212.187.158.3
	216.49.80.74
	4.2.49.2
	4.2.49.4
	66.199.248.202
	66.199.248.203

This is a large set of networks that you seem to be responding to.  
This doesn't sound like you are trying to limit your queries at all.  I 
would suspect that someone has discovered that you are providing DNS 
services to anyone that asks and they are taking advantage of this.

Anyway, hope this helps you out some.

Bill Larson

On Nov 23, 2004, at 10:05 AM, Duane J. Von Lanken wrote:

> I am running HPUX 11.11 with Bind 9.2.0, this server is set up as a
> caching only server and has approx 440,000 queries per 15 minutes.  I
> recently started getting about 110,000 failed queries per 15 minutes.
> Usually they run on average about 10-12,000 per 15 minutes.  The CPU
> has been spiking up to +90%, when it usually runs about 40-50%.  I am
> getting in the log (lame server resolving
> 'chela.tower-hill.pvt.k12.de.us''  MASSIVE amount of times.  How can I
> correct this?
> THANKS!
>
>
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:38 ns1  above message repeats 85 times
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'vscan.mocaasap.com' (in 'mocaasap.com'?): 216.49.80.74#53
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'www.todoporaventura.com' (in 'todoporaventura.com'?):
> 66.199.248.202#53
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.4#53
> Nov 23 10:53:38 ns1  above message repeats 280 times
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'www.todoporaventura.com' (in 'todoporaventura.com'?):
> 66.199.248.203#53
> Nov 23 10:53:38 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.4#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> '104.210.72.200.in-addr.arpa' (in '210.72.200.in-addr.arpa'?):
> 200.72.1.254#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'tvmedia.co.jp' (in 'tvmedia.co.jp'?): 211.134.181.104#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving 'pow.com' (in
> 'pow.com'?): 212.187.158.3#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'tvmedia.co.jp' (in 'tvmedia.co.jp'?): 211.134.181.105#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> '104.210.72.200.in-addr.arpa' (in '210.72.200.in-addr.arpa'?):
> 200.72.1.253#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving 'pow.com' (in
> 'pow.com'?): 212.100.224.247#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.4#53
> Nov 23 10:53:39 ns1  above message repeats 3 times
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.4#53
> Nov 23 10:53:39 ns1 named[18839]: lame server resolving
> 'chela.tower-hill.pvt.k12.de.us' (in 'tower-hill.pvt.k12.de.us'?):
> 4.2.49.2#53
>
>



More information about the bind-users mailing list