Configuring Your Nameserver - Linux DNS

For the purposes of this tutorial, assume your ISP assigned you the subnet 97.158.253.24 with a subnet mask of 255.255.255.248 (/29).

Configuring resolv.conf

You'll have to make your DNS server refer to itself for all DNS queries by configuring the /etc/resolv.conf file to reference localhost only.

nameserver 127.0.0.1

Creating a named.conf Base Configuration

The /etc/named.conf file contains the main DNS configuration and tells BIND where to find the configuration, or zone files for each domain you own. This file usually has two zone areas:

• Forward zone file definitions list files to map domains to IP addresses.
• Reverse zone file definitions list files to map IP addresses to domains.

Some versions of BIND will come with a /etc/amed.conf file configured to work as a caching nameserver which can be converted to an authoritative nameserver by adding the correct references to your zone files. Please proceed to the next section if this is the case with your version of BIND.

In other cases the named.conf configuration file may be hard to find. Some versions of Linux install BIND as a default caching nameserver using a file names /etc/named.caching-nameserver.conf for its configuration. In such cases BIND becomes an authoritative nameserver when a correctly configured /etc/named.conf file is created.

Fortunately BIND comes with samples of all the primary files you need. Table 18.3 explains their names and purpose in more detail.

Table 18.3 The Primary BIND Configuration Files

File	Description
/etc/named.conf	The main configuration file that lists the location of all your domain's zone files
/etc/named.rfc1912.zones	Base configuration file for a caching name server.
/var/named/named.ca	A list of the 13 root authoritative DNS servers.

The first task is to make sure your DNS server will listening of requests on all the required network interfaces. The options section of named.conf may be configured to listen exclusively on its internal hidden localhost interface with an IP address of 127.0.0.1 as we see in this example.

# File: /etc/named.conf

options {
      listen-on port 53 { 127.0.0.1; };
};

If other devices are going to rely on your server for queries, then you’ll need to either change this or add a selected number of IP addresses on your server. In this example, we allow queries on any interface.

listen-on port 53 { any; };

In this example, we allow queries on localhost and address 192.168.1.100.

listen-on port 53 { 127.0.0.1; 192.168.1.100; };

Note: Always make sure localhost, 127.0.0.1 is included.

Though it is not required, it is a good practice to configure your DNS server's named.conf file to support BIND views. This will be discussed next.

Configuring BIND Views in named.conf

Our sample scenario assumes that DNS queries will be coming from the Internet and that the zone files will return information related to the external 97.158.253.26 address of the Web server. What do the PCs on your home network need to see? They need to see DNS references to the real IP address of the Web server, 192.168.1.100, because NAT won’t work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NAT IP address of your Web server. Don’t worry. BIND figures this out using its views feature which allows you to use predefined zone files for queries from certain subnets. This means it’s possible to use one set of zone files for queries from the Internet and another set for queries from your home network. Here’s a summary of how it’s done:

1. If your DNS server is also acting as a caching DNS server, then you'll also need a view for localhost to use. We'll use a view called localhost_resolver for this.

2. Place your zone statements in the /etc/named.conf file in one of two other view sections. The first section is called internal and lists the zone files to be used by your internal network. The second view called external lists the zone files to be used for Internet users.

For example; you could have a reference to a zone file called my-site.zone for lookups related to the 97.158.253.X network which Internet users would see. This /etc/named.conf entry would be inserted in the external section. You could also have a file called my-site-home.zone for lookups by home users on the 192.168.1.0 network. This entry would be inserted in the internal section. Creating the my-site-home.zone file is fairly easy: Copy it from the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X.

3. You must also tell the DNS server which addresses you feel are internal and external. To do this, you must first define the internal and external networks with access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs can save you time:

• localhost: Refers to the DNS server itself
• localnets: Refers to all the networks to which the DNS server is directly connected
• any: which is self explanatory.

Let's examine BIND views more carefully using a number of sample configuration snippets from the /etc/named.conf file I use for my home network. All the statements below were inserted after the options and controls sections in the file. I have selected generic names internal, for views given to trusted hosts (home, non-internet or corporate users), and external for the views given to Internet clients, but they can be named whatever you wish.

First let's talk about how we should refer to the zone files in each view.

Forward Zone File References in named.conf

Let’s describe how we point to forward zone files in a typical named.conf file.

In this example the zone file is named my-site.zone, and, although not explicitly stated, the file my-site.zone should be located in the default directory of /var/named/chroot/var/named in a chroot configuration or in /var/named in a regular one. With Debian / Ubuntu, references to the full file path will have to be used. Use the code:

zone “my-web-site.org” {

  type master;
  notify no;
  allow-query { any; };
  file “my-site.zone”;

};

In addition, you can insert more entries in the named.conf file to reference other Web domains you host. Here is an example for another-site.com using a zone file named another-site.zone.

zone “another-site.com” {

  type master;
  notify no;
  allow-query { any; };
  file “another-site.zone”;

};

Note: The allow-query directive defines the networks that are allowed to query your DNS server for information on any zone. For example, to limit queries to only your 192.168.1.0 network, you could modify the directive to:

allow-query { 192.168.1.0/24; };

Reverse Zone File References in named.conf

Here’s how to format entries that refer to zone files used for reverse lookups for your IP addresses.

In most cases, your ISP handles the reverse zone entries for your public IP addresses, but you will have to create reverse zone entries for your SOHO/home environment using the 192.168.1.0/24 address space. This isn’t important for the Windows clients on your network, but some Linux applications require valid forward and reverse entries to operate correctly.

The forward domain lookup process for mysite.com scans the FQDN from right to left to get to get increasingly more specific information about the authoritative servers to use. Reverse lookups operate similarly by scanning an IP address from left to right to get increasingly specific information about an address.

The similarity in both methods is that increasingly specific information is sought, but the noticeable difference is that for forward lookups the scan is from right to left, and for reverse lookups the scan is from left to right. This difference can be seen in the formatting of the zone statement for a reverse zone in /etc/named.conf file where the main in-addr.arpa domain, to which all IP addresses belong, is followed by the first 3 octets of the IP address in reverse order. This order is important to remember or else the configuration will fail. This reverse zone definition for named.conf uses a reverse zone file named 192-168-1.zone for the 192.168.1.0/24 network.

zone “1.168.192.in-addr.arpa” {
  type master;
  notify no;
  allow-query { any; };
  file “192-168-1.zone”;
};

Your patience will soon be rewarded. It's time to talk about the views! Let's go!

The Caching Nameserver localhost_resolver View

The localhost_resolver view is used for your caching DNS server configuration and should look like this:

view "localhost_resolver"
{
/* This view sets up named to be a localhost resolver
* ( caching only nameserver ). If all you want is a
* caching-only nameserver, then you need only define this view:
*/
       match-clients           { localhost; };
       match-destinations      { localhost; };

       // As your caching name server clients will be using this server
       // for DNS lookups to get to sites all over the Web you’ll need to
       // turn on recursion
       recursion yes;

       // All views used by caching nameserver clients must
       // contain the root hints zone. Recursive lookups to DNS domains
       // you don’t own (non-authoritative) starts here.
       zone "." IN {
            type hint;
            file "named.ca";
       };

       /* these are zones that contain definitions for all the localhost
        * names and addresses, as recommended in RFC1912 - these names should
        * ONLY be served to localhost clients:
        */
       include "/etc/named.rfc1912.zones";

       /*
        *  Include zonefiles for internal zones
        */
       include "/var/named/zones/internal/internal_zones.conf";
};

There are some quick facts you should be aware of with your caching name server configuration:

1. If you want your server to be only a caching DNS server, then delete all other views in named.conf and restart the named daemon.

[root@bigboy tmp]# /etc/init.d/named restart

2. Make all the other machines on your network point to the caching DNS server as their primary DNS server.

