You are a savvy net wrangler; doubtless you already know a bit about the Domain Name System ( Choose and Register a Domain Name). You know that it’s why we are able to have nice memorizable domain names like snackfight.com, and not just numbers. You probably even know that when you type “snackfight.com” into your browser, your computer contacts a DNS server to find out what numerical IP address the domain name corresponds to.
Let’s take a closer look, though, at exactly how this all works, what exactly is going on, and even how to set up a DNS server of your very own. Wait, you say — your ISP already provides DNS service for you. Why would you want to set up your own? I knew you’d ask that.
Why DIY DNS?
There are a few reasons why it can be beneficial to run your own DNS server. First, it’s fun and educational. Second, you are a control freak, and want to have as much of your site under your thumb as possible. If you are frequently or imminently changing machines, host names, IP addresses, ISPs, or other factors, or if you have a whole lot of web addresses to maintain, it is much easier to update your own data each time rather than faxing forms to the various providers and hoping you get everything right and they get everything right and that a virtual tug-of-war doesn’t ensue. Also, if you control your own DNS, you can do all sorts of neat tricks.
In this article, I’ll explain the different types of DNS records, what they contain, and then go over the basics of running a name server on a Unix network.
Computers on the Internet are primarily identified by IP addresses:those strings of four numbers separated by dots, each between 0 and 255, like 188.8.131.52. You can type these dotted octets into your browser, but humans like catchy names for things, so DNS, which maps names onto numbers and vice versa, was invented to make things easy for your pitiful, puny race! It is only a matter of time before your downfall!
Back in the day, the internet was small enough for this mapping to be contained in a single file. As the network grew, this quickly became unviable, and so the Domain Name System came into being. This system handles a large amount of rapidly changing mapping information by spreading the information around a number of servers. These servers are able to hierarchically query one another – asking around until they find an answer – so they can quickly look up Net addresses without having to store all that addressing info in one place.
Domain name data is structured hierarchically. At the top level is the so-called root node. Every domain on the Internet is a member of the root node. Under the root node are the top-level domains:com, edu, org, uk, ru, biz, and so on. The next levels down are the names known as “domain names” in the vernacular:webmonkey.com, navy.mil, as well as some organizational country code extensions, like co.uk. Anything below that is a subdomain or a host. Subdomain names can be layered to a total depth of 127, in case you happen to be crazy.
In order to understand DNS records, you will need some DNS terminology under your belt.
Data is handled and disseminated by name servers, which provide name information in response to queries from “resolvers.” A given name server is authoritative for a given zone, and if it’s asked for name information that’s not within its zone, it has to get the information from the name server that’s authoritative for the zone in question. The process by which a resolver queries a name server for DNS info and receives a response is called “resolution”:the resolver knows a domain name and wants to find out the corresponding numerical IP address. Or vice versa. The data lives primarily on the primary name server, which for redundancy and robustness is backed up to a secondary name server automatically at regular intervals.
Got all that? Good.
Now, DNS data is represented as DNS records in a zone data file, and these files are handled by the name server. There are a number of different kinds of DNS records, each suited to a specific kind of data.
Let’s take a look at the structure of the most important files. The records below are in the standard format used by BIND, the most common name server software. Djbdns, an alternative package, uses a somewhat different format.
SOA (Start Of Authority) records indicate the extent of the zone for which the name server is authoritative. They also contain information about how frequently they should be checked for updated information. An SOA record might look like this:
mydomain.com. IN SOA ns1.mydomain.com. root.mail.mydomain.com. ( 2002012901 24h 2h 4w 4d )
The first line indicates first the zone, then the type of record — Internet SOA — then the primary name server for the zone, and then a contact address for the zone. Note that the email address uses a period (dot) in place of the @, and that all of these domain names must end with a dot. On the next line is the serial number, which can be anything as long as it increased each time the record is updated. If you don’t update the serial number when you make a change to the record, the change won’t go through. The serial number I use above consists of the year, the month, the day, and the number of changes (01) made so far today. Next comes the frequency with which the data should be checked by a secondary name server, how often a failed attempt to connect should be retried, how soon the data should expire if it hasn’t been refreshed, and the default time-to-live of the data. In the record above, these are set to 24 hours, 2 hours, 4 weeks, and 4 days respectively.
NS (name Server) records provide a list of name servers authoritative for the zone:
mydomain.com. IN NS ns1.mydomain.com. mydomain.com. IN NS ns2.mydomain.com.
The real data, the reason we have name servers in the first place, is largely contained in A (Address) records. This is where the name-to-number mappings are kept:
mydomain.com. IN A 192.168.40.31 mail.mydomain.com. IN A 192.168.40.32 ns1.mydomain.com. IN A 192.168.40.33 ns2.mydomain.com. IN A 192.168.40.34 cheesebox.mydomain.com. IN A 192.168.148.44 lester.mydomain.com. IN A 192.168.148.45
CNAME (Canonical name) records allow aliases. A machine has one true, or canonical name, as well as an unlimited number of aliases:
www.mydomain.com. IN CNAME mydomain.com. wwww.mydomain.com. IN CNAME mydomain.com. ww.mydomain.com. IN CNAME mydomain.com. cb.mydomain.com. IN CNAME cheesebox.mydomain.com.
Note that, thanks to the above aliases, whether a browser tries to go to http://mydomain.com, http://www.mydomain.com, http://ww.mydomain.com, or http://wwww.mydomain.com, it will wind up at the same place.
The cardinal rule of CNAMEs is to use only a machine’s canonical name, never its alias, in any other record. So in our hypothetical network, “cb.mydomain.com” should never appear in, say, an A record, because it’s just an alias for the machine whose canonical name is cheesebox.
Pointer and MX Records
PTR (pointer) records are the reverse of A records:whereas the latter maps names to addresses, PTR addresses map addresses to names. PTR records are not stored in the main zone database for mydomain.com, but in another database which covers reverse lookups. There is a special domain set aside for reverse lookups:in-addr.arpa. PTR records reference addresses with respect to this zone. In practice, this means that when creating a PTR record, the numerical address is reversed and followed by “in-addr.arpa.” So the PTR record for the IP address 192.168.40.32 would refer to it as 184.108.40.206.in-addr.arpa.
Thus, the PTR records for the machines listed above would look like this:
40.168.192.in-addr.arpa. IN SOA ns1.mydomain.com. root.mail.mydomain.com. ( 2002012901 ; last updated January 29th, once 24h 2h 4w 4d ) 31 IN PTR mydomain.com. 32 IN PTR mail.mydomain.com. 33 IN PTR ns1.mydomain.com. 34 IN PTR ns2.mydomain.com. 44 IN PTR cheesebox.mydomain.com. 45 IN PTR lester.mydomain.com.
The last type of DNS record that we’ll cover is MX (Mail eXchanger) records. These address the handling of email. Each record specifies a machine that should handle the mail for a given domain. When multiple mail exchangers are listed for a given domain, they can be given rankings in order of preference. These rankings take the form of a number (from 0 to 65535, with 0 representing the most preferred exchanger) appearing before the name of the exchanger, so that if the more-preferred machine doesn’t work, the next in line will be tried.
mydomain.com. IN MX 0 mail.mydomain.com. mydomain.com. IN MX 50 lester.mydomain.com.
That’s the gist of DNS records. There are a number of other types of records for specialized purposes, but the ones we’ve covered are sufficient for most needs. There are abbreviated forms and shortcuts that you can use to save on typing and download times, but those are a little less transparent to the eye than the long forms.
The whole list of records is placed together in a zone data file, which looks like this:
$TTL 24h ; ; zone data file ; comments can appear on any line after a semi-colon ; mydomain.com. IN SOA ns1.mydomain.com. root.mail.mydomain.com. ( 2002012901 ; last updated January 29th, once 24h 2h 4w 4d ) mydomain.com. IN NS ns1.mydomain.com. mydomain.com. IN NS ns2.mydomain.com. mydomain.com. IN A 192.168.40.31 mail.mydomain.com. IN A 192.168.40.32 ns1.mydomain.com. IN A 192.168.40.33 ns2.mydomain.com. IN A 192.168.40.34 cheesebox.mydomain.com. IN A 192.168.148.44 lester.mydomain.com. IN A 192.168.148.45 www.mydomain.com. IN CNAME mydomain.com. wwww.mydomain.com. IN CNAME mydomain.com. ww.mydomain.com. IN CNAME mydomain.com. cb.mydomain.com. IN CNAME cheesebox.mydomain.com. mydomain.com. IN MX 0 mail.mydomain.com. mydomain.com. IN MX 50 lester.mydomain.com.
Notice that $TTL 24h at the top. That means that the file’s Time To Live is 24 hours. This file is placed on the name server machines. That sort of falls into the Setup topic, which we’ll cover next.
Setting Up A DNS Name Server
This section will cover the basics of running a name server on your Unix network.
The most prevalent name server software, called named (“name dee”) is included with BIND, the Berkeley Internet Name Domain, which also includes a resolver library and other tools. As of this writing BIND is up to version 9.4.2. Version 8.3.1 is also in widespread use.
The main alternative to BIND is djbdns, a package from the creator of qmail. It is designed for modularity and security (the author has a standing offer of $500 to anyone who finds a security hole in the software, which has gone unclaimed so far). It is smaller and faster than BIND, but the license controlling the source code is stricter, and djbdns gets a lot of flak for that. There’s a compelling debate of the virtues of the two systems in the archives of the BIND users mailing list.
In this tutorial, I’m talking mostly about BIND, although I definitely advocate djbdns as an alternative. Here is a guide to switching from BIND to djbdns.
Presumably you have, at the very least, a domain name and an IP address, and you want the one to point to the other. If you’re not at that point yet, you might want to talk to an ISP to see about getting an IP address, and a registrar for the domain name (If you need help, consult our Choose and Register a Domain Name tutorial).
First see if you have BIND already on your system. It may be there, behind the scenes unsuspected. Type named -v on the command line. If it returns a response telling you which version of BIND you’re running, that means you have it on your system, and don’t need to install it — although BIND is a prime target of attacks, and if you don’t have the latest version you may be leaving yourself open to a security risk.
Otherwise, download the source and unzip it, then install with ./configure ; make ; make install. Detailed instructions on configuring the build for your system are available in the INSTALL file; here is a walkthrough for Mac OS X.
Once you’ve installed BIND, you get to configure it. We don’t have space here to get into all the vicissitudes of configuring BIND. There’s an art to fine-tuning everything the way you want — heck, there’s a whole book on that topic.
The DNS howto will tell you how to set up the named.conf file, which contains the configuration information for the name server. The zone data files containing the DNS records we went over — typically, one for local use and another for external use — are placed in a specified directory. Then your system must be told to use the name server you have created. Anyway, the how-to on tldp.org explains all that better than I can.
With BIND set up, your name server is ready to rock. The DNS how-to will tell you how to set up the named.conf file, which contains the configuration information for the name server. The file should say that your name server is authoritative for mydomain.dom for forward lookups as well as 40.168.192.in-addr.arpa for reverse lookups. The zone data files containing the DNS records we went over typically, one for local use and another for external use are placed in a specified directory. Then your system must be told to use the name server you have created. Anyway, the how-to explains all that better than I can.
Note:I am indebted to Stephen Russell, who took the time to pinpoint and correct several problems that I overlooked in the early version of this article.