Developer

Setting up a Linux DNS server, part 2: Ongoing maintenance

See how to set up a secondary DNS server and learn how to make changes to records and keep DNS servers up to date.


In "Setting up a DNS server under Linux, part 1: The configuration," I discussed the initial setup and configuration of a primary DNS server. This week, I’ll explain how to configure a secondary DNS server and how to maintain and apply changes to your DNS servers. I’ll also show you some other interesting and useful things that you can do with your DNS server.

Configuring a secondary DNS server
You must set up a secondary DNS server (also known as a slave server). Let’s assume that you’ve already set up your primary DNS server. Call it ns.mydomain.com and give it an IP address of 192.168.1.1. Now, you’ll need to set up a secondary DNS server, which will be called ns2.mydomain.com and which will have an IP address of 192.168.1.2. Of course, you’ll also need to configure your /etc/named.boot file, which is similar to the file that has the same name on your primary server. For example, your primary server’s /etc/named.boot file may look like this:
directory/var/named
cache.named.ca
primarymydomain.commydomain.com
primary1.168.192.in-addr.arpa192.168.1


But the /etc/named.boot file on the secondary server should look like:
directory/var/named
cache.named.ca
secondarymydomain.com192.168.1.1 mydomain.com
secondary1.168.192.in-addr.arpa192.168.1.1 192.168.1


The differences between the two servers aren't significant. In the first column of the secondary server, you have to tell named that it’s “secondary” (as opposed to “primary”). In the third column, don’t type the database filename; instead, type the IP address of the primary server (and ns.mydomain.com’s IP address is 192.168.1.1). In the fourth column, type the database filename for that domain.

Please note that you don’t create the database on the secondary DNS server. Upon startup and as DNS refreshes (as determined by the primary DNS server of any given domain), named probes the primary DNS server for changes to any domain databases for which it acts as a secondary server. Thus, named actually creates the database files as they are required. The only other file for your secondary DNS server that you need to worry about is the /etc/named.conf file. It looks something like this:
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "mydomain.com"{
type slave;
file "mydomain.com";
masters { 192.168.1.1; };
};
zone "1.168.192.in-addr.arpa"{
type slave;
file "192.168.1";
masters { 192.168.1.1; };
};


This file looks very similar to the /etc/named.conf file that exists on your primary DNS server. The only difference is that the type keyword is "slave" instead of "master,” which indicates that it’s a secondary DNS server. In parentheses, the new keyword (masters) includes the IP address of the primary (or master) DNS server.

Maintaining your secondary DNS server is as simple as setting it up. The primary DNS server takes care of any changes that are made to MX records or other DNS information for a particular domain. Based on a time interval that was predetermined by the domain records, the secondary DNS server merely looks for updates. The only times when you’ll need to edit your /etc/named.boot and /etc/named.conf files are when you add or remove a domain. Otherwise, your secondary DNS server will take care of itself.

Delegating authority to subdomains
Some domains are quite large, and they often split up into logical subdomains for differing company divisions or groups. For example, a university that owns the domain myuniv.edu may want to give the physics department a subdomain of phys.myuniv.edu. However, if the physics department is large and has many computers, it will have to assign a lot of DNS entries. Instead of updating the primary DNS authority for myuniv.edu, the university could let phys.myuniv.edu have its own primary DNS server. That way, the physics department could make changes without disturbing the administrator of the domain’s primary DNS server. Now, let’s assume that the primary DNS for myuniv.edu is ns.myuniv.edu and the primary DNS for phys.myuniv.edu is h2o.phys.myuniv.edu. The database file for myuniv.edu might look like this:
@INSOA...
INA10.1.1.25
INMXmail.myuniv.edu.
INMXns.myuniv.edu.

h2o.physINA10.1.2.80

physINNSh2o.phys.myuniv.edu.
INNSns.myuniv.edu.


In this example, we gave h2o (the primary DNS for phys.myuniv.edu) an IP address of 10.1.2.80 as a precaution. If the folks in the physics department accidentally destroy their DNS data, their primary DNS server will still exist in ns.myuniv.edu's domain records. Since the h2o machine belongs to the phys subdomain, you should place h2o.phys in the first column (and not h2o). Doing so translates into h2o.phys.myuniv.edu—not just h2o.myuniv.edu (which is incorrect). The second NS line exists because you’ll want ns.myuniv.edu (the primary DNS server for the university) to act as a secondary DNS server for the new subdomain.

