The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service resolves queries for these names into IP addresses for the purpose of locating computer services and devices worldwide. By providing a worldwide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.

An often-used analogy to explain the Domain Name System is that it serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). Unlike a phone book, DNS can be quickly updated and these updates are distributed, allowing a service's location on the network to change without affecting the end users, who continue to use the same hostname. Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates the services.

The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed and fault tolerant and has helped avoid the need for a single central register to be continually consulted and updated. Additionally, the responsibility for maintaining and updating the master record for the domains is spread among many domain name registrars, who compete for the end-user's, domain-owner's, business. Domains can be moved from registrar to registrar at any time.

The Domain Name System also specifies the technical functionality of this database service. It defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite.

The Internet maintains two principal namespaces, the domain name hierarchy and the Internet Protocol (IP) address spaces. The Domain Name System maintains the domain name hierarchy and provides translation services between it and the address spaces. Internet name servers and a communication protocol implement the Domain Name System. A DNS name server is a server that stores the DNS records for a domain name, such as address (A) records, name server (NS) records, and mail exchanger (MX) records (see also list of DNS record types); a DNS name server responds with answers to queries against its database.

Domain Name System (DNS) converts the name of a Web site (www.linuxhomenetworking.com) to an IP address (65.115.71.34). This step is important, because the IP address of a Web site's server, not the Web site's name, is used in routing traffic over the Internet.

Introduction to DNS

DNS Domains

Everyone in the world has a first name and a last, or family, name. The same thing is true in the DNS world: A family of Web sites can be loosely described a domain. For example, the domain linuxhomenetworking.com has a number of children, such as www.linuxhomenetworking.com and mail.linuxhomenetworking.com for the Web and mail servers, respectively.

BIND

BIND is an acronym for the Berkeley Internet Name Domain project, which is a group that maintains the DNS-related software suite that runs under Linux. The most well known program in BIND is named, the daemon that responds to DNS queries from remote machines.

DNS Clients

A DNS client doesn't store DNS information; it must always refer to a DNS server to get it. The only DNS configuration file for a DNS client is the /etc/resolv.conf file, which defines the IP address of the DNS server it should use. You shouldn't need to configure any other files. You'll become well acquainted with the /etc/resolv.conf file soon.

Authoritative DNS Servers

Authoritative servers provide the definitive information for your DNS domain, such as the names of servers and Web sites in it. They are the last word in information related to your domain.

How DNS Servers Find Out Your Site Information

There are 13 root authoritative DNS servers (super duper authorities) that all DNS servers query first. These root servers know all the authoritative DNS servers for all the main domains - .com, .net, and the rest. This layer of servers keep track of all the DNS servers that Web site systems administrators have assigned for their sub domains.

For example, when you register your domain my-site.com, you are actually inserting a record on the .com DNS servers that point to the authoritative DNS servers you assigned for your domain. (More on how to register your site later.).

When To Use A DNS Caching Name Server

Most servers don’t ask authoritative servers for DNS directly, they usually ask a caching DNS server to do it on their behalf. These servers, through a process called recursion, sequentially query the authoritative servers at the root, main domain and sub domain levels to get eventually get the specific information requested. The most frequently requested information is then stored (or cached) to reduce the lookup overhead of subsequent queries.

If you want to advertise your Web site www.my-site.com to the rest of the world, then a regular DNS server is what you require. Setting up a caching DNS server is fairly straightforward and works whether or not your ISP provides you with a static or dynamic Internet IP address.

After you set up your caching DNS server, you must configure each of your home network PCs to use it as their DNS server. If your home PCs get their IP addresses using DHCP, then you have to configure your DHCP server to make it aware of the IP address of your new DNS server, so that the DHCP server can advertise the DNS server to its PC clients. Off-the-shelf router/firewall appliances used in most home networks usually can act as both the caching DNS and DHCP server, rendering a separate DNS server is unnecessary.

When To Use A Static DNS Server

If your ISP provides you with a fixed or static IP address, and you want to host your own Web site, then a regular authoritative DNS server would be the way to go. A caching DNS name server is used as a reference only, regular name servers are used as the authoritative source of information for your Web site's domain.

Note: Regular name servers are also caching name servers by default.

When To Use A Dynamic DNS Server

If your ISP provides your router/firewall with its Internet IP address using DHCP then you must consider dynamic DNS 

How To Get Your Own Domain

Whether or not you use static or dynamic DNS, you need to register a domain.

Dynamic DNS providers frequently offer you a subdomain of their own site, such as my-site.dnsprovider.com, in which you register your domain on their site.

If you choose to create your very own domain, such as my-site.com, you have to register with a company specializing in static DNS registration and then point your registration record to the intended authoritative DNS for your domain. Popular domain registrars include VeriSign, Register Free, and Yahoo.

If you want to use a dynamic DNS provider for your own domain, then you have to point your registration record to the DNS servers of your dynamic DNS provider.

Basic DNS Testing of DNS Resolution

As you know, DNS resolution maps a fully qualified domain name (FQDN), such as www.linuxhomenetworking.com, to an IP address. This is also known as a forward lookup. The reverse is also true: By performing a reverse lookup, DNS can determining the fully qualified domain name associated with an IP address.

