On Thu, Jun 24, 2004 at 05:20:07PM +0200, Alexander Dalloz wrote:
> Am Do, den 24.06.2004 schrieb olga@xxxxxxxxxxxxxx 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.