If you’re delegating authority for PTR records, the same rules apply. Your reverse resolution file on the primary server might look like this:
@INSOA...
INNSns.myuniv.edu.
25.1INPTRmail.myuniv.edu
...
2INNSh2o.phys.myuniv.edu


In the database, you’ll see two places for IP addresses. The first PTR record will resolve to 10.1.1.25, which points to mail.myuniv.edu. The final NS record in the database tells people who query 10.1.2.0-10.1.2.255 to send their queries to h2o.phys.myuniv.edu for the reverse resolution. The reverse resolution file on the primary DNS server should be named /var/named/10.1.db. That way, it can handle the 1.10.in-addr.arpa domain. Of course, this method only works if you delegate an entire byte boundary to the subdomain. If you just want to delegate 10.1.2.1-10.1.2.50, you have a lot of typing ahead of you; you’ll need to enter the following lines into your reverse resolutions file:
@INSOA...
INNSns.myuniv.edu.
25.1INPTRmail.myuniv.edu
...
1.2INCNAME1.1-50.1.10.in-addr.arpa
2.2INCNAME2.1-50.1.10.in-addr.arpa
...
49.2INCNAME49.1-50.1.10.in-addr.arpa
50.2INCNAME50.1-50.1.10.in-addr.arpa
1-50INNSh2o.phys.myuniv.edu


You have to type 50 different CNAME records, all of which point to the final NS record. Basically, you’re telling the requesting DNS server not to look for 1.2.1.10.in-addr.arpa (the reverse resolution for 10.1.2.1); instead, it should look for 1.1-50.1.10.in-addr.arpa, which points to the DNS server h2o.phys.myuniv.edu. This DNS server will answer the query.

Frankly, however, delegating reverse resolution to a subdomain that doesn’t occur on a byte boundary is more of a pain than it’s worth. It would be easier to let the primary server handle reverse resolutions instead of delegating the job to the subdomain. Since reverse resolution is extremely important, you can’t just forget about it. But there are easier ways to handle subdomain delegation than to delegate both forward and reverse resolutions to the subdomain. You could delegate forward resolutions to the subdomain and keep reverse resolutions on the primary domain.

Managing multiple domains
More often than not, a DNS server will have to manage more than one domain. You can even make a DNS server act as the primary server for some domains and as a secondary server for others—all with the same setup. It isn't very hard to do, but it involves several steps that you need to follow. First, you must edit your /etc/named.boot file so that you can manage the xyz.com domain, which we examined in the first part of our series, and the mydomain.com domain. With the following code, this machine will also become the secondary DNS server for otherdomain.com:
directory/var/named
cache.named.ca
primaryxyz.comxyz.com.db
primarymydomain.commydomain.com.db
secondaryotherdomain.com192.168.1.28 otherdomain.com.db
primary1.168.192.in-addr.arpa192.168.1.db


Your DNS server will be the primary server for xyz.com and mydomain.com, and it will be the secondary server for otherdomain.com. You can obtain the DNS records from the primary DNS server for otherdomain.com at 192.168.1.28. Next, edit the /etc/named.conf file so that it will provide the same information:
options {
directory "/var/named";
};
zone "." {
type hint;
file "named.ca";
};
zone "xyz.com"{
type master;
file "xyz.com.db";
};
zone "mydomain.com"{
type master;
file "mydomain.com.db";
};
zone "otherdomain.com"{
type slave;
file "otherdomain.com.db";
masters { 192.168.1.28; };
};
zone "1.168.192.in-addr.arpa"{
type master;
file "192.168.1.db";
};


Configure the database files as you normally do. For example, edit the resource records in /var/named/xyz.com.db, /var/named/mydomain.com.db, and 192.168.1.db. Remember, named creates the /var/named/otherdomain.com.db file when it refreshes the zone information for the otherdomain.com domain.

Now, you're going to have to decide which is your primary domain. Let's assume that mydomain.com is the primary domain for your system and that xyz.com is a domain that you’re hosting (but that you don’t necessarily own). This distinction is important when you’re setting up your reverse resolution records (or the 192.168.1.db file). When you perform reverse resolution, you can point to only one machine name per IP address.

