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 {
lamers;
};
};
Such a log can be quickly grepped for notifications caused by own
errors.
Alexander
--
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
