ISC BIND Server Logging

BIND defines logging categories which provide classification of loggable events for the server. This provides a convenient way to direct logging events for different event categories to different destinations. For example you may want to log critical events logged for the security category to the syslog daemon while warn events for the query category to a log file. The logging destinations and associated output formatting for each category are defined as logging channels within named.conf.

Logging Channels

Each logging channel is defined by the specifying the following.

  • output destination - one of the following:
  • file - an appended log file on the server
  • syslog - a protocol for sending log messages over an IP network
  • stderr - standard error - the operating system standard output stream for error messages
  • null - discard
  • severity - critical   error   warning   notice   info  debug [level] or dynamic - ordered highest to lowest; listed severity indicates that severity level and higher
  • flush output - the buffered parameter when set to "yes" will not flush the output to files after each log entry. The default is no, all log messages are flushed.
  • additional information to include with the event output (default is to not include any of the following):
  • include the logging category in the output or not (print-category)
  • include the severity in the output or not (print-severity)
  • include the timestamp in selected format within the output or not (print-time)

For output destinations of stderr or null no further parameters are needed; however for file or syslog output additional parameters may be defined:

  • for filespecify file parameters:
    • path_name of the file
    • the number of rollover versions to keep - as a file maxes out in size a copy is created with an integer suffix of the version number i.e., 1, 2, etc.
    • maximum size of each file specified in bytes with k, m, or g suffix for KB, MB and GB respectively
  • for syslogspecify the syslog facility ( the type of program that is logging the message - make sure the server OS supports the selected facility)
    • kern - kernel messages
    • user - user-level messages
    • mail - mail subsystem
    • daemon - system daemon
    • auth - security/authorization messages (deprecated in recent syslogd versions)
    • syslog - syslogd messages
    • lpr - line printer subsystem
    • news - USENET news subsystem
    • uucp - UUCP subsystem
    • cron - timed cron daemon
    • authpriv - security/authorization messages - private
    • ftp - file transfer protocol
    • local0   local1   local2   local3   local4   local5   local6   local7 - local facilities

Logging Categories

BIND defines several categories of events which can be logged. The logging statement enables association of selected BIND categories with one or more output destinations or channels with corresponding event severity to include in logging output. The syntax for defining logging falls within the logging statement block within the named.conf file. The logging statement encompasses definition of one or more logging channels and their respective associations with BIND logging categories.

logging {
[ channel channel_name {
( file path_name [versions ( number | unlimited )] [size size] |
syslog facility |
stderr |
null );
[ buffered (yes | no); ]
[ severity severity; ]
[ print-category (yes | no); ]
[ print-severity (yes | no); ]
[ print-time (yes | no | iso8601 | iso8601-utc | local); ]
}; ]
[ category category_name {
channel_name; [ channel_name; . . . ]
}; ]
};

where:

  • channel_name = a user defined name for the logging channel
  • path_name = file path
  • number = integer number of file versions
  • size = max log file size e.g. 100k 20m 5g etc.
  • facility = ( kern | user | mail | daemon | auth | syslog | lpr | news | uucp | cron | authpriv | ftp | local0 | … local7)
  • severity = (critical | error | warning | notice | info | debug [level] | dynamic )
  • category_name = one of the pre-defined BIND categories. Valid values include:
    • client - client/resolver events
    • cname - name servers skipped due to them being CNAME vs. A/AAAA.
    • config - configuration file processing events
    • database - events related to server databases for storing zone and cache data
    • default - defines the channel parameters for those categories for which no explicit channel parameters have been defined.
    • delegation-only - queries forced to NXDOMAIN due to a delegation-only zone or a delegation-only in a hint or stub zone declaration.
    • dispatch - server module hand-off events
    • dnssec - events related to DNSSEC and TSIG processing
    • dnstap - dnstap traffic capture
    • edns-disabled - queries that have been sent to other servers using EDNS but were resent without using EDNS due to timeouts awaiting a response from the EDNS query. This may indicate other DNS servers which are not responding due to packet loss or neglect in replying with an error code.
    • general - a category for those events that don't fall into other defined categories
    • lame-servers - events identifying a lame delegation where a delegated server is unable to resolve or further process a query
    • network - network related events
    • notify - events related to notify messages
    • queries - queries received by the server including the querierer's IP address and port number as well as query owner name class and type along with header information including the RD (recursion desired) flag setting use of EDNS and if the query was signed.
    • query-errors - used for debugging queries that resulted in some form of failure e.g., SERVFAIL; provides named source code file and line number which prompted the error condition
    • rate-limit - the start, periodic, and final notices of the rate limiting of a stream of responses are logged at info severity in the rate-limit category.
    • resolver - events related to resolution activities on behalf of resolvers e.g., iterative lookups performed
    • rpz - events related to response policy zones include errors in zone files and response rewrites
    • security - events related to approval and denial of requests
    • spill - queries dropped or responded to with SERVFAIL due to a fetchlimit quote being exceeded
    • trust-anchor-telemetry - trust anchor telemetry queries received
    • unmatched - events triggered by the inability of the server to identify the view or corresponding class for which a given query applies
    • update - events related to dynamic update transactions
    • update-security - dynamic update request events e.g. approvals and denials
    • xfer-in - incoming zone transfer events
    • xfer-out - outgoing zone transfer events

Bringing this together by way of example defining the logging structure mentioned earlier we define this logging statement to log critical events logged for the security category to the syslog daemon and warn events for the query category to a log file:

logging {
channel syslog-critical {
syslog daemon;
severity critical;
print-category yes;
print-severity yes;
print-time yes;
};
channel file-warn {
file "/etc/dnslog.log" versions 3 size 500m;
severity warn;
print-category yes;
print-severity no;
print-time yes;
};
category security { syslog-critical; };
category query { file-warn; };
};