[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: lame servers resolving

Am Mo, den 28.06.2004 schrieb T. Nifty Hat Mitchell um 22:23:

Hi Tom!

> 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.

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

Your warning is correct and rereading my reply to Olga's question was in
the sense of your arguments a bit unresponsible. Of course lame server
notifications have their sense. So instead of directing a lame server
messages to /dev/null it is a good decision to log them to a separate
logfile. A possible setup to do so would be in the named.conf:

logging {
        channel lamers {
                file "/var/log/lamer.log" versions 4 size 1m;
                severity info;
                print-time yes;
                print-category yes;
                print-severity yes;
        category lame-servers {

Such a log can be quickly grepped for notifications caused by own


Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) on Athlon CPU kernel 2.6.6-1.435 
Serendipity 15:35:26 up 2 days, 17:22, load average: 0.59, 0.26, 0.18 

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]