Unix How-To: DNS Logging

By Sandra Henry-Stocker  Add a new comment

While it's generally preferable to let DNS servers to do their jobs quietly, you might sometimes want to turn on logging for troubleshooting or to view of kind of requests that are coming through the service routinely. To turn logging on, you just need to tweak the syntax in your configuration file and add some syntax that at first glimpse might seem fairly tricky.

Logging for DNS servers requires that you add a logging clause to your named.conf file. This can be mildly traumatic. There's so much syntax to choose from! But it may not be quite as difficult as you might expect.

Here's the basic syntax for the logging clause. Note that just about all of it is optional.

logging {
   [ channel channel_name {
     ( file path name
         [ versions ( number | unlimited ) ]
         [ size size_spec ]
       | syslog syslog_facility
       | stderr
       | null );
     [ severity (critical | error | warning | notice |
                 info | debug [ level ] | dynamic ); ]
     [ print-category yes | no; ]
     [ print-severity yes | no; ]
     [ print-time yes | no; ]
   }; ]
   [ category category_name {
     channel_name ; [ channel_name ; ... ]
   }; ]
   ...
};

Here's what some of the keywords mean:

  • channel -- the control channel you want to log
  • file -- where you want to store log data (if not via syslog), absolute path in quotes
  • versions -- number of file versions that should be kept
  • size -- size limit on log file
  • syslog -- if using syslog logging facility
  • stderr -- write to standard out
  • null -- write to /dev/null
  • severity -- defines logging levels
  • print-category -- whether category is written to log (default is no)
  • print-severity -- whether severity is written to log (default is no)
  • print-time -- whether time stamps are added to log (default is no)
  • category -- controls what categories are written to the log and can be any of these:
    • client = client requests,
    • config = confile file parsing)
    • database = internal DNS databases
    • delegation-only = queires returning NXDOMAIN following delegation-only zone or statement in a hint or stub zone declaration
    • dispatch = dispatch of incoming packets to server modules
    • dnssec = DNSSEC and TSIG protocol processing
    • general = the default (not matching other choices)
    • lame-servers = lame servers
    • network = network operations
    • notify = all NOTIFY operations
    • queries = all queries
    • resolver = name resolutions including recursive lookups
    • security = approvals and denials
    • unmatched = no matching clauses or unrecognized class value
    • update = all dynamic updates (DDNA)
    • update-security = approvals and denials of update requests
    • xfer-in = received sone transfers
    • xfer-out = sent zone transfers

Given the many choices, you can be fairly exacting about what you want to see. Comments can be inserted as shown in the example following "//" markers. In this example, we are defining what we want logged (queries) and where we want to log the information. We'll store up to three versions with a maximum size of 100 MB.

logging {
      channel query_logging {
         file "/var/log/named_query.log"
         versions 3 size 100M;
         print-time yes;                 // timestamp log entries
      };

      category queries {
          query_logging;
      };
};

The trick is then to edit your named.conf (/etc/named.conf) file, add your logging clause and restart (or send a HUP to) BIND (named). Then you can peruse the log data and get an idea what your name service is doing.

The log data collected will look something like this:

26-May-2010 11:44:26.564 XX+/10.10.10.123/boson.particles.org/AAAA/IN
26-May-2010 11:44:26.974 XX+/10.10.2.101/255.255.255.255.in-addr.arpa/PTR/IN
26-May-2010 11:44:27.116 XX+/10.10.7.173/fermion.particles.org/AAAA/IN

ITworld LIVE

Operating SystemsWhite Papers & Webcasts

White Paper

A Comparison of PowerVM and VMware vSphere (4.1 & 5.0) Virtualization Performance

This technical white paper presents benchmark results showing greater VM consolidation ratios than demonstrated in previous benchmarks and demonstrating the extent of the performance lead that PowerVM virtualization technologies deliver over x86-based add-on virtualization products.

White Paper

Consolidating Lotus Domino x86 Workloads on IBM Power Systems

Read the white paper to learn how moving up to Lotus Domino 8.5 and consolidating with IBM Power Servers can help you boost performance results and ROI.

White Paper

Task, workflow & issue management for teams. Try free!

Need a flexible system for managing team tasks, issue tracking, and automating and managing workflow processes? Comindware® Tracker helps you do it all.

Webcast On Demand

Best Practices in Monitoring VMware

The benefits of virtualization are unassailable: increased agility, scale, and cost savings to name a few. However, so too are the monitoring challenges posed by these environments-including complexities, lack of visibility and control, and inefficiency.

Sponsor: Nimsoft

White Paper

How Nimsoft Service Desk Speeds Deployment and Time to Value

For years, many support teams have been hamstrung by their traditional service desk platforms, which require complex, time-consuming coding for virtually every aspect of customization. This complexity makes it costly and difficult for support organizations to adapt-and places an increasingly substantial burden on the agility and efficiency of the business as a whole.

See more White Papers | Webcasts

Ask a question

Ask a Question