Tag Archives: bind9

BIND9 tip – statistics

If you add zone-statistics yes; to your named.conf.options file (if you are using an options file that’s externally included in named.conf) and you’ll be able to spit out a pretty dizzying number of statistics about your server. run sudo rndc stats to have these statistics dumped to a file. The default location for this file on a fairly vanilla install of Ubuntu server 10.04 LTS is /var/cache/bind/named.stats

If you want to change the default location, be sure you edit the apparmor profile for bind or you will get permissions errors. I’m lazy, so I just keep the default.


Related:

One stop shop for all bind9 options and the contexts where they may be used.
http://www.zytrax.com/books/dns/ch7/statements.html

Reading the contents of a bind9 statistics file.
http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.hald001/debug9.htm

Troubleshooting BIND logging on vanilla install on Ubuntu 10.04 LTS

Bind is a bitch. The default installation configuration of it on Ubuntu 10.04 LTS server has some bugs that make it difficult for anyone with mediocre or less than intermediate Linux administration skills to troubleshoot configuration or run-time issues. The single biggest thing that makes it so hard is actually finding log information that you can act on. It shouldn’t be this way.

I’m not going to cover everything since there’s an enormous number of potential configuration problems that can cause your particular instance to have problems, but here are a few helpful things, that, once I found them, helped me solve my BIND issues.

NOTE: many of these commands will require you to be root or sudo as root.

1. LOGS, LOGS, LOGS.

If you can’t see what the problem is, you’ll never be able to solve it. Again, vanilla Ubuntu installation, try this:

tail -f /var/log/daemon.log | grep named

This will print all BIND daemon startup, shutdown, and major configuration fails to the screen as they happen. This is one of several BIND default logging options that can’t be changed. This is the best log for tracking major configuration errors that stop BIND from starting.

2. Apparmor (more LOGS, LOGS, LOGS)

I guess this bit of Ubuntu tech has been around a while, but you will find very little information on the web when searching for a reason your custom logs are not being written to. Either you must put your custom logs in /var/log/named or you have to edit the apparmor settings for BIND, specifying a path the “bind” account can read and write.

sudo vi /etc/apparmor.d/usr.sbin.named

Once you either put your custom logs in the right place or edit the “named” apparmor profile so the bind account can RW to them, do this to see the logs in real time.

tail -f -q /path/to/custom1.log /path/to/custom2.log

Here are some of the eleventy places I found some answers: