Home > Articles

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:

03fig34.gif

Figure 3.34 A sample DNS hierarchy for a college.

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:
    03fig35.gif

    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.

03fig36.gif

Figure 3.36 Running named in a chroot jail.

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.

03fig37.jpg

Figure 3.37 Running named using the named User Account.

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:

03fig38.gif

Figure 3.38 Restricting user access.

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:

03fig39.gif

Figure 3.39 Restricting zone transfers.

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:
    03fig40.jpg

    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:
    03fig41.jpg

    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:

03fig42.jpg

Figure 3.42 DNS Zones in LDAP.

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

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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