Configuring DNS on SLES 9

This chapter is from the book 

Advanced DNS Configuration

TEST OBJECTIVE COVERED:

1. Configure a DNS server using BIND.

The DNS server you configured in Lab Exercise 3.1 is well suited for many networks. However, you should be aware of some advanced features and security issues. Although there are many subjects we could address, in this topic we'll focus on the following:

• Configuring forwarding
• Securing the DNS server
• Configuring LDAP support

Let's start with configuring DNS forwarding.

Configuring Forwarding

Recall that at the beginning of this chapter, we discussed how the DNS name resolution process works. We said that your DNS server, if asked to resolve a hostname for which it isn't authoritative, will first contact a root-level name server. The root-level name server will provide the IP address of a TLD name server. Your DNS server will then send the request to the TLD name server, which will respond with the IP address of the DNS server that is authoritative for the zone where the host resides (see Figure 3.7).

This process works reasonably well. However, two problems are associated with it:

• It creates a fair amount of network traffic.
• It can be somewhat slow.

If you want to see just how slow, give it a try on your SLES 9 server. Open a shell prompt and enter dig www.novell.com (or any other hostname for which your server isn't authoritative). You'll notice that it takes up to 3 seconds for you to get a response. If you enter the command a second time, dig provides a response instantly. That's because your named daemon cached the information the first time it made the query.

Forwarding is a feature of DNS that speeds things up. When you configure forwarding, your DNS server will directly contact another specified DNS server when it needs to resolve a name for which it isn't authoritative. The assumption is that the second DNS server has tons of names already in its cache. This saves the laborious process of finding the root server, then the TLD server, and then the authoritative server.

Forwarding is generally implemented in two situations:

• Your organization has implemented a DNS server hierarchy.
• Your network is connected to the Internet using an ISP who supplies a DNS server for customers to use.

I've never actually worked for an organization that uses a DNS server hierarchy; however, I've heard of some that do. Those that I know of are academic institutions that have many networks, usually each owned by a particular department. Each department has its own DNS server.

Rather than having all these separate DNS servers walking the DNS domain tree to resolve outside hostnames, they are configured to resolve up a chain of internal DNS servers. As a result, only one or two DNS servers go outside on the Internet. These servers cache huge numbers of names, which really speeds up the resolution process. This situation is depicted in Figure 3.34 below:

The situation I've seen more frequently is the second scenario presented. Many organizations go through an ISP to connect their network to the Internet. Most ISPs provide one or more DNS servers for their customers to use. You can use forwarding to point your DNS server to your ISP's DNS server. The assumption is that your ISP's DNS server gets used a lot and, therefore, has a lot of names in its cache. Again, this configuration saves your DNS server from having to walk the DNS tree to resolve names it's not authoritative for.

Forwarding is relatively easy to implement. To do this, complete the following:

1. Open /etc/named.conf file in a text editor.
2. Locate the Options directive and find the forwarders parameter, as shown in Figure 3.35:
   

   Figure 3.35 Enabling DNS forwarding.

3. Uncomment the forwarders line.
4. Within the curly brackets, enter the IP addresses of the servers you want your DNS server to forward requests to (separated by semicolons).
5. Uncomment the forward first line.

With these option enabled, the server will first query the DNS servers listed in the forwarders line. If, for some reason, it can't get an answer, it will proceed with the traditional DNS name resolution process.

Now that you understand forwarding, let's look at some steps you can take to increase the security of your DNS server.

Securing the DNS Server

In the past, a number of attacks on servers have been perpetrated through the BIND service. Fortunately for us, many of these attacks have been mitigated because vulnerabilities were fixed in BIND version 9.x. In spite of these fixes, you still need to do a number of things to secure your DNS service as well as the server it runs on. These include the following:

• Running named in a chroot Jail
• Restricting Zone Transfers
• Using ACLs

Let's first look at putting your named daemon in jail!

RUNNING NAMED IN A CHROOT JAIL

One of the main problems in earlier BIND releases was that the named daemon ran as root by default. The service needed access to a variety of files in the file system as well as access to the system log; to make this possible, named ran as root.

Although this accomplished the goal, it also opened up a big security hole. Because named ran as root, it had full and unfettered access to the entire system. If a hacker were to discover a way to exploit the named daemon (and it did actually happen) then he or she could gain access to the system with root-level access. Yikes!

To fix this problem, you need to configure named to run as a different user. Better still, you need to create a chroot jail and run named within it.

By doing this, you deny named root access and you deny it access to anything outside its own directory structure in the file system.

So, how do you go about doing this? In the old days we had to do this manually. It was a fairly complicated process, not for the faint of heart.

Fortunately for us, we don't have to worry about it. Why not? The version of BIND 9 that you installed in Lab Exercise 2.1 automatically installs named into a chroot jail! To verify this, open /etc/sysconfig/named in a text editor, as shown in Figure 3.36.

Notice that, by default, the NAMED_RUN_CHROOTED parameter is set to yes. The chroot jail is located in /var/lib/named. Notice also that each time the service is stated, the various named configuration files are copied from their locations elsewhere in the file system into the jail, eliminating the need for named to access other directories and files in the file system.

Because named now runs in a chroot jail by default, it no longer runs as root. Have a look at Figure 3.37.

Notice that named runs using the named user account. Hats off to the BIND 9 developers! They have really made our lives as system administrators a lot easier.

Now that we've discussed running named in a chroot jail, let's look at our next security topic: restricting user access to your DNS server.

RESTRICTING USER ACCESS TO THE DNS SERVER

By default, the DNS service running on your server is wide open for anyone to use. Depending on your situation, this may or may not be an issue for you.

If your DNS server resides on your local area network behind your organization's firewall, restricting user access may not be an issue. Because of where it's located, the only users who will be able to access it are authorized users.

However, if your DNS server resides in your organization's demilitarized zone (DMZ), which is a very common situation, you may want to configure restrictions that define who can use the service. Otherwise, it's wide open for anyone on the Internet (who know its IP address) to use.

To restrict user access, you use the allow-query directive. Inserting this directive in your named.conf file allows you to specify a list of IP addresses that are allowed to submit queries for name resolution to the DNS service. The allow-query directive is followed by a list of IP addresses, separated by semicolons.

You may be saying at this point, "Whoa! I don't want to have to list each and every IP address that's allowed to use the DNS server!" You're right—that could represent a monumental task, especially if your network is a big one. Fortunately, the allow-query directive allows you to use network addresses as well as IP addresses. This allows the DNS server to respond to queries from all hosts on the specified network. This is shown in Figure 3.38:

In Figure 3.38, the allow-query directive has been inserted within the options statement of the named.conf file. By placing this directive here, the restriction will apply to all zones hosted by the local DNS server. In this example, the DNS server has been configured to respond only to queries that come from systems whose IP address is 192.168.1.x.

If a host with an IP address outside the specified range sends a query for name resolution to the DNS server, it will deny the request.

There may be situations in which your DNS server is hosting multiple zones and you want to restrict access on a per-zone basis. Can you do it with the allow-query directive? You bet!

In addition to the options statement, you can also place allow-query directives within each zone declaration. By doing so, you can customize the hosts that can query each zone.

For example, suppose your DNS server has two zones: cle9.com and somedomain.com. You want to restrict the cle9.com zone to users on the network segment that has the IP address of 192.168.1.0. Likewise, you want to restrict somedomain.com to users on a different network segment: 192.168.2.0. To do this, you would add the allow-query directive to each zone, as shown:

zone "cle9.com" in {
    file "master/cle9.com";
    type master;
    allow-query (192.168.1.0/24;);
};

zone "somedomain.com" in {
    file "master/somedomain.com";
    type master;
    allow-query (192.168.2.0;);
}; 

Now that you know how to lock down user access to your DNS server, the next thing you need to know is how to restrict zone transfers.

RESTRICTING ZONE TRANSFERS

Recall our earlier discussion of master and slave DNS servers. We said that slave DNS servers are implemented to provide a degree of fault tolerance to your name resolution system. They do this by periodically transferring zone information from your master DNS server. This process is called a zone transfer.

After a zone transfer has occurred, the slave DNS server can resolve hostnames just like a master DNS server. However, any modifications or updates that need to be made to the zone must be made to the master server and then replicated out to the slave server. Any changes you make to a slave DNS server will be lost when the next zone transfer occurs.

The problem with zone transfers is that, by default, your master server is wide open. Anyone who knows your server's IP address can initiate a zone transfer. Although there may be some who don't care, the rest of us care a great deal. It adds significant overhead to your DNS server and it also provides the other party with a list of hostnames and IP addresses on your network that you probably don't want them to have.

The good news is that you can lock down zone transfers. This is done with the allow-transfer directive in your named.conf file. This directive allows you to specify which slave servers are allowed to initiate a zone transfer with your server. The allow-transfer directive is followed by a list of IP addresses of servers, separated by a semicolon, that are allowed to transfer zone data from your server.

If you want to establish a blanket rule for all zones hosted by the DNS server, you can insert an allow-transfer directive within the options statement in your named.conf file, just like the allow-query directive. An example is shown in Figure 3.39:

In Figure 3.39, the named daemon has been configured to allow zone transfers only with the DNS server that has an IP address of 192.168.1.48. Because it's listed within the options statement, zone transfers for all zones hosted by named on this server are limited to this single slave DNS server.

Suppose you don't use a slave DNS server and you don't want anyone to be able to initiate a zone transfer? You can do this as well with the allow-transfer directive. Simply add the following somewhere within the options statement of your server's named.conf file:

allow-transfer {"none"; };

You may encounter situations in which you need to configure zone transfer restrictions on a per-zone basis. Many times, you many want one zone on your DNS server to synchronize with one slave DNS server and other zone on your DNS server to synchronize with a different slave server.

This can also be done with the allow-transfer directive. Instead of putting the directive in the options statement of named.conf, you put it within the zone declaration itself in the file.

For example, suppose your DNS server hosts two zones; cle9.com and somedomain.com. You want zone transfers for cle9.com to be restricted to a slave server with an IP address of 192.168.1.48. You also want zone transfers for somedomain.com to be restricted to a slave server with an IP address of 192.168.1.49. To do this, you would configure each zone declaration within your named.conf file with its allow-transfer directive, as shown:

zone "cle9.com" in {
    file "master/cle9.com";
    type master;
    allow-transfer (192.168.1.48;);
};

zone "somedomain.com" in {
    file "master/somedomain.com";
    type master;
    allow-transfer (192.168.1.49;);
};    

If you're managing a large DNS implementation with many zones and complex access rules for user queries and zone transfers, you may want to consider using Access Control Lists (ACLs) for your DNS server to simplify this process. Let's look at those next.

USING ACLS

With DNS you can define ACLs that you can use to configure your restrictions.

With a DNS ACL, you define an access control list in your named.conf file. Then you can reference these ACLs when you use the allow-query and allow-transfer directives. The general syntax in the named.conf file is the following:

acl acl_name {list_of_addresses; };

The acl statement is parallel with the options and zone statements. Be sure you don't place it within the options statement. The acl_name parameter is any name you want to give the ACL. You will use this name in other directives, such as allow-query, to reference back to the ACL. The list of addresses parameter is a list of IP addresses or network addresses you want to include in the ACL.

For example, suppose you want to configure your DNS server so that queries are restricted to two network segments: 192.168.1.0 and 192.168.2.0. You could create an ACL in your named.conf file as shown:

acl allowedhosts {192.168.1.0; 192.168.2.0; };

Then you could insert an allow-query directive within the options statement that references the ACL, as shown:

allow-query {allowedhosts;};

Using ACLs can save you a lot of typing and prevent a lot of typos. You can also use YaST to define ACLs in your named.conf file by doing the following:

1. Start YaST.
2. Select Network Services, DNS Server.
3. In the left frame, select ACLs. When you do, the screen in Figure 3.40 is displayed:
   

   Figure 3.40 Defining ACLs in YaST.

4. In the Name field, enter a name for your ACL.
5. In the Value field, enter the IP address(es) you want included in the ACL. If you use more than one, be sure to separate them with a semicolon. Don't worry about entering brackets; YaST puts them in automatically for you.
6. Select Add, Finish.

Recall earlier that I mentioned that you could use any and none in your allow-query and allow-transfer directives? These are predefined ACLs that are automatically implemented when you installed BIND.

Now that you've learned how to lock down your DNS server, we need to cover one last topic in this course—configuring your DNS server to store information in the LDAP directory.

Configuring LDAP Support

Recall that in Chapter 1 when we were discussing LDAP, I mentioned that one of the advantages of LDAP was that, in addition to user accounts, you could store your DNS configuration in the directory.

Why would you want to? Admittedly, this is a new concept for most Linux system administrators. I've not seen many production systems configured to work this way. It may take a while to catch on. However, after you understand the benefits of using LDAP for DNS, you may have a hard time going back.

The main problem with the traditional DNS configuration is that important information is stored locally in text files. If something were to happen to your server, your name resolution system is gone.

Even if you configured a slave DNS server to back up your zone data, a natural catastrophe could still take down your name resolution system if the servers were located in the same geographic location.

Storing your name resolution information in LDAP, on the other hand, makes your DNS system less server-centric. Instead of storing the configuration in local text files, the data is stored in the LDAP directory, which can be replicated and used among many servers.

In the event of a hardware failure or a natural disaster, any other server in the network can instantly take the role of the DNS server. There's no backups to restore, no files to copy.

To integrate your DNS server into the LDAP directory, complete the following:

1. Start YaST and su to root.
2. Select Network Services, DNS Server.
3. In the left frame, select Start-Up. The screen in Figure 3.41 is displayed:
   

   Figure 3.41 Configuring LDAP Support.

4. Mark LDAP Support Active; then select Finish.
5. When prompted, enter the password for your Administrator LDAP user account.
6. Wait while the changes are applied.

Your DNS zone information is then saved in the LDAP directory, as shown in Figure 3.42:

Let's practice performing these tasks on your DNS server in Lab Exercise 3.2.