Knowledge Base ISC Main Website Ask a Question/Contact ISC
BIND Logging - some basic recommendations
Author: Cathy Almond Reference Number: AA-01526 Views: 2098 Created: 2017-08-29 13:51 Last Updated: 2017-09-03 19:22 0 Rating/ Voters

BIND9 logging configuration is very flexible, and the default settings are designed to make sure that you are collecting all of the basic administrator information as well as 'doing the right thing' when there are problems and you are advised to run with a higher debug level.  But sometimes (especially with larger and high-performance servers), more granularity is needed.

Logging configuration is included in the Administrator Reference Manual (ARM)

For a more exhaustive list of BIND logging and how it works, please refer to the documentation.  The ARM is distributed within the BIND downloadable source code tarball, as well as available online.  For more information please see: An Overview of BIND 9 Documentation

Included in this article is a sample logging configuration.  BIND administrators will almost certainly want to tailor it to their own needs, but it basically 'groups' the interesting logging into functional areas (with a few exceptions as noted in the comments).

The main points to note are:

1.  It is worth considering carefully whether or not syslog is appropriate to your needs or if it might be more useful to have named logging to flat files for later parsing.  The example provided below uses syslog for the logging categories that emit most of the ordinary running notices.


2.  BIND's dynamic logging channel severity setting can be used to flexibly include (or not) log messages at higher debug/trace levels, matching the debug/trace level at which named is running.  By logging the same categories to two channels in parallel, you can have one channel continue to output only the normal messages, but have the normal and the debug messages together go to another destination in parallel.

Use the rndc utility to set named into debugging mode while it is running

The server can supply extensive debugging information when it is in debugging mode. If the named’s global debug level is greater than zero, then debugging mode will be active. The global debug level is set either by starting the named server with the -d flag followed by a positive integer, or by running rndc trace. The global debug level can be set to zero, and debugging mode turned off, by running rndc notrace. All debugging messages in the server have a debug level, and higher debug levels give more detailed output.

For more information on debug/trace levels, see the Administrator Reference Manual (ARM).

Caution: Running named in debug mode can affect performance due to the overhead of providing and logging more information about named's processing steps.


3.  We recommend that you have the following additional options set - it makes parsing large volumes of output much easier, particularly when running named in debug mode:

print-time yes;
print-category yes;
print-severity yes;


4.  The sample configuration in this article (provided below) includes categories based on those available in BIND 9.11; administrators using older version of BIND may need to comment some out (e.g. dnstap).  Similarly administrators using newer versions of BIND may find that they have more logging categories available than have been included in this article!

Sample Logging Configuration

The sample logging configuration below is heavily commented in order to explain why the settings are thus - this should give you enough guidance for copying it and then adjusting it to your own needs:

