DNS with BIND/named

by Marion Bates <mbates at whoopis.com>
with much help from William Stearns <wstearns at pobox.com>

" . $googleAdBlack; ?>

(Need to do secondary DNS? Check here.)

You know how to log in to your server, and how to do things as root (with sudo, or as root directly)
You know how to start and stop services (usually /etc/init.d/servicename restart)
You know how to configure a service to start up automatically after your server reboots (there are several ways to do it, e.g., run ntsysv or chkconfig, or cd /etc/rc.d/rc3.d/ and mv Kxxservicename to S(100-xx)servicename. In other words, to enable sendmail to start up on restart:
mv K30sendmail S70sendmail

NOTE: I have not yet tried running BIND on my own server, so the first part of this section is untested (but should work). I use the slartibartfast.pa.net server (hereafter known as "slart") to do DNS for me. But this info would still be applicable -- it is simply assumed that BIND is already installed and running.

To run your own DNS: Install the bind, bind-devel, bind-utils, and caching-nameserver packages; the latter includes a skeleton /etc/named.conf file, perfectly suited for adding your own primary or secondary dns stanzas. If your nameserver is secondary for a given domain, the actual db.goober.com file will come from the primary automatically and be stored in /var/named/. If you're primary, you have to create one in /var/named/.

Assuming BIND is installed and running, either on your own machine or another server: You should perform the following steps BEFORE you register your domain name, because some registrars will poll the DNS servers you specify before allowing you to claim the domain name. You will need root privileges for the next few steps. On the DNS server, edit /etc/named.conf. This is where you will specify the location of the db file for your new domain. You should add section like the following:

zone "goober.com" {
        type master;
        file "db.goober.com";
        //masters { 66.59.111.182; };
};

(or wherever you plan to keep the db file). The //masters line is commented out, but if you send this chunk of text to whoever's doing secondary for you, then all he/she has to do is uncomment that line and change "type master" to "type secondary."

Create /var/named/db.goober.com and edit it in your favorite text editor (mcedit is easy to use and doesn't mangle linebreaks, but vi and pico work too). Here is a template. Note that this assumes that you are using slart as the primary DNS server:

;
; Authoritative data for goober.com (ORIGIN assumed goober.com)
;

$ttl 38400
$ORIGIN com.
goober         IN      SOA     slartibartfast.pa.net. root.slartibartfast.pa.net. (
                2002100402      ; Serial
                10800           ; Refresh 3 hours
                3600            ; Retry 1 hour
                3600000         ; Expire 1000 hours
                7200            ; Minimum 2 hours
                )
goober.com.    IN      NS      slartibartfast.pa.net.
goober.com.    IN      NS      secondary-dns.not-slart.com.
goober.com.    IN      MX      5 mail.goober.com.

$ORIGIN goober.com.
localhost       IN      A       127.0.0.1
goober.com.   	IN      A       your.server.ip.address
mail            IN      A       your.server.ip.address
www             IN      A       your.server.ip.address
ftp             IN      A       your.server.ip.address

What these things mean:

The first three lines (preceded by semicolons) are comments. $ttl is the default time to live for objects that don't explicitly state how long they can be cached. $ORIGIN applies to objects in the left hand column; if those objects do _not_ end with a period, the value of $ORIGIN is appended, so for example the next line "goober <tab>..." is really interpreted as goober.com.

The next block of text designates slart as the SOA (Start Of Authority) for this domain, and specifies some time limits for how long the domain information is cached. The first number, "Serial", is key -- you will need to update this number BEFORE you restart named, otherwise the db file will not be read in. If you are making changes for the first time on a given day, the serial number ought to be of the format YYYYMMDD01. Year, month, today's date, and number 01. If you edit the file again on the same day, increment the number to 02, etc. If you edit the file the next day, reset the trailing number to 01 and increment the date appropriately.

The next block defines both primary and secondary nameservers for goober.com. The secondary nameserver ideally ought to be on a different network from the primary, to maximize redundancy. A good idea is to swap secondary DNS duties with the admin of another server (i.e., you each do secondary DNS for each other's domains). The third line here tells named where to send email for goober.com; you'll define mail.goober.com's IP later. The "5" is the mailserver priority. When a remote SMTP server has a message to deliver, it will try to connect with the SMTP server for that domain with the lowest number in that field. If it can't deliver there, it will try the server with the next smallest number, and so on, until it gets to the server with the highest number there.

Note the trailing dots (".com.") in all of these entries. If you leave those off, named will try to resolve requests for goober.com and turn them into "goober.com.com" etc. Also note that up to this point, we are only using domain names, not IP addresses.

The last block defines the possible prefixes of your domain. These will probably all point to your server, but you can have them correspond to separate IPs -- for example, direct www.goober.com to one IP and ftp.goober.com to another. The second line (note the trailing dot!), which seems redundant, exists to handle the case where a user enters "http://goober.com/" without the www.

Keep in mind that the prefixes you choose here do not imply specific protocols -- in other words, "www.goober.com" does not have to be a webserver, nor does "ftp" have to be a file server, etc. -- the names and their implied protocols are meaningless, as far named is concerned. Here, you are simply accounting for whatever possible domain name strings you expect users to type, or that you yourself want to have. The user's use of "http://" or an FTP program will determine what ports/services they connect to on your server.

You will need to restart named for your changes to take effect (don't forget to update the serial number).

Once you've configured named on your end, you can go to your favorite registrar and register your domain. Be careful about the registrar's options -- you do NOT want their company to "park" your domain! That would mean that THEIR nameservers are claiming authority for your domain. Some registrars will have an "advanced" button or something similar; whatever they call it, you want to be taken to a screen where you can specify the nameservers for your domain. (Joker.com definitely allows this.) In our example, the first nameserver is slart (you'll need to know the hostname and IP of each of your nameservers) and the secondary is secondary-dns.not-slart.com. (with its corresponding IP). After a day or two, your domain registration will percolate up to the root nameservers, and they will direct requests for goober.com to slart (or to the secondary, if slart is unavailable).

If you want to test things before the registration has taken effect, you can do so by editing /etc/resolv.conf on your local machine such that the only nameserver listed is the primary you specified for your domain (in this case, resolv.conf would have just slart's IP). Then try accessing www.goober.com, etc. If you have problems, check the syntax in the db file (make sure the dots are all where they're supposed to be, that you used names or IPs where appropriate, check the serial number, etc.) Or, start nslookup and type:

server slart 	# or your primary DNS server
set type=A
www.goober.com

See if the results point to the correct IP.