From Debian Clusters

Domain Name Service (DNS) is responsible for resolving IP addresses to domain names and vice versa. On the Internet, it's used exactly for that. When you type a URL in a web browser, like www.debianclusters.com, your machine asks a nameserver for the IP address of the web server responsible for that URL. This is called forward DNS. Reverse DNS refers to the opposite process - finding a domain name from a URL.

A cluster uses DNS for the same purpose, but none of the domain names are available to the public Internet. If you've been following through these tutorials, you've seen that I've been using the internal network raptor.loc, though cluster.loc or debian.cluster or anything else that doesn't map to an external domain on the Internet would have worked just as well. DNS is then used to give the machines their host names and to simplify services that run over SSH. Some software, like MPICH, require both forward and reverse DNS to be set up.

BIND, the Berkeley Internet Name Domain, is one implementation of DNS, and it's commonly used in Linux. As of the time of this writing, Debian lenny is running version 9.4.1.

The step involved in setting up the DNS server (with BIND) are:

• Installing and Configuring BIND
• Creating Forward DNS Records
• Creating Reverse DNS Records
• Testing and Troubleshooting BIND

Master versus Slave Nameservers

There are primarily two types of nameservers: master nameservers and slave nameservers.

Depending on the number of nodes, most smaller clusters only need one nameserver running to serve DNS for the entire cluster. However, for larger setups (and for larger zones on the Internet), multiple nameservers need to be set up to handle traffic as well as provide fallbacks if the primary nameserver(s) fail. Having to update multiple nameservers with new information seems contrary to the idea of gathering all the domain information on one computer (rather than manually updating /etc/hosts files), and it is!

This is where the distinction of the nameservers comes into play. Master nameservers hold original information - they're the places where the zones are configured. Slave nameservers, at regularly scheduled times, ask the master nameservers for all of the DNS information (called a zone transfer) and then cache that information. They can also store the information in a temporary files in case the primary nameserver goes down. How long the slave holds this for, as well as how often it asks the master nameserver for information, is part of the configuration in the forward DNS and reverse DNS records.

Changes in the master nameserver are then propagated through the slave nameservers when the they query the master for new information. Slaves can tell if the information has been updated based on the serial numbers in the records. In addition to that, by default Bind9 (the version on Debian Lenny, as of the date of writing this) automatically notifies any slave nameservers of changes whenever bind on the master is restarted with changes.

When setting up only one nameserver for a cluster, that cluster is the "master" nameserver, though the naming distinction isn't very important when there's only one server.

References

• Berkeley Internet Name Domain (BIND)
• http://www.debian.org/doc/manuals/network-administrator/ch-bind.html
• Liu, Cricket, and Paul Albitz. DNS and BIND. 5th ed. Sebastopol, CA: O'Reilly Media, Inc., 2006.