lame servers resolving

[T. Nifty Hat Mitchell]

On Thu, Jun 24, 2004 at 05:20:07PM +0200, Alexander Dalloz wrote:
> Am Do, den 24.06.2004 schrieb olga at urbantimes.net um 16:56:
> 
> > Since I am on the topic of logs... Here's another question.
> > I am getting a lot of 'lame server resolving' messages in the
> > /var/log/messages.
> > 
> > Here's an example:
> > Jun 24 09:02:25 isis named[1340]: lame server resolving
> > '71.68.90.80.in-addr.arpa' (in '68.90.80.in-addr.arpa'?): 80.90.64.38#53
> > 

> You can safely ignore such lame server messages, or even suppress them
> with following entry in the logging section of named.conf:
> 
>         category lame-servers {
>                 null;
>         };
> 
> A "lame server" is one that should be authoritative for a zone,
> according to the NS records that delegate authority for that zone, but
> really isn't, perhaps because it hasn't been configured to load the zone
> or because it is a secondary master that has expired the zone.
> 

How do you filter lame-server messages so you can discover 
problems with your own domain and toss those that are out
of your control?

My practice when I had responsibility of a large name space was to not
filter any errors going into the logs.  When scanning the logs I would
often build filters on the fly and verify that none of the errors 
had their root cause in anything I had responsibility for.

On boxes that were a consumer of DNS data then filtering this error
might be ok.  i.e. a local caching name server (SOA for
localhost.localdomain and look up all the rest).  No filters on mail
relays and MX hosts that might hide a problem.

And yes, Alexander is correct.
  "> You can safely ignore such lame server messages, or even suppress them"
unless you are responsible for the net or name space.

-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.