Setting up a Linux DNS server
[LEFT][CODE]http://articles.techrepublic.com.com/5100-10878_11-1052952.html[/CODE]
[B][SIZE=3]
[/SIZE][/B][B][B][SIZE=3]Part 1: The Configuration[/SIZE][/B][/B]
[SIZE=3][B]Takeaway:[/B] So, you've decided to use Linux for your Internet services. It's a good idea, but many of the available resources that help you set up your DNS server are unnecessarily confusing. That's why Vincent Danen has written this clear two-part series.[/SIZE]
Using Linux for your Internet services not only provides you with stability; due to Linux’s low cost, it’s also economically sound. People are beginning to use Linux as their Internet servers for a variety of reasons. If you want to make Linux your networking solution, however, you can set up many services that will provide you with a robust and suitable server environment. Besides the basic Web hosting, FTP, and e-mail services that Linux provides, you’ll also get Domain Name System (DNS) services. In this Daily Drill Down, I’ll explain how you can configure a DNS server for your Linux system. There are many resources that will help you set up a DNS server, but some of them are difficult to follow and too confusing. So, I’ll provide clear instructions for obtaining a DNS server setup that will enhance your Internet hosting services.
Who needs DNS servers?
Typically, people who run their own Web sites with their own domain names have external providers manage those domains. Many of these external providers allow you to change certain aspects of how you control your own domain via Web site forms and controls. However, some of these services, which are adequate for simple Web hosting servers, are lacking when it comes to handling distributed loads on your network. For example, if your primary server handles Web hosting, you may not want your FTP server to exist on the same system. Or if you run all of your servers on the same computer, you may want a backup server to assume e-mail services in case your primary server goes down. In these situations, you’ll need more flexibility than some management services give you. (You also won't have to pay someone else to manage something that you could take care of yourself.) Since the tools that you need to set up a DNS server under Linux come with almost every major distribution, there are no additional costs or required programs. You can run these services almost right out of the box.
BIND
Linux uses a program called BIND (Berkeley Internet Name Domain) to provide the DNS server, which is a daemon called [I]named[/I]. This daemon handles all of the DNS queries for whichever domains you run or manage. In fact, [I]named[/I] is a full-fledged DNS server. If you manage multiple domains, this daemon can handle all of them very easily. On most distributions, the BIND package will have been installed by default, but you should check to see if the [I]/usr/sbin/named[/I] file exists (it’s the [I]named[/I] executable). On Red Hat systems or other distributions that use RPM (Red Hat Package Manager) technology, you can run the following line:
rpm -q bind
If this package isn’t installed, you should be able to obtain it from the distribution vendor, a mirror site, or your installation CD-ROM. Once you’ve installed BIND, you’re ready to begin setting up your new DNS server. For this Daily Drill Down, I’ll install and configure BIND on a Linux Mandrake 7.0 computer for the fictional domain [I]xyz.com[/I].
SOA resource records
The first step in setting up the DNS server for [I]xyz.com[/I] is to edit a database file for the SOA (Start of Zone Authority) resource records. The SOA resource records are the meat of the server; they provide the information that’s needed to resolve domain names to IP addresses. These files are typically stored in the [I]/var/named[/I] directory, but you can name them anything you want. For this example, I’ll name my SOA file [I]/var/named/xyz.com[/I].
The SOA resource records require a number of fields, which I’ll explain as I proceed. You can include comments in the resource file by typing a semicolon ([I];[/I]) before the comment. Comments will help you understand what you did and what everything means if you need to refer to them later. You should write as many comments in the file as you think you need. The resulting file will look something like the following:
@INSOAns.xyz.com root.titan.xyz.com (
2000031601 ; serial number
7200 ; refresh (2hrs)
3600 ; retry (1hr)
151200 ; expire (1 week)
86400 ) ; default TTL
This is the beginning of our SOA resource file. The first line gives us a few pieces of information for this SOA record. The [I]@[/I] character represents the domain name for this zone. (Later, you’ll see how it gets translated.) The [I]IN[/I] statement stands for [I]Internet Name[/I], and SOA tells us that we’re defining the SOA for our domain ([I]xyz.com[/I]). The first domain name after SOA defines the primary name server for this domain ([I]ns.xyz.com[/I]). The second field is the administrative e-mail address ([I]root@titan.xyz.com[/I]). Notice that the e-mail address uses a period instead of the [I]@[/I] character in the SOA record, so make sure that you format the e-mail address correctly. After the administrative e-mail address, type an opening parenthesis to indicate the following numeric statements.
The next lines indicate parameters for the server. The first number is the serial number. Some people use one or two digits for the serial number, but I prefer to use the date and a revision number. The above serial number translates into “03/16/2000—revision 01.” Every time you change the resource record, you need to increase the serial number by one before you restart [I]named[/I]. That way, secondary servers will know that they have to perform a zone transfer. If you never increase this number, your changes will never take effect.
The second number is the refresh rate in seconds. This value tells the DNS servers how often they should query the primary server to see if the records have been updated at all. The third number is the retry rate in seconds. If the secondary server tries to contact the primary DNS server to check for updates but can’t contact it, the secondary server will try again after the number of seconds that you’ve defined here has elapsed.
The fourth number relates to secondary servers that have cached the entry. If these secondary servers can’t contact the primary server for an update, they will discard the cached value after the specified number of seconds. You should specify a value of one to two weeks. The fifth and final number tells caching servers how long they should wait before allowing an entry to expire if they can’t contact the primary DNS server. Five to seven days is a typical value for this number. Finally, you must place a closing parenthesis to end the statement.
NS servers
The next entries should specify the authoritative NS (Name Server) servers for your domain. Using the previous example, we would type something like this:
NSns.xyz.com.
NSns2.xyz.com.
There are two authoritative name servers for the [I]xyz.com[/I] domain: [I]ns.xyz.com[/I] (the computer that we’re currently setting up) and [I]ns2.xyz.com[/I] (a secondary or backup DNS server). Since both are fully qualified hostnames, they need to have periods after their names. If you were to write the above lines as [I]ns.xyz.com[/I] and not as [I]ns.xyz.com.[/I], the server would translate the addresses as [I]ns.xyz.com.xyz.com[/I]. You probably don’t want that.
MX records
The next entry should include the MX (Mail Exchanger) records. This entry tells the outside world that the defined machine will be in charge of receiving mail from external networks. If you have two computers (one for a primary and one for a secondary/backup mail server), you might issue the following lines:
MX10 mail.xyz.com.
MX50 ns2.xyz.com.
These lines tell external networks to try to deliver mail to the [I]mail.xyz.com[/I] machine first. If the first machine can’t be reached, then external networks will deliver mail to [I]ns2.xyz.com[/I]. The number in the second column is a priority number. You can use any number as long as you adhere to one rule: Lower numbers have a higher priority. Since [I]mail.xyz.com[/I] has a priority level of 10, it has a higher priority than [I]ns2.xyz.com[/I], which has a priority level of 50. Thus, all external mail servers will attempt to deliver mail to [I]mail.xyz.com[/I] first.
A records
The next section deals with A (Address Record) records. Address records provide translations from hostnames to IP addresses. You should have A records for all of the machines for which you want to have a recognized hostname. If you have four computers in your network, you would run the following lines:
nsA192.168.1.1
ns2A192.168.1.2
workA192.168.1.3
develA192.168.1.4
These lines tell the DNS server that [I]ns.xyz.com[/I] is mapped to the IP address of 192.168.1.1 but that [I]devel.xyz.com[/I] is mapped to the IP address of 192.168.1.4. Since there’s no period after the hostname, the DNS server assumes the same domain of the current SOA record (the [I]xyz.com[/I] SOA).
CNAME records
The next section should contain any Canonical Name (CNAME) records (also known as hostname aliases) that you want to define. Using CNAME aliases is quite common and very helpful in giving common names to servers. For example, suppose that your mail server's real hostname is [I]work[/I] because you complete other work on it. You could give it a CNAME of [I]mail[/I] so that you could reach it through both [I]work.xyz.com[/I] and [I]mail.xyz.com[/I]. For the CNAME to work, you must have defined an Address (A) or Mail Exchange (MX) record already:
MailCNAMEwork
wwwCNAMEwork
ftpCNAMEwork
mail2CNAMEdevel
The above lines will map [I]mail.xyz.com[/I], [I][url=http://www.xyz.com]XYZ Consulting[/url][/I], and [I]ftp.xyz.com[/I] to the [I]work.xyz.com[/I] computer. Also, you must define an alias of [I]mail2.xyz.com[/I], which points to the [I]devel.xyz.com[/I] computer.
TXT and RP records
Finally, you can include some text information in your SOA record by using the TXT and Responsible Person (RP) record types. They are useful for providing contact information in your DNS records that others can query. TXT records are free-form records that can place any information that you want to make available to others. TXT records must be tied to a particular hostname, however, so order is important. Below, I’ll illustrate what your [I]/var/named/xyz.com[/I] file should look like, and you’ll see how you should place your TXT records:
TXT"Contact: Jim Smith"
TXT"Great Guru of Linux"
The RP records are also informational, but there’s a particular syntax that you must follow when you use them:
RPadmin.xyz.comxyz.com.
The first field in the RP record is the e-mail address of the person in charge of this domain. Notice that the [I]@[/I] symbol has been replace by a period. (The actual e-mail address is [I]admin@xyz.com[/I].) The last column specifies a TXT record, which provides more information. In this case, it’s the TXT record for [I]xyz.com[/I].
The finished product
Now, we’ve defined all of the important parts of our primary SOA record in the [I]/var/named/xyz.com[/I] file. The finished product will look something like this:
; Forward resolution for xyz.com
;
@INSOAns.xyz.com root.titan.xyz.com (
2000031601 ; serial number
7200 ; refresh (2hrs)
3600 ; retry (1hr)
151200 ; expire (1 week)
86400 ) ; default TTL
; define our name servers:
NSns.xyz.com.
NSns2.xyz.com.
; define our mail severs:
MX10 mail.xyz.com.
MX50 ns2.xyz.com.
; define the contact information for this domain:
TXT"Contact: Jim Smith"
TXT"Great Guru of Linux"
RPadmin.xyz.comxyz.com.
; define addresses and aliases:
nsA192.168.1.1
ns2A192.168.1.2
;
workA192.168.1.3
mailCNAMEwork
wwwCNAMEwork
ftpCNAMEwork
;
develA192.168.1.4
MX10 mail2.xyz.com.
mail2CNAMEdevel
With the exception of another MX record, all of the above lines are the same as the ones I’ve already listed. Since order is important, we can perform several interesting tasks, such as defining different mail servers for different machines. In the above example, all machines use [I]mail.xyz.com[/I] or [I]ns.xyz.com[/I] for their mail servers—except for [I]devel.xyz.com[/I], which uses its own mail server on the same computer. Then, we defined the Address record for [I]devel.xyz.com[/I] and gave it a specific MX record ([I]mail2.xyz.com[/I]), which is a CNAME alias for [I]devel.xyz.com[/I]. There are a number of ways in which you can perform tasks with your DNS server and the records you’re setting up. The above example is pretty simplistic, but other examples can become much more complicated and powerful.
Reverse resolution database
Now that you’ve defined your primary SOA, you must provide a reverse resolution database to match it. Place the second database in a file called [I]/var/named/192.168.1[/I]. It follows pretty much the same syntax as the first database, but you don't define its A, MX, CNAME, TXT, or RP records.
; Reverse resolution for xyz.com
;
@INSOAns.xyz.com root.titan.xyz.com (
2000031601 ; serial number
7200 ; refresh (2hrs)
3600 ; retry (1hr)
151200 ; expire (1 week)
86400 ) ; default TTL
; define our name servers:
NSns.xyz.com.
NSns2.xyz.com.
1PTRns
2PTRns2
3PTRwork
4PTRdevel
The SOA record and the NS records are exactly the same. The new record type that we see here is the Pointer (PTR) record. The Pointer record is also known as the reverse resolution record, and it tells [I]named[/I] how to turn an IP address into a hostname. If you look closely, you’ll see that the PTR record starts with a single digit, which happens to be the last octet of the IP address for the defined hostnames. What we’re telling [I]named[/I] is that 192.168.1.1 points to the hostname [I]ns[/I], which in turn resolves to [I]ns.xyz.com[/I]—and so on. You’ll see how [I]named[/I] knows to complete the IP address in a moment.
Next, you have to tell [I]named[/I] that it needs to read these databases. So, you must edit the [I]/etc/named.boot[/I] file. Your [I]named.boot[/I] file should look like this:
directory/var/named
cache. named.ca
primaryxyz.comxyz.com
primary1.168.192.in-addr.arpa192.168.1
These lines tell [I]named[/I] to use the [I]/var/named[/I] directory (which is where we saved our databases). They also tell [I]named[/I] to cache the DNS entries and speed things up a bit. Finally, we define two primary zone records: one for the forward resolution of [I]xyz.com[/I] (our [I]/var/named/xyz.com[/I] file) and one for the reverse resolution of our IP addresses (our [I]/var/named/192.168.1[/I] file). Remember, in our SOA records, we used the [I]@[/I] symbol to represent our domain name. This is where the SOA record obtains the domain name. For example, you can define your databases in one of two ways. First, you can type:
@INSOAns.xyz.com root.titan.xyz.com (
Or you can define them like this:
xyz.com.INSOAns.xyz.com root.titan.xyz.com (
Using substitution with the [I]@[/I] symbol is easier because you’ll only need to change your [I]/etc/named.boot[/I] file if you want to change the domain name. Now, you have one last file to configure: the [I]/etc/named.conf[/I] file. It looks like this:
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "xyz.com"{
type master;
file "xyz.com";
};
zone "1.168.192.in-addr.arpa"{
type master;
file "192.168.1";
};
This file is pretty straightforward, and it almost duplicates what we put in the [I]named.boot[/I] file. The first line specifies the options where you define the base directory for [I]named[/I] (which is [I]/var/named[/I]). The zone entries are for each domain and reverse resolution record that you define. Notice that [I]xyz.com[/I] points to the [I]/var/named/xyz.com[/I] file, while the reverse resolution (which is recognized by [I]1.168.192.in-addr.arpa[/I]) points to the [I]/var/named/192.168.1[/I] file. Also notice that our cache file (which is specified by the period in the first zone statement) is the [I]/var/named/named.ca[/I] file. This file came with the BIND program that you installed. Basically, it’s a file that contains the IP addresses of the root DNS servers; it allows [I]named[/I] to prime the cache.
For both domain zones, you can define the authoritative system by indicating that the machine is of the “master type.” If you were setting up a secondary DNS server, you would indicate that the machine was of the “slave type.” Here’s an example of a secondary DNS server zone statement:
zone "xyz.com"{
type slave;
file "xyz.com";
masters { 192.168.1.1; };
};
These lines tell [I]named[/I] that this machine is a secondary (or slave) DNS server. They also point to the primary (or master) DNS server ([I]192.168.1.1[/I]).
Starting the service
Now that you know how to configure the DNS server, you're probably wondering how to start it. On Linux Mandrake and Red Hat systems, the appropriate command to start the named daemon would be:
/etc/rc.d/init.d/named start
You could use this [I]chkconfig[/I] utility and force the DNS server to start at boot:
chkconfig --level 2345 named on
To start the server in the background on all other systems, simply run [I]named[/I] without command line arguments. If you want to look at the man pages and see what other command line options can be used, run [I]man named[/I].
Conclusion
Setting up a DNS server can become time-consuming and confusing. However, I trust that I’ve made the process a little easier to understand. If you want more information on BIND, take a look at [URL="http://www.isc.org/"]Internet Software Consortium[/URL]. You should check out this [URL="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"]DNS HOWTO[/URL] for more information, too.
Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Vincent is a firm believer in the philosophy behind the Linux "revolution,” and heattempts to contribute to the Linux causein as many ways as possible—from his [URL="http://www.freezer-burn.org/"]FreezerBurn Web site[/URL] to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from [URL="http://www.brainbench.com/"]Brainbench[/URL] .He hopes to tackle the RHCE once it can be taken in Canada.
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes
[/LEFT]
