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. | 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 | 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.
Syntaxnslookup 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
Syntaxhost [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 | 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. | 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. | | 