For example, let’s assume that mydomain.com has three machines, and each machine has its own separate IP address that’s reachable from the Internet. Your primary machine is called web.mydomain.com because it’s your Web server. It also acts as your primary DNS server. The second machine is called mail.mydomain.com, and it acts as your SMTP and POP3 server. The third machine, which is called backup.mydomain.com, is your secondary DNS server. Setting up your network this way will distribute the load across multiple computers; no single computer will become completely saturated with IP traffic.

If you’re hosting xyz.com, give it the same information. Define web.xyz.com, mail.xyz.com, and backup.xyz.com and define any appropriate CNAME records along the way. Now, you have two fully qualified domain names per machine, for your Web server can be reached by web.mydomain.com and web.xyz.com. Similarly, the other two machines can be reached by two different (but fully qualified) domain names. You can’t place both of these domains in your reverse resolution database, so you use your primary domain instead (mydomain.com). Your reverse resolution file might look like this:
NSweb.mydomain.com.
NSbackup.mydomain.com.
1PTRweb.mydomain.com.
2PTRmail.mydomain.com.
3PTRbackup.mydomain.com.


If you follow these steps, you shouldn’t have any problems serving multiple domains from one machine. Basically, all you really need is one primary domain for your network. Usually, when you define the hostname for your computer, you have only one hostname and one domain name. This domain name will become your primary domain because it’s the one that’s used across your network.

Forwarding DNS requests
Forwarding DNS requests to another DNS server is a simple way of lessening the load on your DNS server. If the local server receives any queries that it can’t resolve from its own local cache, it will forward hostname lookup requests to a specific list of servers. This method builds a rich cache on the selected server and keeps the load down on secondary servers. If possible, this selected server should exist on your local network. That way, you’ll prevent your secondary servers from reaching out to the Internet to resolve hostname lookups. Only one server on your local network will look up hostnames across the Internet, which can become very helpful if you’re paying for Internet usage. Here’s an example of a /etc/named.conf file using the forwarders option:
options {
directory "/var/named";
forwarders first;
forwarders { 192.168.1.1; 192.168.1.2; };
};


These lines tell the local server to try the forwarders before it tries to get an answer from any other external server (such as the root servers that InterNIC runs). The forwarders first; option is somewhat redundant because it tells the local server to try the forwarders before trying anything else, which is the default setup. An alternative option is the forwarders only; option, which tells the local server to talk to forwarders only. With the forwarders only; option, any queries not resolved by the forwarders will remain unresolved because the local server is explicitly told not to try any external servers. The forwarders option contains a list of DNS servers to which all queries will be forwarded. (In the above lines, 192.168.1.1 would be consulted first; then, 192.168.1.2 would be consulted.)

Final tips
Now, I'm going to give you two tips that will save you a lot of headaches. If this is the first DNS server that you’ve ever set up, you’ll want to pay close attention to these tips. First, due to various RFCs that relate to domain name services, you must keep in mind that NS and MX records can’t point to CNAME records. These record types must point to an explicitly defined A record. If not, named will remind you by writing an error to the syslog. Although named will run with NS and MX records pointing to CNAMEs, it isn’t proper, and this method may cause problems. Pointing to a name server called bunny.xyz.com instead of ns.xyz.com may not be as cosmetic, but it’s proper. Since this difference is invisible to everyone except other DNS servers, it doesn't really matter. You can define a CNAME of ns.xyz.com to point to bunny.xyz.com. If you’re worried about cosmetics, you can tell your users to use ns.xyz.com as the DNS server for normal hostname resolving.

Second, if you want to set up primary and secondary DNS servers, make sure that they exist on separate machines. Remember, named doesn't like it very much if you tell it to act as both primary and secondary DNS for any given zone or domain. It will write an error to the syslog if it encounters this configuration.

Conclusion
Setting up a DNS server can remain a simple and straightforward job, or it can become extremely complex—based on your needs. I trust that I've approached the configuration and installation of BIND and the DNS server system in a way that will help you get the most out of any DNS server that you set up. Another excellent source of information on DNS is the DNS Resources Directory. This source will help you obtain further advanced configuration, if you require it.

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. Prior to that, he used OS/2 exclusively for approximately four 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 Freezer Burn Web siteto building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench.He hopes to tackle the RHCE once it can be taken in Canada.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks

Free Newsletters, In your Inbox