Home > Articles

Configuring DNS on SLES 9

This chapter is from the book

This chapter covers the following requirements for Novell's Certified Linux Engineer (CLE) 9 certification:

  1. 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


  1. 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" 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" 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 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 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

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.


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:    fs1.cle9.com        fs1    www.novell.com        novell    gateway.cle9.com    gateway    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.


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:

  1. 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.
  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.

  3. 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.
  4. Your DNS server sends a resolution query for the FQDN to the top-level domain authoritative DNS server.
  5. 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.
  6. Your DNS server sends a resolution request to the DNS server that's authoritative for the zone where the FQDN resides.
  7. The authoritative DNS server for the FQDN responds to your DNS server with the respective IP address.
  8. 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.


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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020