Tech Ads
Back to Article List
Originally published June 2005 [ Publisher Link ]
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 -- interoperability with BIND servers is not hampered because 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 servers 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 servers or master servers on which to synchronize data are specified. 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, should be copied 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 its 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.