Configuring DNS on SLES 9
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the following requirements for Novell's Certified Linux Engineer (CLE) 9 certification:
- Configure a DNS server using BIND.
On a modern IP-based network, users take for granted the fact that they can access local network and Internet resources using easy-to-remember domain names instead of IP addresses. I doubt that a single work day goes by that the typical employee doesn't access some website with a URL that uses a domain name, such as http://www.novell.com. As a Linux system administrator, it's your job to know how to provide users with this functionality.
In this chapter, we're going to do just that. We're going to discuss how to implement domain name service (DNS) on your SLES 9 server.
Let's begin!
The Need for DNS
TEST OBJECTIVE COVERED:
- Configure a DNS server using BIND.
Let's visit an imaginary world; a world without DNS. In this world, users can't use the domain names that we are so used to in our modern lexicon.
Your coworker comes to you and says, "Hey, I found a great website for searching the Internet. Just go to 66.102.7.99." Later, you're watching television and you see an advertisement for an online auction website. The slogan for it goes, "I found just what I needed on 66.135.192.124." It's not very catchy, is it?
Fortunately, in the real world, this isn't a problem. We have DNS. As you probably know, DNS is a network service that allows you to map easy-to-remember host and domain names to IP addresses. Before going any farther, let's review a little bit of the history behind DNS.
Life Before DNS
Believe it or not, DNS hasn't always been with us. In the early days of IP-based computer networks, we had two choices:
- Don't use any kind of name resolution.
- Use the hosts file for name resolution.
As you can guess, the first option wasn't terribly popular. If you're a tech-head (and you probably are if you're pursing the CLE 9 certification), you probably could handle using IP addresses instead of hostnames. It wouldn't be easy, but as soon as you memorized a list of frequently used IP address, you could probably get by.
However, this option would be a support nightmare for your typical network users. Could you imagine how many help-desk calls you would get? For whatever reason, humans have a tough time memorizing long numbers. Our brains tend to just jumble up the numbers.
Imagine what would happen if you sent out the memo in Figure 3.1 to your users.
)
Figure 3.1 The World without name resolution.
I can tell from personal experience that your phone will be ringing off the hook. It's just hard for the typical user to comprehend IP addresses.
Because of this, most system administrators used the second option. Instead of requiring users to memorize IP addresses, they instead used the hosts file to provide a simple form of name resolution.
Most operating systems are designed to use some type of hosts file to map hostnames to IP addresses. A sample hosts file from a Linux system is shown in Figure 3.2:
)
Figure 3.2 A sample Linux hosts file.
On a Linux system, this file resides in /etc. Even the latest Windows operating system still has a hosts file available should it be needed. On a Windows XP system, this file resides in the \windows\system32\drivers\etc directory. A sample hosts file from a Windows system is shown in Figure 3.3:
)
Figure 3.3 A sample Windows hosts file.
Notice in Figures 3.2 and 3.3 that each mapping resides on a single line. The syntax is as follows:
IP_address Host_Name Alias
The IP_address parameter is the IP address of the host you want the hostname mapped to. The Host_Name parameter is the alphanumeric hostname you want mapped to the IP address. The Alias parameter is an optional, secondary hostname you want mapped to the same IP address. It's usually shorter than the hostname.
For example, in the preceding figures, the IP address 192.168.1.47 is mapped to the hostname of fs1.cle9.com. Notice that you're not limited to a hostname only for this parameter. You can also use a fully qualified domain name (FQDN).
The Alias parameter is usually a shorter, easy-to-remember name that you want additionally mapped to the specified IP address. In Figures 3.2 and 3.3, we've also mapped the alias of fs1 to 192.168.1.47 in addition to the FQDN. With this hosts file, we can use either fs1.cle9.com or fs1 to access the host configured with the IP address 192.168.1.47.
Sounds pretty easy, huh? Can you still use hosts files to provide name resolution services on your network? Absolutely. This can be configured on your Linux host using the /etc/host.conf file. The order directive in this file specifies whether you are going to use hosts files and, if so, where to look first.
Do system administrators still use hosts files to provide name resolution services? Very rarely. Although editing the hosts file to define mappings is relatively uncomplicated, using hosts files has two major shortcomings.
First, maintaining hosts files on a small network is somewhat feasible. However, if a network gets very large at all, it becomes an impossible task. Suppose, for example, that you are responsible for managing an IP-based network that has 800 hosts on it. If you were to add a server to the network, you would have to manually update 800 hosts files with the new server's IP address and hostname. Unless you're the type of person who lives for tedium, this really isn't feasible, especially if your network is a growing, dynamic network. However, in the "old days," this was the only real name resolution option available and system administrators did the best they could.
The second problem with hosts files relates to Internet access. If an organization allowed very few users to access the Internet from their desktops, this wasn't an issue. You could maintain your users' hosts files (very tediously) with mappings of IP address to hostnames for systems on your network.
However, imagine the problem you would face if you wanted to implement hosts files to allow users to access hosts on the Internet. Basically, each user with Internet access would need a hosts file that contained mappings for all Internet hosts (or at least the ones you want them to be able to access). Yikes! This task sounds almost impossible.
To make this possible, the registration of Internet host names was centrally managed by the InterNIC (Network Information Center) at Stanford. This organization kept a master hosts file. Early system administrators would have to download new versions of this file regularly. They would then have to add mappings to the file for hosts on their own network. When they were done, they would copy the file around to all of the systems on their network.
Essentially, with hosts files, the smallest change required a great deal of manual effort to implement and distribute. That's where DNS comes into play.
How DNS Works
DNS makes name resolution on your IP network a much easier administrative task. The main weakness with hosts files was that name resolution was decentralized. Each computer system had its own hosts file. Any change in the network required each hosts file on every system to be changed.
DNS rectifies all that. Where the hosts file was a decentralized name resolution system, DNS is a centralized name resolution system.
Recall that when we installed and configured our SLES 9 server in the previous chapter, we configured the system with the IP address of a DNS server, as shown in Figure 3.4:
)
Figure 3.4 Configuring the IP address of the DNS resolver.
Instead of relying on the hosts file, the system will instead send requests for resolving hostnames into IP addresses (and vice versa) to the DNS server.
This strategy provides distinct advantages over hosts files. Key among these is that name resolution services are centralized in the network. Recall the example we looked at earlier. You have 800 computer systems in your network and you've just added a new server. You need to update your name resolution system with the new hostname and IP address of the server.
We related that when using hosts files, you would have to make 800 manual updates; every hosts file would have to be edited or copied. With DNS, however, you would have to make a single update to the DNS server. As soon as you add the mapping, the hostname can immediately be resolved for any host on the network. That's a lot of time saved on your part.
Let's review how DNS works.
THE DNS NAMESPACE
One of the key differences between DNS and hosts files is that DNS employs a hierarchy of domains and zones. This hierarchy is called the DNS namespace.
By way of comparison, refer back to Figure 3.2. The hosts file is flat. What does the term "flat" mean? It means there is no structure to the file that would allow records to be nested within units of organization. All records in a hosts file reside at the same level.
For example, you could enter the following list of hostnames and IP addresses in a single hosts file:
192.168.1.47 fs1.cle9.com fs1 130.57.4.27 www.novell.com novell 192.168.1.1 gateway.cle9.com gateway 195.135.220.3 www.suse.com suse
Notice that the mappings aren't arranged in any particular fashion. They don't appear in any particular order nor are similar records grouped together. For a small hosts file, this isn't a problem. However, imagine how messy a hosts file could become if there were hundreds or even thousands of different records in the hosts file.
DNS, on the other hand, organizes hosts into a highly structured domain structure. Think of this structure as an inverted tree, as depicted in Figure 3.5.
)
Figure 3.5 The DNS domain hierarchy.
To understand how DNS domains organize hostnames, let's analyze a sample domain name: www.novell.com.
At the top of the DNS hierarchy is the root domain. It's denoted by a simple period, as shown in Figure 3.5. This will be the right-most domain in any DNS domain name.
Notice the period at the end of www.novell.com. This period represents the root domain. Now, as you visit websites, you probably don't include the trailing period in the URL. Most people don't. However, you should always remember that a properly written FQDN name ends with a trailing period denoting the root domain.
As an experiment, try opening a web browser and navigating to your favorite websites using a trailing period after the domain name. You'll find that it works! In Figure 3.6, you see Novell's website opened using just this type of URL:
)
Figure 3.6 Using a trailing period in a URL.
The root domain contains a number of top-level domains (TLDs). If you've visited websites on the Internet, you're probably already familiar with these top-level domain names, which include
- com— Contains commercial organizations.
- edu— Contains educational organizations.
- org— Contains nonprofit organizations.
- gov— Contains United States government organizations.
This list isn't all-inclusive. In recent years, new top-level domains have been added, including tv, biz, and info. In addition, top-level domains exist for specific countries. For example, the top-level domain for Australia is au. The top-level domain for Spain is es.
In our www.novell.com. example, the next domain after the root domain is com.
Within the top-level domains reside thousands of subdomains or zones. Zones are specific to an organization.
Zones themselves can contain either subzones or specific hosts. In our example, the zone comes immediately to the left of the top-level domain; in this case, novell.
In Figure 3.5, you'll notice that the novell zone contains two specific records; one for www and one for ftp. These records contain mappings, just like in a hosts file, that map a hostname to an IP address. In our example, www specifies a specific host within the novell zone.
With this in mind, let's look at how the name resolution process works with DNS.
RESOLVING HOSTNAMES WITH DNS
Recall that with a hosts file, the system needing to resolve a hostname parses the locally stored file until it finds a match and reads the appropriate IP address. The process is quite a bit more complex when using DNS to resolve hostnames. However, it's this complexity that makes DNS a much more manageable system than using hosts files.
The DNS name resolution system uses DNS servers. Instead of reading a local file, a computer system that needs to resolve a hostname into an IP address sends a resolution request to the DNS server it's been configured to use; as shown in Figure 3.4.
What happens after that gets a little more complex. The process is depicted in Figure 3.7:
)
Figure 3.7 The Name resolution process.
Here's how it works:
- The system needing to resolve a hostname to an IP address sends a request to the DNS server it's been configured to use on IP port 53. If the DNS server is authoritative for the zone where the hostname being requested resides, it responds with the IP address. If not, the process continues to step 2.
- The DNS server sends a request to a root-level DNS server. There are 13 root-level DNS servers on the Internet. When you install your own DNS server, it's automatically configured with the IP addresses of these servers, as shown in Figure 3.8. These root-level servers are configured with records that resolve to authoritative DNS servers for each top-level domain.
Figure 3.8 Root-level DNS servers.
- The root-level DNS server contacted responds to your DNS server with the IP address of a DNS server that's authoritative for the top-level domain of the FQDN in question.
- Your DNS server sends a resolution query for the FQDN to the top-level domain authoritative DNS server.
- The top-level domain DNS server responds to your DNS server with the IP address of the DNS server that's authoritative for the DNS zone of the FQDN that you need to resolve.
- Your DNS server sends a resolution request to the DNS server that's authoritative for the zone where the FQDN resides.
- The authoritative DNS server for the FQDN responds to your DNS server with the respective IP address.
- Your DNS server responds to the system that originated the request with the IP address.
)
At this point, something very important happens. When your DNS server resolves a hostname for which it is not authoritative, it saves that address in its name cache. In the future, if it receives a request to resolve the same hostname again, it will pull the IP address out of its cache and respond to the requesting system directly instead of going through the entire resolution process again. This saves both time and network traffic, especially on a heavily utilized DNS server.
With this in mind, you need to know a couple of things about the DNS server's name cache. First, the cache resides in the server's memory; it's not saved in a file. This is significant because, many times, system administrators want to manipulate their DNS server's cache, such as manually editing it to add hosts or to copy it to another DNS server. Simply put, you can't do it.
This brings to bear the second point: The name cache on a given DNS server isn't persistent. Because it resides in memory only, it's lost if you stop the DNS service or if you reboot the server system that's running the service. Many administrators want to save the cache to a file and then reload it when the service comes back up. The idea is a good one; rather than wait for the name cache to be rebuilt, they want to force the service to use an existing cache, saving time and reducing network traffic. Unfortunately, it can't be done.
Before we go any further, we need to discuss the two roles that a DNS server can take: master or slave.
MASTER AND SLAVE DNS SERVERS
One of the problems with current DNS implementations is fault tolerance. If you have your DNS database hosted on a particular server and it goes down, name resolution for your network is gone.
To provide a degree of redundancy, BIND allows you to configure master and slave DNS servers. A master server is a DNS server that hosts zone files. Any changes made to the zone are made to the zone files on the master server.
A slave DNS server, on the other hand, is configured to get its zone data from a master DNS server. Every so often, the slave server contacts the master server and downloads zone data. This transfer is called a zone transfer.
By configuring your DNS implementation with master and slave servers, you provide a degree of fault tolerance. That's because a slave DNS server can resolve hostnames just like a master DNS server. Your workstation doesn't know the difference between the two.
In fact, you'll notice that most organizations and ISPs provide two or more DNS server addresses for client workstations. One is usually a master server, the others slave servers. If your master server were to go down, workstations can still use the slave server for name resolution.
In addition to knowing about master and slave servers, you also need to understand that two types of zones can be hosted by a DNS server. Let's look at those next.
FORWARD- AND REVERSE-LOOKUP ZONES
DNS servers can perform two types of lookups performing name-resolution tasks. The first type is called a forward lookup. A forward lookup is the type of lookup we've been focusing on in the beginning pages of this chapter. When performing a forward lookup, the client system sends a request to the DNS server asking it to resolve a hostname into an IP address.
However, this process also works in reverse. These are called reverse lookups. During a reverse lookup, the client system sends a request to the DNS server that asks it to resolve an IP address into a hostname.
At first glance, you may conclude that the DNS server can use the same zone data to perform both types of lookup. After all, it's just a matter of direction, right?
Well, it doesn't work that way. If you want a DNS server to provide forward and reverse lookups, you have to create two zones: a forward zone and a reverse zone. Both zones contain the same data; it's just formatted in a slightly different fashion. We'll look at the difference later in this chapter.
Now that you know how DNS works conceptually, you need to learn how to implement it on your SLES 9 server.