Many different Web sites can map to a single IP address, but the reverse isn't true; an IP address can map to only one FQDN. This means that forward and reverse entries frequently don't match. The reverse DNS entries are usually the responsibility of the ISP hosting your site, so it is quite common for the reverse lookup to resolve to the ISP's domain. This isn't an important factor for most small sites, but some e-commerce applications require matching entries to operate correctly. You may have to ask your ISP to make a custom DNS change to correct this.

There are a number of commands you can use do these lookups. Linux uses the host command, for example, but Windows uses nslookup.

The Host Command

The host command accepts arguments that are either the fully qualified domain name or the IP address of the server when providing results. To perform a forward lookup, use the syntax:

[root@bigboy tmp]# host www.linuxhomenetworking.com
www.linuxhomenetworking.com has address 65.115.71.34
[root@bigboy tmp]#

To perform a reverse lookup

[root@bigboy tmp]# host 65.115.71.34
34.71.115.65.in-addr.arpa domain name pointer 65-115-71-34.myisp.net.
[root@bigboy tmp]#

As you can see, the forward and reverse entries don't match. The reverse entry matches the entry of the ISP.

The nslookup Command

The nslookup command provides the same results on Windows PCs. To perform forward lookup, use.

C:\> nslookup www.linuxhomenetworking.com
Server:  192-168-1-200.my-site.com
Address:  192.168.1.200

Non-authoritative answer:
Name:    www.linuxhomenetworking.com
Address:  65.115.71.34

C:\>

To perform a reverse lookup

C:\> nslookup 65.115.71.34
Server:  192-168-1-200.my-site.com
Address:  192.168.1.200

Name:    65-115-71-34.my-isp.com
Address:  65.115.71.34

C:\>

Downloading and Installing the BIND Packages

Most RedHat and Fedora Linux software products are available in a package format. When searching for the file, remember that the BIND package's filename usually starts with the word “bind” followed by a version number, as in bind-9.2.2.P3-9.i386.rpm. 

Note: Unless otherwise stated, the sample configurations covered in this article will be for Redhat / Fedora distributions. If you use Debian / Ubuntu, don’t worry, there will be annotations to make you aware of the differences.

Managing the BIND Server

Managing BIND's named daemon is easy to do, but the procedure differs between Linux distributions. Here are some things to keep in mind.

1. Firstly, different Linux distributions use different daemon management systems. Each system has its own set of commands to do similar operations. The most commonly used daemon management systems are SysV and Systemd.
2. Secondly, the daemon name needs to be known. In this case the name of the daemon is named.

Armed with this information you can know how to:

1. Start your daemons automatically on booting
2. Stop, start and restart them later on during troubleshooting or when a configuration file change needs to be applied.

Remember to configure your daemon to start automatically upon your next reboot.

The /etc/resolv.conf File

DNS clients (servers not running BIND) use the /etc/resolv.conf file to determine both the location of their DNS server and the domains to which they belong. The file generally has two columns; the first contains a keyword, and the second contains the desired values separated by commas. See Table 18.1 for a list of keywords.

Table 18.1 Keywords In /etc/resolv.conf

Take a look at a sample configuration in which the client server's main domain is my-site.com, but it also is a member of domains my-site.net and my-site.org, which should be searched for shorthand references to other servers. Two name servers, 192.168.1.100 and 192.168.1.102, provide DNS name resolution:

search my-site.com my-site.net my-site.org
nameserver 192.168.1.100
nameserver 192.168.1.102

The first domain listed after the search directive must be the home domain of your network, in this case my-site.com. Placing a domain and search entry in the /etc/resolv.conf is redundant, therefore.

Important File Locations

The locations of the BIND configuration files vary by Linux distribution, as you will soon see.

RedHat / Fedora

RedHat / Fedora BIND normally runs as the named process owned by the unprivileged named user.

Sometimes BIND is also installed using Linux's chroot feature to not only run named as user named, but also to limit the files named can see. When installed, named is fooled into thinking that the directory /var/named/chrootis actually the root or /directory. Therefore, named files normally found in the /etcdirectory are found in /var/named/chroot/etcdirectory instead, and those you'd expect to find in /var/named are actually located in /var/named/chroot/var/named.

The advantage of the chroot feature is that if a hacker enters your system via a BIND exploit, the hacker's access to the rest of your system is isolated to the files under the chrootdirectory and nothing else. This type of security is also known as a chroot jail.

You can determine whether you have the chroot add-on RPM by using this command, which returns the name of the RPM.

[root@bigboy tmp]# rpm -q bind-chroot
bind-chroot-9.2.3-13
[root@bigboy tmp]#

There can be confusion with the locations: Regular BIND installs its files in the normal locations, and the chroot BIND add-on RPM installs its own versions in their chroot locations. Unfortunately, the chroot versions of some of the files are empty. Before starting Fedora BIND, copy the configuration files to their chroot locations:

[root@bigboy tmp]# cp -f /etc/named.conf /var/named/chroot/etc/
[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/

Before you go to the next step of configuring a regular name server, it is important to understand exactly where the files are located. Table 18.2 provides a map.

Table 18.2 Differences In Fedora And Redhat DNS File Locations

Note: Fedora Core installs BIND chroot by default. RedHat 9 and earlier don't.

Debian / Ubuntu

With Debian / Ubuntu, all the configuration files, the primary named.conffile and all the DNS zone files reside in the /etc/binddirectory.

Unlike in Redhat / Fedora, references to other files within these configuration files should include the full path. The named daemon won't automatically assume they are located in the /etc/binddirectory.

Configuring Your Nameserver

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

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]# systemctl restart named.service

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.