Setting Up NSD3 for DNS
There are two major players in the Domain Name System server market: Bind and NSD. The former has been around since the 1980s and makes up a majority of the installations in use today, while the latter saw its first release around the turn of the century, and is designed to be purely authoritative (incapable of recursive DNS queries). While selecting a DNS server for Ambrose University College, NSD’s ability to easily run from a Chroot, and its lightweight footprint (currently using 69MB of RAM for the entire server), easily won our vote. Furthermore, NSD can make use of BIND’s zonefiles, and the migration from our old server was complete in a matter of minutes.
Securing your server
Before you even consider working on your DNS server, you’ll want to lock down your security. What good is a server if you can’t trust it? I’ve written up a separate post on Securing a Linux Server that should give you a head start.
NSD will start as soon as you install it, and complain if you don’t have a config file created already, so we’ll create a blank file for now.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Give yourself access to
By default, you won’t have access to
/etc/nsd3 without working as root, and running as root is bad form, so let’s add the nsd group to our account. We probably have some kernel updates that need to be applied, and we need to relogin for the group to apply, so this is the perfect time to reboot our server as well.
1 2 3 4 5 6
Configure NSD as a Master
You’ll find a sample configuration at
/etc/nsd3/nsd.conf.sample, and man nsd.conf is a great place to find more information. The config is quite simplistic though, and I was un and running in minutes.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
You may be asking yourself “But Spenser, how do I generate that key?”, and thankfully the answer is quite simple.
Configure NSD as a Slave
The slave configuration is nearly identical to the master, with the only change being the
provide-xfr lines changing to the slave-variant. Each zone is required to have a zonefile, but you don’t need to fill it out if it pulls from the master, so I just touched each file and left it empty.
1 2 3 4 5 6
NSD uses BIND zonefiles, and there is a plethora of documentation and guides on how to write one, so hit up your favourite search engine and you’ll be on your way. Don’t forget to update the SOA Serial whenever you make a change, otherwise the next step won’t work.
Applying your configuration changes
If you’ve modified your
nsd.conf, you’ll need to restart NSD.
Otherwise, changes to zonefiles require the zone database to be rebuilt and reloaded.
If you have any slaves configured, be sure to check your logs for errors. If you don’t set the server verbosity to 1 (incoming notifies/transfers) or 2 (soft warnings), and don’t receive an error, it is likely working.
Confirming your Master/Slave zones
Dig is a wonderful tool when testing DNS changes. Check the forward and reverse zones of each of your nameservers, and make sure the serial and information matches. Then update the serial on your master, rebuild/reload, and check the slave again.
1 2 3 4 5 6 7 8 9 10 11 12
Get a second opinion
There are quite a few automated tests that will check the responses from your nameservers, and ensure everything is in working order. I found that Pingdom, the Swedish Internet Infrastructure Foundation, and IntoDNS were extremely helpful.