Book: LPI Linux Certification in a Nutshell Section: Chapter 20. Networking Services (Topic 1.13)
### 20.5 Objective 5: Set Up and Configure Basic DNS Services The Domain Name Service (DNS) is the distributed database of name-to-IP-address translations. Technically, it isn't necessary to use host and domain names such as www.lpi.org, because it's the actual IP address that the computer requires to establish communications. DNS was created to allow the use of more convenient global domain names instead. For example, when a user enters a DNS name as part of a URL in a browser, the name portion is sent to a DNS server to be resolved into an IP address. Once the address is found, it is used to rewrite the URL and directly fetch the web page.
## On the Exam You must be familiar with the concept of name resolution on the Internet using DNS.
The server daemon that implements DNS is named, the name daemon , which is part of the Berkeley Internet Name Daemon package (BIND). It is named's job to respond to requests from the resolver and return an IP address. #### 20.5.1 The resolver The code that resolves names to IP addresses using DNS for client programs is implemented in system libraries collectively called the resolver. The resolver uses one of several means to determine an IP address from a hostname or domain name: Static local files The local file /etc/hosts can contain name-to-address mapping for a few systems on a network. However, for large enterprises, using static local files to manage IP address resolution is problematic due to the frequent changes required in the data. Updating all of the client systems would be impractical. This resolution method is sometimes referred to as the files method. Network Information Service (NIS) Some private networks use a shared information service that can include address resolution. This is NIS, or a later version of it called NIS+, and is referred to as the `nis` method of resolution. Both services are beyond the scope of the LPIC Level 1 exams. Domain Name Service (DNS) Because addresses and domains on the public Internet change frequently and are so numerous, static local files can't handle resolution far outside the enterprise. As already mentioned, DNS is a distributed database. That is, small portions of the DNS are managed by local authorities that are responsible only for their particular slice of the system. As you'd expect, using DNS for name resolution is called the `dns` method. In most cases, /etc/hosts will be used for name resolution of the local host and perhaps a few other nearby systems. DNS, perhaps together with NIS in enterprise environments, will handle everything else. /etc/hosts and the other files used to configure the resolver are described in Section 19.2 but here's a quick recap: /etc/hosts This file lists statically defined name-to-address translations. /etc/nsswitch.conf (or /etc/host.conf on older Linux systems) The "name service switch" file (nsswitch.conf ) defines the order of name server methods to be used in succession by the resolver (it can also control other things such as passwords, but those don't apply here). Typically, this single entry is used to control name resolution:
    hosts:  files dns
This entry instructs the resolver to resolve names using /etc/hosts first, and if a match isn't found, to make a DNS query. /etc/resolv.conf This file lists the IP addresses of name servers:
    nameserver 127.0.0.1
    nameserver 192.168.1.5
    nameserver 192.168.250.2
## On the Exam Be sure that you understand how /etc/nsswitch controls the resolution order, that /etc/resolv.conf identifies DNS servers by address, and that /etc/hosts is for local, statically resolved addresses. Also remember that older versions of Linux used /etc/host.conf to configure the resolution order instead of /etc/nsswitch.conf.
When the resolver determines that a DNS query is required, it sends a request containing a domain name to one of the DNS servers listed in /etc/resolv.conf. The DNS server uses its own records to find the domain or may resort to escalating to other DNS servers if the information isn't readily available. When a result is found by the DNS servers, the IP address corresponding to the requested name is returned to the originating client. ##### 20.5.1.1 Domain registration Domain names are assigned through a registration process with one of the domain name registrars available on the Internet (http://www.internic.net/regist.html). Originally, a single authority managed domain names. As commercial uses for domain names spread, additional entities sought the ability to charge for the service of domain registration, and today there are a number of qualified registrars (a search for "domain registrar" on one of the popular search engines will yield a daunting list). Once a domain name is registered, it is listed in a worldwide database along with contact information for the owners or their agents. The name servers that contain DNS information for the domain can go along with this record. Most registrants offer a domain name search service, so you can test desired domain names for availability. If the domain name you're seeking is available, you can provide payment information to a registrant and purchase rights to use the name, usually for one or two years. ##### 20.5.1.2 Using named as a local caching-only name server named is often configured to serve DNS requests even when it does not have local information for a domain. Instead, it is used for its caching ability. When a client program requests an address resolution from the local named , the daemon first checks its local cache. If it doesn't find the domain there, it goes to other DNS servers as usual. If the cache does contain the domain, it is returned immediately to the client from the cache, which speeds the resolution process. Some Linux distributions come with a caching-only named configuration pre-installed. If this isn't the case for you, simply follow the brief instructions in section 3 of the DNS HOWTO available from http://www.linuxdoc.org/ (or in your /usr/doc/HOWTO directory). Part of the configuration includes setting your local system as the default DNS server in /etc/resolv.conf :
    nameserver 127.0.0.1
You can test the configuration using the nslookup utility:
    # nslookup
    Default Server:  localhost
    Address:  127.0.0.1

    > lpi.org
    Server:  localhost
    Address:  127.0.0.1

    Name:    lpi.org
    Address:  209.167.177.93

    > lpi.org
    Server:  localhost
    Address:  127.0.0.1

    Non-authoritative answer:
    Name:    lpi.org
    Address:  209.167.177.93

    > exit
In this example, nslookup attaches to the default server `localhost` (`127.0.0.1`). In the first query for `lpi.org`, the local named must find the address from external DNS servers. However, the result is found in the cache on the second try, as indicated by the `Non-authoritative answer` response. If this behavior isn't seen, there may be a problem with the named configuration in /etc/named.conf. Some debugging information can be found in /var/log/messages. For example, the highlighted line in this short excerpt shows an error in the configuration file:
    smp named[216]: starting.  named
    smp named[216]: cache zone "" (IN) loaded (serial 0)
    smp named[216]: Zone "0.0.127.in-addr.arpa"
      (file named.local): No default TTL
      set using SOA minimum instead
    smp named[216]: master zone "0.0.127.in-addr.arpa"
      (IN) loaded (serial 1997022700)
    smp named[216]: /etc/named.conf:18: can't redefine
    channel 'default_syslog'
    smp named[216]: listening on [127.0.0.1].53 (lo)
    smp named[216]: listening on [192.168.1.30].53 (eth0)
    smp named[216]: listening on [172.16.132.1].53 (vmnet1)
    smp named[216]: Forwarding source address is [0.0.0.0].1855
    smp named[216]: Ready to answer queries.
Note that configuration of a caching-only name server is beyond the scope of the LPIC Level 1 exams but is a useful exercise in understanding the configuration of named. ##### 20.5.1.3 DNS query utilities A few tools exist to verify the operation of DNS name resolution. Here's a brief synopsis of nslookup and host, both specifically mentioned in this Objective. The host utility does not offer interactive mode but uses a syntax similar to nslookup.
nslookup |
#### Syntax
    nslookup host [dnsserver]
#### Description Look up host, optionally specifying a particular dnsserver. nslookup can be used in either interactive or noninteractive modes. If host is provided on the command line, noninteractive mode is used. In interactive mode, a number of commands are available to control nslookup (the ls command to nslookup is used in the example). See the manpage for more details. #### Noninteractive example In this example, nslookup provides immediate results because host, in this case `oreillynet.com`, is provided on the command line:
    # nslookup oreillynet.com 192.168.1.2
    Server:  ns1.mydomain.com
    Address:  192.168.1.2

    Non-authoritative answer:
    Name:    oreillynet.com
    Address:  208.201.239.36
#### Interactive example Here, nslookup is used interactively with DNS server `192.168.1.2` to find records from `yourdomain.com` :
    # nslookup
    Default Server:  localhost
    Address:  127.0.0.1

    > server 192.168.1.2
    Default Server:  ns1.mydomain.com
    Address:  192.168.1.2

    > ls -a yourdomain.com
    [ns1.mydomain.com]
    $ORIGIN yourdomain.com.
    ipass                   2D IN CNAME     snoopy
    smtp                    2D IN CNAME     charlie
    mail                    2D IN CNAME     charlie
    pop                     2D IN CNAME     lucy
    yourdomain              2D IN CNAME     charlie
    ww2                     2D IN CNAME     linus
    www                     2D IN CNAME     sally
    > exit
host |
#### Syntax
    host [options] host [dnsserver]
#### Description Look up host, optionally specifying a particular dnsserver. #### Frequently used options -d Enable debugging, showing network transactions in detail. -v Use verbose mode. Results are displayed in the official domain master file format. #### Example
    # host -v oreillynet.com
    Trying null domain
    rcode = 0 (Success), ancount=1
    The following answer is not authoritative:
    oreillynet.com  1991 IN A       208.201.239.36
    For authoritative answers, see:
    oreillynet.com  167591 IN       NS      NS1.SONIC.NET
    oreillynet.com  167591 IN       NS      NS.SONGLINE.COM
    Additional information:
    NS1.SONIC.NET   167591 IN       A       208.201.224.11
    NS.SONGLINE.COM 167591 IN       A       208.201.239.31
## On the Exam Detailed knowledge of nslookup and host are not required, but you must be familiar with their purpose and basic operation.
Additional utilities, such as dig and dnsquery, also can help you with DNS queries, though they are not mentioned in this exam Objective. ##### 20.5.1.4 BIND Version 4 versus Version 8 configuration files It's likely that a Linux administrator will maintain or install systems running BIND v4.x as well as the newer v8.x. This LPI Objective requires an understanding of the differences between the configuration files for these two BIND versions. Under BIND v4, the configuration file was called /etc/named.boot. Example 20-5 shows a trivial BIND v4 configuration file. ##### Example 20-5. BIND v4 named.boot File
    directory                                /var/named
    cache   .                                root.hints
    primary 0.0.127.IN-ADDR.ARPA             127.0.0.zone
    primary localhost                        localhost.zone
In BIND v8, the configuration file was renamed /etc/named.conf. Example 20-6 shows the equivalent configuration in the BIND v8 format. ##### Example 20-6. BIND v8 named.conf File
    // generated by named-bootconf.pl

    options {
            directory "/var/named";
    };

    zone "." {
            type hint;
            file "root.hints";
    };

    zone "0.0.127.IN-ADDR.ARPA" {
            type master;
            file "127.0.0.zone";
    };

    zone "localhost" {
            type master;
            file "localhost.zone";
    };
    };
As you can see, the information contained in the files is largely the same, but the v8 format contains a more formal structure. For those upgrading to Version 8, the Perl script named-bootconf.pl is included in the v8 package to upgrade named.boot to named.conf.
## On the Exam You should be generally familiar with the structural differences between the configuration files for BIND v4 and v8. However, detailed named configuration is beyond the scope of the LPIC Level 1 exams.