3. Remember that all DNS queries done on your DNS server appear to come from localhost. If your server is also an authoritative server for your domain, you will have to include a reference to your domain's zone files in this section for the server's own DNS lookups to work. If not, queries from clients defined by the internal and external ACLs will work correctly, but queries for the domain from the server itself will fail. In this example we have included a reference to the internal_zones.conf zone file which we'll visit again soon. This line can be deleted if your server isn't an authoritative server for your domain.

Note: If you have a localhost only view like this, make sure you don't reference localhost in any of your other views as one view will take precedence over the other for queries from your server. This could lead to unpredictable results.

The Internal View

In this example I included an ACL for network 192.168.17.0 /24 called safe-subnet to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the safe-subnet in the match-clients statement in the internal view. Therefore the local network (192.168.1.0 /24), the other trusted network (192.168.17.0), and localhost get DNS data from the zone files in the internal view.

// ACL statement

acl “safe-subnet” { 192.168.17.0/24; };

view “internal” { // What the home network will see

  match-clients      { localnets; localhost; safe-subnet; };
  match-destinations { localnets; localhost; safe-subnet; };

  // As your caching name server clients will be using this server
  // for DNS lookups to get to sites all over the Web you’ll need to
  // turn on recursion
  recursion yes;

  // All views used by caching nameserver clients must
  // contain the root hints zone. Recursive lookups to DNS domains
  // you don’t own (non-authoritative) starts here.
  zone "." IN {
       type hint;
       file "named.ca";
  };

  // These are your "authoritative" internal zones, and would probably
  // also be included in the "localhost_resolver" view above :

  /*
  *  Include zonefiles for internal zones
  */
  include "/var/named/zones/internal/internal_zones.conf";

};

The question you may have on your mind is, "Where are the zone file definitions?". Don't worry, there is an include statement that refers to a file named internal_zones.conf that contains them all as we see here:

// File internal_zones.conf

zone "1.168.192.in-addr.arpa" IN {
  type master;
  file "/var/named/zones/internal/192.168.1.zone";
  allow-update { none; };
};

zone "my-web-site.org" IN {
  type master;
  file "/var/named/zones/internal/my-web-site.org.zone";
  allow-update { none; };
};

I'll discuss how to handle queries from clients outside your trusted networks in the next section where an external view can be used.

The External View

You can also setup an external view that will be used for DNS queries from clients outside your network, such as the Internet. In this case external queries get results from zone files in the /var/named/zones/external directory.

view “external” { // What the Internet will see

  /* This view will contain zones you want to serve only to "external"
   * clients that have addresses that are not on your directly attached
   * LAN interface subnets:
   */

  match-clients      { any; };
  match-destinations { any; };

  // you'd probably want to deny recursion to external clients, so you don't
  // end up providing free DNS service to all takers
  recursion no;

  // These are your "authoritative" external zones, and would probably
  // contain entries for just your web and mail servers:

  zone "253.158.97.in-addr.arpa" IN {
     type master;
     file "/var/named/zones/external/97.158.253.zone";
     allow-update { none; };
  };

  zone "my-web-site.org" IN {
     type master;
     file "/var/named/zones/external/my-web-site.org.zone";
     allow-update { none; };
  };
};

Notice that the reverse zone file gives results for public internet addresses, and of course, the forward zone file should only provide responses with Internet accessible addresses.

Note: In the external view, you may be tempted to use an exclamation mark (!) to eliminate networks used in the internal view like this. Be careful, it is best to use "any;" for your external view as the exclamation mark (!) is not honored with some versions of BIND in views named "external".

; !!! CAUTION !!!

match-clients      { !localnets; !localhost; !safe-subnet; };
match-destinations { !localnets; !localhost; !safe-subnet; };

The views listed here are purely to illustrate their use. The sample home network we have been using doesn’t need to have the ACL statement at all as the built in ACLs localnets and localhost are sufficient. The sample network won’t need the safe-subnet section in the match-clients line either as there is only one subnet in the configuration.

Views are also not just for NAT. If you run an Internet data center, you can set up your DNS server to act as a caching server to servers on all the Internet networks you own and no one else, and then provide authoritative responses to your customers' domains to everyone. Views can be very useful.