Keeping a secondary name server up to date with respect to the list of zones that it needs to slave can be a challenge. Our primary name server has over 500 zones that it handles, and changes are reasonably frequent, say weekly. We currently use cron jobs between all the name servers we deal with that uses a locked-down SSH public key to periodically get the list of zones that the slave servers need to pull, then we rely on AXFR to transfer them.

This system has worked fairly well over the years. Recently I was studying PowerDNS, and saw it's "supermaster" ability in which you tell it what DNS servers to trust and if it receives a NOTIFY message for a zone it doesn't already know about from this server, it will automatically configure itself to slave for this zone and then use AXFR to transfer it.

In other words, it uses the NOTIFY messages your servers are already sending out to configure itself as a slave. This should eliminate the primary issue we've had with the SSH replication, which has been in the infrequent cases where SSH host keys change on various servers, the replication stops until we manually fix it. Read on for more of my thoughts about this configuration.

Initial Setup

It was pretty easy to set up, though it wasn't documented particularly well. One particular thing that threw me for a few minutes was that the supermaster is configured not in the main pdns.conf file, but in the "backend" storage. And, of course the master servers need to be configured to allow XFER from and send NOTIFY to this new server. I used the "also-notify" and "allow-transfer" settings in our master BIND server to do this.

I decided to use the SQLite back-end because for this test it seemed like that would require the least mucking around -- since it's really just a file and I wouldn't have to deal with authentication issues of using a PostgreSQL database. Even though that's not hard, I just wanted to keep it simple at this point.

I didn't go through extensive testing at this point beyond verifying that it was transferring zones as I updated them on the master, and that it sucked down a ton of zones if I made the master send out notifies for all the zones.

Configuration

I was testing on an Ubuntu Hardy based system, so some options may be different if you're using CentOS or another server. However, here are my basic notes:

• apt-get install pdns-server pdns-backend-sqlite
• Save the following values to /etc/powerdns/pdns.d/pdns.local, of course replacing "ns2.example.com" with your name server name:

  default-soa-name=a.ns2.example.com
  slave=yes
  #webserver=yes
  launch=gsqlite
  gsqlite-database=/var/spool/powerdns/pdns.sqlite

• Run "sqlite /var/spool/powerdns/pdns.sqlite" and cut and paste the database schema from the PowerDNS web site into it.
• Also using the above "sqlite" command-line interface, insert a database entry for your supermaster server, replacing your master name server IP and name in the below:

  INSERT INTO supermasters ( ip, nameserver, account )
        VALUES ( '10.0.0.1', 'ns1.example.com', 'internal' );

• chown pdns:pdns /var/spool/powerdns/pdns.sqlite
• /etc/init.d/pdns restart
• tail -f /var/log/syslog

Monitoring

PowerDNS also includes a webserver (commented out of the pdns.local file above). If enabled, you can visit it via http://127.0.0.1:8081/, (I accessed it via SSH port forwarding, since I wasn't on the machine I was testing). This web server will tell you all sorts of stats about the PowerDNS server. There's also a command-line interface you can use to get access to similar stats from the command-line. There's also a set of Munin plugins for graphing stats, search google for "munin pdns". I haven't used the Munin plugins, but they looked reasonable enough.
(Post Reply)