Special Offers

Feature: Networking

DNS name serving through NSD

Given the sheer importance of name servers in providing Domain Name System (DNS) resolution -- a process used by every Web-facing application to translate domain names into IP addresses and vice versa -- not many people put much thought into the available software alternatives for pulling off this feat. One compelling application is NSD, an alternative to the widely deployed BIND name server.

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<nobr> <wbr></nobr>/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:

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<nobr> <wbr></nobr>/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<nobr> <wbr></nobr>/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.

Re:NSD vs. tinydns

Good Article

Posted by: Anonymous Coward
on July 04, 2005 10:58 PM

Good article, I didnt know there were so much alternatives. However I have heard of djbdns ( <a href="http://cr.yp.to/djbdns.html" title="cr.yp.to">http://cr.yp.to/djbdns.html</a cr.yp.to> ) but I dont know if it's good or how it compare to BIND or NSD.

Re:Good Article

Posted by: Anonymous Coward
on July 05, 2005 10:37 PM

Actually, djbdns totally rocks. I know there are some folks who don't like it, either for political reasons or for filesystem layout reasons, but I've implemented it in the past. Once you grok the config file, you'll be happy if you never see another BIND config file again.

If you want to be politically (corporate) correct, you'll likely end up implementing BIND. But if you want something where you set it and forget it, check out djbdns.