Chapter SEVENTEEN. Domain Name System (DNS)

     

Chapter SEVENTEEN. Domain Name System (DNS)

Chapter Syllabus

17.1 Configuring a Master Name Server

17.2 Configuring Additional Backup Slave and Caching-Only Name Servers

17.3 Delegating Authority to a Subdomain Including DNS Forwarders

17.4 Configuring DNS to Accept Automatic Updates from a DHCP Server

17.5 Dynamic DNS Server Updates and TSIG Authentication

The DNS is said to be the glue of the Internet. In layman's terms, that normally means converting a hostname into an IP address or an IP address into a hostname. With this IP address, we can then kick the entire IP software into action. Are we talking to a local network and looking up our ARP cache, or do we need to communicate with a remote network and need to know the address of a local router and then consult our routing table? Without DNS, we wouldn't be able to resolve a URL to an IP address. Its primary use is providing resolver capabilities to clients , converting a given name into a different representation of that name. This is the basic functionality that we configure first, although I suspect we know how to set up a rudimentary DNS server. We look at the following tasks :

1. Configure master, slave, and caching-only servers including testing with the rndc utility.

2. Configure additional backup slave and caching-only name servers.

3. Delegate authority to a subdomain including DNS forwarders.

4. Configure DNS to accept automatic updates from a DHCP server.

5. Perform an update of a Dynamic DNS Server using nsupdate and TSIG authentication.

The current version of the DNS software (known as BIND = Berkeley Internet Name Daemon) for HP-UX is version 9.2.0. This is available as a free download from http://software.hp.com Security and Manageability. If you are looking at utilizing the automatic updates feature, you need at least version 8.1.2, which is supplied by default with HP-UX 11i version 1. BIND 9.2.0 is supplied as standard with HP-UX 11i versions 1.6 and 2.0.

Here's a quick recap of what the DNS is: It provides a distributed name resolution service by distributing special machines across its entire structure running special software . The special machines and the special software are affectionately known as name servers . The special machines are not really that special , and neither is the software. What makes them special is that they hold the hostnames and IP addresses for all the machines in their locale: They are said to be authoritative for a zone . The structure used by the DNS is similar to the UNIX filesystem inverted tree structure with a few differences:

• The directories are called domains.

• The separator is a dot (.) instead of a forward-slash (/).

• Names are ready backward, i.e., the leaf of the tree is read first, e.g., machinex.sub-domain.domain. This makes referring to local names easy; we just leave of the domain components . We use the Fully Qualified Domain Name (FQDN) only when we want to fully qualify which node we are talking about (much like the absolute pathname to a file).

A zone is a collection of machines and/or a collection of networks. A zone may part of a domain or may encompass the entire domain. A name server is authoritative for the resource records for a zone . Delegating responsibility for a subdomain alleviates the pressure on a higher-level server by making another name server authoritative for the resource records for that zone. A delegated subdomain inserts a new name server into the DNS hierarchy. In this way, an upper-level server knows the name and IP address of the name server responsible for the delegated subdomain. Should a query arrive for that subdomain, the higher-level name server does not have any of the resource records for that subdomain and hence cannot answer the query directly, but can reply with the IP address of the name server for the delegated subdomain that can answer the query. The reverse of this is not necessarily true; in other words, the lower-level server need not know the name and IP address of the upper-level server. This makes some kind of sense when we look at a simple example (see Figure 17-1).

Figure 17-1. A DNS recursive query.

The machine machineX needs to know the IP address of a node called frog001.maabof.com. Node machineX constructs the query and forwards it to the name server for domain keenan- consultants .co.uk . This name server looks up its cache of all known IP addresses and hostnames. It doesn't find the name. At this stage, there is absolutely no point in asking the name server for the domain .co.uk , because that won't get me any closer to finding out the IP address. The only sensible place to start looking for the IP address is at the top of the tree; we have to ask a root name server . If it doesn't know the IP address, it can point me in the general direction because it does know the name servers for delegated subdomains. In this case, it's the name server for the .com domain. (I know that the root name servers are also the name servers for some of the top-level domains (TLD), but this is simply for demonstration purposes.) This continues until I am directed to the name server for the maabof.com domain, which can respond to my initial query. My name server will cache this information as well as all other information gathered during this query for a period of time (using a time-to-live ”TTL ”value) whereby, if I wanted to know the IP address of a node, for example, frog002.maabof.com , my name server could contact the maabof.com name server directly. This is how the DNS operates by default. Forwarding requests to a higher-level domain may make sense in some instances, but that is a specific configuration choice, one we look at later.

The other helpful thing about the structure of the DNS is that it allows us to neatly plug an IP address into the existing structure. If we think about it, an IP address sort of looks like a domain name except that it is backward, e.g., 192.168.0.1, with the leaf (in this case 1 = host part) of the domain name on the right side instead of the left side. If we simply turn an IP address around, we get a structure whereby the names used in the DNS hierarchy are simply the components of an IP address backward. This is advantageous because network services, e.g., remsh , rcp , rlogin , frequently deal with IP addresses and need to convert them back to hostnames. A name server can perform a reverse lookup because the DNS supports PTR records that glue an IP address back to its original hostname. (PTRs are sometimes referred to as glue records. ) To accommodate IP addresses in the DNS namespace, a fictitious domain is created called in-addr.arpa . This part of the namespace is big enough to accommodate every IP address, with an example being (backward remember) 100.0.168.192.in-addr.arpa referring to the IP address 192.168.0.100 . There's a similar part of the namespace for IPv6 IP addresses in which the domain where they reside is called IP6.INT .