logging {
        channel default_log {
                file "/var/named/log/default" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel auth_servers_log {
                file "/var/named/log/auth_servers" versions 100 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel dnssec_log {
                file "/var/named/log/dnssec" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel zone_transfers_log {
                file "/var/named/log/zone_transfers" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel ddns_log {
                file "/var/named/log/ddns" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel client_security_log {
                file "/var/named/log/client_security" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel rate_limiting_log {
                file "/var/named/log/rate_limiting" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel rpz_log {
                file "/var/named/log/rpz" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
        channel dnstap_log {
                file "/var/named/log/dnstap" versions 3 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
//
// If you have the category ‘queries’ defined, and you don’t want query logging
// by default, make sure you add option ‘querylog no;’ - then you can toggle
// query logging on (and off again) using command ‘rndc querylog’
//
        channel queries_log {
                file "/var/named/log/queries" versions 600 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity info;
        };
//
// This channel is dynamic so that when the debug level is increased using
// rndc while the server is running, extra information will be logged about
// failing queries.  Other debug information for other categories will be
// sent to the channel default_debug (which is also dynamic), but without
// affecting the regular logging.
//
        channel query-errors_log {
                file "/var/named/log/query-errors" versions 5 size 20m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity dynamic;
        };
//
// This is the default syslog channel, defined here for clarity.  You don’t
// have to use it if you prefer to log to your own channels.
// It sends to syslog’s daemon facility, and sends only logged messages
// of priority info and higher.
// (The options to print time, category and severity are non-default.)
//
        channel default_syslog {
                print-time yes;
                print-category yes;
                print-severity yes;
                syslog daemon;
                severity info;
        };
//
// This is the default debug output channel, defined here for clarity.  You
// might want to redefine the output destination if it doesn’t fit with your
// local system administration plans for logging.  It is also a special
// channel that only produces output if the debug level is non-zero.
//
        channel default_debug {
                print-time yes;
                print-category yes;
                print-severity yes;
                file "named.run";
                severity dynamic;
        };
//
// Log routine stuff to syslog and default log:
//
        category default { default_syslog; default_debug; default_log; };
        category config { default_syslog; default_debug; default_log; };
        category dispatch { default_syslog; default_debug; default_log; };
        category network { default_syslog; default_debug; default_log; };
        category general { default_syslog; default_debug; default_log; };
//
// Log messages relating to what we got back from authoritative servers during
// recursion (if lame-servers and edns-disabled are obscuring other messages
// they can be sent to their own channel or to null).  Sometimes these log
// messages will be useful to research why some domains don’t resolve or
// don’t resolve reliably
//
        category resolver { auth_servers_log; default_debug; };
        category cname { auth_servers_log; default_debug; };
        category delegation-only { auth_servers_log; default_debug; };
        category lame-servers { auth_servers_log; default_debug; };
        category edns-disabled { auth_servers_log; default_debug; };
//
// Log problems with DNSSEC:
//
        category dnssec { dnssec_log; default_debug; };
//
// Log together all messages relating to authoritative zone propagation
//
        category notify { zone_transfers_log; default_debug; };
        category xfer-in { zone_transfers_log; default_debug; };
        category xfer-out { zone_transfers_log; default_debug; };
//
// Log together all messages relating to dynamic updates to DNS zone data:
//
        category update{ ddns_log; default_debug; };
        category update-security { ddns_log; default_debug; };
//
// Log together all messages relating to client access and security.
// (There is an additional category ‘unmatched’ that is by default sent to
// null but which can be added here if you want more than the one-line
// summary that is logged for failures to match a view).
//
        category client{ client_security_log; default_debug; };
        category security { client_security_log; default_debug; };
//
// Log together all messages that are likely to be related to rate-limiting.
// This includes RRL (Response Rate Limiting) - usually deployed on authoritative
// servers and fetches-per-server|zone.  Note that it does not include
// logging of changes for clients-per-query (which are logged in category
// resolver).  Also note that there may on occasions be other log messages
// emitted by the database category that don’t relate to rate-limiting
// behaviour by named.
//
        category rate-limit { rate_limiting_log; default_debug; };
        category spill { rate_limiting_log; default_debug; };
        category database { rate_limiting_log; default_debug; };
//
// Log DNS-RPZ (Response Policy Zone) messages (if you are not using DNS-RPZ
// then you may want to comment out this category and associated channel)
//
        category rpz { rpz_log; default_debug; };
//
// Log messages relating to the "dnstap" DNS traffic capture system  (if you
// are not using dnstap, then you may want to comment out this category and
// associated channel).
//
        category dnstap { dnstap_log; default_debug; };
//
// If you have the category ‘queries’ defined, and you don’t want query logging
// by default, make sure you add option ‘querylog no;’ - then you can toggle
// query logging on (and off again) using command ‘rndc querylog’
//
        category queries { queries_log; };
//
// This logging category will only emit messages at debug levels of 1 or
// higher - it can be useful to troubleshoot problems where queries are
// resulting in a SERVFAIL response.
//
        category query-errors {query-errors_log; };

};



© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Quick Jump Menu