A nameserver is a server that resolves hostnames to IP addresses. Instead of having to type in "209.81.10.250", I can just type in "www.penguincomputing.com" to get to a site. BIND is nameserver software that runs on many types of machines, originally written by Paul Vixie and now maintained by the Internet Software Consortium (ISC).
This was one of the trickiest things I've had to try to figure out so far. I didn't talk to anybody as to how to go about this, unlike PPP setup. But I finally found the Linux DNS HOWTO and used that. Hopefully this will save you some trouble. Here I have instructions for BIND 8, which is newer and more advanced than BIND 4 (which some distributions still use).
In the event that your distribution already comes with BIND 8, then all you need to do is find out how the configuration works, and/or put in entries for machines that the Linux box will be the nameserver for. I think Slackware comes with BIND 8. I don't know about Debian. Most new distributions (including Red Hat 5.2) will already have BIND 8 so you'll probably have to look for the configuration file and how it has been pre-configured.
I had to remove the old nameserver first, so it wouldn't get in the way of the new one. It's fine to remove it and replace it with a new one; there aren't any other packages that really depend on it.
Using Red Hat 5.1, I typed rpm -e bind bind-utils caching-nameserver. That removed all the old packages. Be careful about this, especially about bind-utils, because bind-utils contains the tools such as dnsquery and nslookup that you might be using fairly often. Red Hat 5.2 already has BIND 8.
First, download BIND from ftp.isc.org. If you've got it on your system already, then you don't need to get BIND 8 unless you want to make a minor upgrade. The filename is something like bind-8.1.2-src.tar.gz, which says that it's BIND version 8.1.2 in source format (which you have to compile on your system). I'll work with the source version since that's what I usually do anyway.
After you have it on your system, type tar -zxvf bind-8.1.2.tar.gz. It will extract a directory called src/ and that's where you go into. Simply type "make" and have it compiled for you. If you need anything to be tweaked then read the INSTALL file (less INSTALL) and find what you need. After it finishes compiling, type make install.
Configuring the nameserver was probably the hardest part of the process that I had to go through. Hopefully, what I've written up about what I learned will save the reader some trouble.
The main BIND 8 configuration file is in /etc/named.conf. The configuration syntax for the file is documented at http://www.isc.org/bind8/config.html. Here's a sample of a configuration file (as /etc/named.conf), with an explanation below.
/*
* A simple BIND 8 configuration
*/
options {
directory "/var/named";
};
zone "penguincomputing.com" in {
type master;
file "master/penguincomputing.com";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "zone/127.0.0";
};
zone "." in {
type hint;
file "named.cache";
};
In "options" I only had one option: where the directory for zone files were. Zone files are where information about domains is stored, and each file has information about a zone. It's a section to cover, I guess, so that's why they're called zones. I have /var/named/ as my named data directory.
The "penguincomputing.com" section is pretty straightforward. It just indicates the location of the penguincomputing.com zone files and tells named that this server is a master nameserver for the penguincomputing.com zone.
The "0.0.127.in-addr.arpa" zone is for mapping localhost to 127.0.0.1, basically. It has its own zone file.
The "." zone indicates a caching nameserver; that is, someone can actually use your machine to resolve hostnames (including you). I've heard that is is efficient especially when using PPP connections, but I don't know for sure. Read the "Caching Nameserver" section to read up on how to create one.
First you need to get a "named.cache" file. I'm not sure if you can name it anything else, but let's just use that filename. In /var/named/ (or wherever you put your nameserver's data files), type dig @a.root-servers.net > named.cache. This will ask for the addresses of the main DNS servers of the Internet and direct them to a file. I'm guessing that the purpose of this is to give your machine an idea of which machines on the Internet to ask about hosts.
Periodically, like once a month, update the named.cache file by running that command once in a while. You can use a cron job for that. If you don't know what I'm talking about here, don't worry about it. Just be sure to update it using dig once in a while, that's all you have to do.
You have /etc/named.conf point to wherever your named.cache file is under the "." zone.
In /var/named/, I created directories for every type of zone I had. The directories I have in there are: master, slave/, and zone. With the domain name system, there is a server for each domain that is the main server (the master). I suppose that the slave server is there in case the main (master) server is down. For each domain there should be at least 2 servers, one master and one slave. That's just the way it goes.
While interning at Penguin Computing I set up both the master and slave DNS servers. The master's information should go in the master directory. You should be able to figure out where the slave's information goes. The information they store is the same, but since one machine is the main one that keeps the information (master) and the other simply follows the master's information (slave), you need to stay organized and make sure you're configuring the right machine for its right place in the nameserver system.
Note that the slave nameserver for one domain can also be the master nameserver for another domain. There just can't be two masters for a single domain, though I think there can be several slaves.
To figure something like this out, I was looking hard for examples. And examples really help, so hopefully you won't be too confused by my examples. Hey, I try.
The information for each domain is put in a single file. This file contains valuable information for each domain, such as machines that are under that domain (like, for the penguincomputing.com domain, the nameservers would have the information for what IP address pasta.penguincomputing.com gets and the one that antarctica.penguincomputing.com gets). Here's an example of a domain's records:
@ IN SOA penguincomputing.com. root.penguincomputing.com. ( 1998082403 ; serial 4H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds NS pasta.penguincomputing.com. NS rice.penguincomputing.com. MX 10 penguincomputing.com. ; Primary Mail Exchanger localhost A 127.0.0.1 router A 140.174.204.2 penguincomputing.com. A 209.81.10.250 ns A 209.81.10.250 www A 209.81.10.250 ftp CNAME penguincomputing.com. mail CNAME penguincomputing.com. news CNAME penguincomputing.com. pasta CNAME penguincomputing.com. slashdot CNAME penguincomputing.com. rice CNAME antarctica.penguincomputing.com. antarctica A 209.81.10.252 antarctic CNAME antarctica.penguincomputing.com. www.antarctic CNAME antarctica.penguincomputing.com. www.antarctica CNAME antarctica.penguincomputing.com. zork A 209.81.10.253 tux A 209.81.10.146 xfce A 209.81.10.252 @ TXT "Penguin Computing" @ HINFO Linux 2.0.34
There's a pretty weird syntax to be used for these zone files. I never would have figured it out on my own had I not read the Linux DNS HOWTO document. Basically, it specifies information about all the machines in the domain, and it contains information about the domain itself, such as the type of machine the server is running on.
I'll start explaining what all the stuff does. In the first line, it's saying that this file specifies the zones for the penguincomputing.com domain, and to send anything about the domain to root@penguincomputing.com. Since the "@" character has special significance in these zone files, the username (root) and machine name (penguincomputing.com) have to be separated by a dot. I guess BIND just knows how to split it up. That's how you fill in stuff for your domain as well.
The line with the comment "serial" shows the serial number of that domain. The syntax is YYYYMMDDRR; that is, a four digit year, two digit month in numerical form, two digit day format, and a two digit revision number. In this example (1998082403), it shows that the zone file was last modified on August 24, 1998. It's the third revision for that day. When you're changing anything in the file, make sure to increase the revision number by one if the previous change was on the same day. If I were to change the IP of one of the hosts, I would make the last two numbers, currently 03, to 04.
The next few lines show times for certain functions such as refreshing, retrying, and expiring the information. I'm not absolutely sure, but my best guess is that H stands for hour, D stands for day, and W stands for week.
The "NS" line indicates all the nameservers for that particular domain, including the one this information is on. This information has to match what has been registered with InterNIC. For the hostnames of the nameservers, remember to add a dot at the end. If you don't, it will add the hostname to the current domain. For example, if you forgot the dot at the end of pasta.penguincomputing.com, you would end up with the nameserver being pasta.penguincomputing.com.penguincomputing.com, which is obviously not what it's supposed to be. Watch out for this.
The MX file is the Mail eXchange record, so that mail can get through to the domain. There should also be an entry in /etc/sendmail.cw to allow messages coming in from that domain (assuming you're using Sendmail, the default on many Linux systems, for mail transfer).
The next couple of lines point to the local loopback (127.0.0.1), which all Linux systems should have even if they aren't connected to a network. The "router" line points to the IP address of where the machine's Internet connection is. I'm not sure if it's really necessary but I was playing it safe back then and trying to copy the example from the DNS HOWTO as closely as possible.
The rest of the entries use either A (address) or CNAME (Canonical Name) to point hostnames to IP addresses. Note that hostnames can be mapped to other hostnames, or they can be mapped to IP addresses. Use A to map a name to an IP address, and CNAME to map a hostname to another hostname (which must be mapped to another IP address).
The file for mapping localhost is pretty simple. Not much explanation needed. Of course, if you want to copy and paste, be sure you make the proper changes.
@ IN SOA penguincomputing.com root.penguincomputing.com ( 1998072401 ; Serial number 3H ; Refresh 1H ; Retry 604800 ; Expire 86400) ; Minimum TTL NS pasta.penguincomputing.com. NS rice.penguincomputing.com. 1 PTR localhost.
This file looks similar to the zone file for the domains, but it provides the opposite function. It points IP addresses to hostnames (as opposed to vice versa), because many servers on the Internet do this thing called reverse lookup on the IP address of your hostname to make sure that you're not doing anything sneaky.
This is for the zone "209.81.10" specified in the sample configuration file. Note that my example is not complete, nor does it work in reality, because Penguin Computing doesn't own the whole block of "209.81.10.*". But this is how you'd fill in a file to resolve your IP addresses to hostnames if you owned the entire block of IP addresses.
@ IN SOA penguincomputing.com. root.penguincomputing.com. (
1998072002 ; Serial
4H ; Refresh
2H ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS pasta.penguincomputing.com.
NS rice.penguincomputing.com.
;
; Servers
;
250 PTR pasta.penguincomputing.com.
250 PTR penguincomputing.com.
250 PTR ftp.penguincomputing.com.
250 PTR www.penguincomputing.com.
250 PTR mail.penguincomputing.com.
251 PTR rice.penguincomputing.com.
;
; Workstations
;
252 PTR antarctica.penguincomputing.com.
252 PTR antarctic.penguincomputing.com.
If you were to fill in an actual zone file like this, it's necessary to fill in all the entries in your block of IP addresses, from 1 to 255. For something like that you may want to assign the task to anyone who looks bored.
So what should you do if you only own a domain but not the block of IP addresses that it's part of? Ask the people who are in charge of that block of IP addresses to map your IP addresses to their respective hostnames for you.
The following is a list of resources I referred to in order to help me set up a nameserver for myself and write this document.
Comments, questions, suggestions? Send them to joshuago at users dot sourceforge dot net.
Copyright © 1997-1998 Joshua Go (joshuago at users dot sourceforge dot net). All rights reserved. Permission to use, distribute, and copy this document is hereby granted. You may modify this document as long as credit to me is given.