DNS name serving through NSD

NSD is an authoritive name server, meaning that it does not implement complementary features to name serving such as recursion or round robin sequencing that are incorporated into BIND. This gives NSD a smaller footprint, which translates into a faster and less exploitable piece of software. According to the SANS Institute, BIND is among the top vulnerabilities present on Unix systems, something that cannot be overlooked given organizations’ reliance on name resolution services.

Since NSD is based on standards, sharing data between name servers — common in DNS master/slave architectures that do so for scalability — it can interoperate with BIND servers. NSD uses the standard TCP/UDP port 53 for serving requests and feeds of the same zone file format used by BIND.

Let’s analyze a basic NSD setup. Once you install NSD and create a system user named nsd to run it, you need to proceed with NSD’s configuration, which is controlled by two files, nsdc.conf and nsd.zones, both located under the default/etc/nsd directory. The first of these files contains basic configuration and executable parameters; keeping the default settings should be fine for vanilla installations. The second file requires you to include the zone files that NSD will serve — the same information you include in BIND’s named.conf file. The syntax used in nsd.zones differs slightly from that used in named.conf, however. Here is an example:

; Syntax for nsd.zones;zone <domain>    <zone-filename> <masters-notify IP Address(es)>
; Primary server for mx
zone mx                 primary/mx              notify  201.14.4.240
; Secondary server for ar
zone ar                 secondary/ar            masters 210.4.10.50
; Sample name server for your domain
zone yourdomain.com     yourdomain.com

The first lines in this example describe the configuration for serving two top-level country domains, one as a primary server and another as secondary server. Notice the inclusion of typical DNS configuration parameters such as a primary name server’s ability to notify slave servers — in this case located on the 201.14.14.240 address — and also how a hosted secondary name server can poll a master name server, which holds the authoritive data for a zone. The actual zone files used by NSD are specified by the second parameter in this configuration file, based on an absolute path to the default NSD installation directory/etc/nsd.

The last line will probably most resemble your environment: a dot-com domain with a single DNS server. In this particular case, no downstream slave or master servers on which to synchronize data are specified. You should copy the zone file for yourdomain.com, which contains the actual mapping data for the domain and should normally be located under the default/var/named BIND directory, to a file under NSD’s directory.

After specifying your data in nsd.zones and copying your existing zone files to NSD’s directory tree, you need to validate your syntax using the utility zone compiler zonec, which is included in NSD.

The final step is initiating NSD’s daemon to start serving your zones. The daemon is accessible through the nsdc command. Starting the daemon automatically re-validates your nsd.zones file — a feature which eases updates to your configuration files — and actually compiles the file into a binary format named nsd.db which NSD uses for serving purposes. Once this is done, your box should be ready to attend any incoming name resolution request it receives and respond via NSD.

Daniel Rubio is an independent technology consultant and avid blogger at Webforefront.com who specializes in Web-based technologies.