Home |  DNS scripts |  Loghost HOWTO |  Syslog-ng FAQ |  The Art of System Administration 

Sep 14 19:22:32 PDT 2014
Your IP:

campin.net tent logo

Campin dot Net

DNS resources on the web

tinydns, BIND 8 and 9 statistic graphing

I developed a few perl scripts to graph queries/sec on the DNS servers at work. I query the stats via SNMP, with the agent in the nameservers running an external script to collect the stats. The querying host then inserts the data into an RRD data file for later dynamic graphing by a CGI script.

RRDtool and it's perl libraries make it all easy.

Want the scripts? Click here for more info.

Example DNS stat graphs

BIND slave server management scheme

I manage my slave servers with a couple scripts which keep the content on my slave servers the same as that on my master. What I mean is that every one of my slaves hosts all the zones that my master hosts, whether the zone is actually delegated to the slave or not.

This eliminates variance between the zones loaded on my slaves, while still allowing me to keep different directives in the "options" and other blocks of the BIND config file. I know which zones are loaded on each slave - the answer is "all of the zones". I can setup a zone once on my master server, run a single script, and have the zone added to my slaves. This saves a huge amount of time in the long run, if you add zones regularly.

The idea here is that the input to this script isn't any "options", "controls", "logging" or any other statements. What this script is written to work with is the "zone" blocks.

I have a named.conf like this (contents of blocks deleted for brevity):

 options {
         version "surely you must be joking";
 controls        {
 logging {
 zone "localhost" {
 zone "0.0.127.in-addr.arpa" {
 zone "." {
 include "subdir1/named.zones";
 include "subdir2/named.zones";
 include "subdir3/named.zones";

This way "subdir1/named.zones", "subdir2/named.zones", and "subdir3/named.zones" only contain "zone" blocks. This makes the job of the filter much easier. Now you can setup your slaves the exact same way, using the "include" directive to include a single named.zones file containing all the zones that you wish to slave.

Use this script to generate the named.zones file for the slaves. The script puts the backup zone files in a sub directory named "secondary" and changes the filename to match the domain name exactly (unless it contains a slash, in which case the slash is replaced with an underscore). This is a *very* basic script, but it shows you how powerful a simple script can be - saving lots of time and effort.

DISCLAIMER: This script wasn't written to be robust, to be able to transform any garbage you shove at into a gleaming named.conf file, or mow your lawn. This works on the input I give it from my nameservers. Your results may vary, use at your own risk, etc, etc. This is more to demonstrate an approach than to give you a general purpose solution.

Also, the wrapper script has no real error checking - it just reloads BIND after syncing the file. I have an extensive logging infrastructure that pages me right away if there's any errors in the logs, so I kept it out of the script. I'd recommend building in some error checking somewhere if you don't have any way of determining if the new config file loaded properly (HINT: named-checkconf from the BIND 9 distro).

Use a shell wrapper like this to use SSH public-key authentication and rsync to push the file out. Wrapping it this way requires you to enter your public-key passphrase only once, which is the best part of the script.

I don't have the time and the patience to explain SSH public-key authentication, so please don't ask me to. Buy the O'Reilly book on it, it was one of the best investments I've ever made. The wrapper script will probably need modifications for your system.

Fun with sequence space arithmetic

If you have a higher serial number on your slaves then on your master server, one way to fix it is to increment your master's serial number by the largest amount possible, then set it to the desired number. Instead of remembering the formula to do this, I've written a script to do the work for me.

Use this form to calculate the the serial that you need to load into the zone on your master. Once the slaves sync to the new serial, set the serial on the master to the lower number you wanted to set it to initially.

Admission of guilt: I haven't actually tested this yet, but I copied the formula from Cricket's book, so it should work.

Input the current serial number of your (master's) zone file

  Home |  DNS scripts |  Loghost HOWTO |  Syslog-ng FAQ |  The Art of System Administration