//#################################
logging{
channel simple_log {
severity info;
syslog local7;
print-time yes;
print-severity yes;
print-category yes;
};
channel null_log {
severity info;
null;
print-time yes;
print-severity yes;
print-category yes;
};
category config {
simple_log;
};
category network {
simple_log;
};
category notify {
simple_log;
};
category database {
simple_log;
};
category xfer-in {
simple_log;
};
category xfer-out {
simple_log;
};
category client {
null_log;
};
category default {
simple_log;
};
category security {
null_log;
};
category lame-servers
{
null_log;
};
category
edns-disabled {
null_log;
};
category dnssec { null_log; };
category
resolver { null_log; };
category
update-security { null_log; };
};
Okay you see 2 channels named simple and null and a few of "nulls" at the bottom?
Okay what I'm doing here is apply these categories ahead of time but directing the output to my null logging-channel, which is basically like a dev-null.
If for example, I start to deploy DNSSEC, I can quickly change the null_log to my simple_log, restart named via "rndc reload" and start gathering log data. After I 'm finish, I can leave or revert back to null_log. This is a simple approach for logging imho.
For client queries, I can toggle this feature via rndc and querylog. It's easy todo and DOES NOT NEED A RESTART/RELOAD of named.
Here's me toggling it on using the utility rndc
and when you disable it, your primary logfile and rndc status should show it being off. Take heed of the client queries in the tail of my syslog file.
I could have even directed the output of the client queries to yet another destination.
I hope the above examples, give you a insight into just how powerful DNS & ISCbind name-server, and when it comes to logging.
A few key-points to remember;
1: on client queries and logging, don't enable it forever, since you could easy consume your diskspace on the localhost or remote-syslog server if you run it on a very busy TLD or authoritative name-server for to long of a time
2: if you log alot of categories, your dns-server could see a higher CPU and IO impact
3: if you log via remote-syslog to an external logging source, keep the above 2 points and the network traffic (udp/tcp depending on how your logging )
4: rsyslog on linux can flake out with heavy log datagrams when using udp protocols
5: a better solution is a commerical logging host for heavy TLD or ISP dns-servers
Some of the name-servers that I'm currently working on, handles anywhere from 50-100k queries per minute or more. So that's a lot of client queries.
Logging on some of these servers, can easily become over 100-200megs per-day. I have one dedicate host for just one primary name-server & that use a 1.5tg external drive for logging against 400+ domains.
IO activity is always high on this machine for the obvious reasons :)
Ken Felix
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
^ ^
=( @ @ )=
o
/ \
No comments:
Post a Comment