Understanding domain name system queries
DNS is a hierarchical system of domain zones. Each zone provides a limited set of answers about domain name mappings, the ones within its own subdomain. A given server will query a more general server when it does not know a mapping and, if necessary, follow redirect suggestions until it finds the correct answer (or determines that no answer can be found, producing an error). When a local named server finds the answer to a DNS query, it caches that answer for a configurable amount of time (typically on the order of hours rather than seconds or days). By caching DNS queries, the overall network demand is lowered considerably, especially on top-level-domain (TLD) servers. The article on DNS at Wikipedia (see Resources for a link) is an excellent starting point for understanding the overall architecture. This tutorial borrows a public domain diagram from that site (see Figure 1 below).
A diagram of a hypothetical DNS query makes it easy to understand the overall lookup process. Suppose your local machine wishes to contact the symbolic domain name www.wikipedia.org. To find the corresponding IP address, your machine would first consult the local nameserver you have configured for a client machine. This local nameserver may run on the same machine as the client application; it may run on a DNS server on your local LAN; or it may be provided by your ISP. In almost all cases, it is an instance of BIND's named. This local nameserver will first check its cache, but assuming no cached information is available, will perform steps as in the following diagram:
Figure 1. Example of DNS recursion
Understand that in this diagram, the "DNS Recurser" is the actual DNS server (named), not the client application that talks to it.
DNS uses TCP and UDP on port 53 to serve requests. Almost all DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server.
Configuring client application access to its DNS server(s) is quite straightforward. The entire configuration is contained in the file etc/resolve.conf, whose job is principally to specify the IP addresses for one or more "local" DNS servers. You may manually configure /etc/resolve.conf with known DNS servers; however, if you use DHCP to configure a client, the DHCP handshaking process will add this information to /etc/resolve.conf automatically (you may still read it or even modify it after DHCP sets it up, but it will be reset on reboot). The library code modified by /etc/resolv.conf is called the "DNS resolver."
If more than one DNS server is configured in an /etc/resolv.conf file, secondary and tertiary DNS servers will be consulted if the primary server fails to provide an answer within the specified timeout period. A maximum of three DNS servers may be configured.
The basic entry within an /etc/resolv.conf file contains the
nameserver <IP-addr> entries. Some other entries let you modify returned answers. For example, the directives
search let you expand names without dots in them (like machines on the local LAN). The
options directive lets you change timeouts per DNS server, turn on debugging, decide when to append full domain names, and change other aspects of DNS resolver behavior. For example, one of my machines is configured with:
Listing 1. Modifying options to configure DNS servers
# cat /etc/resolv.conf search gnosis.lan nameserver 0.0.0.0 nameserver 192.168.2.1 nameserver 188.8.131.52 options timeout:3
The first directive lets this machine know that machines on the local LAN use the private domain gnosis.lan, so the simple name bacchus may be resolved as bacchus.gnosis.lan. More than one space-separated domain may be listed in the
Next, I list several DNS servers to try. The first is the local machine itself, which can be referred to either as 0.0.0.0 or by its official IP address, but not with a loopback address. The next
nameserver directive lists my home-office router that connects my LAN to the Internet (and provides DHCP and DNS services). The tertiary nameserver is one provided by my ISP. I also set an option to use a three-second timeout on each nameserver rather than the default five seconds.
BIND 9 comes with four main client utilities. Three of those --
host -- perform similar functions, more or less in descending order of detail. All three utilities are simply command-line utilities to exercise the DNS resolver. Essentially they do what many client applications do internally: these utilities simply provide output on the results of lookups on STDOUT. The most powerful of the three utilities,
dig, also has the most options to limit or configure its output.
These utilities are most often used to look up an IP address from a symbolic domain name, but you may also perform reverse lookups or other record types other than default "A" records. For example, the command
host -t MX gnosis.cx will show you mail servers associated with gnosis.cx. Some examples might help:
Listing 2. host query of google.com
$ host google.com google.com has address 184.108.40.206 google.com has address 220.127.116.11
Listing 3. host MX query of gnosis.cx
$ host -t MX gnosis.cx gnosis.cx mail is handled by 10 mail.gnosis.cx.
Listing 4. nslookup using default (machine-local) server
$ nslookup gnosis.cx Server: 0.0.0.0 Address: 0.0.0.0#53 Non-authoritative answer: Name: gnosis.cx Address: 18.104.22.168
Or a reverse lookup using the
dig utility and specifying a non-default nameserver:
Listing 5. dig reverse lookup specifying a non-default nameserver
$ dig @192.168.2.2 -x 22.214.171.124 ; <<>> DiG 9.2.4 <<>> @192.168.2.2 -x 126.96.36.199 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3950 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;188.8.131.52.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 187.233.64.in-addr.arpa. 2613 IN SOA ns1.google.com. dns-admin.google.com. 2004041601 21600 3600 1038800 86400 ;; Query time: 1 msec ;; SERVER: 192.168.2.2#53(192.168.2.2) ;; WHEN: Thu Nov 10 02:00:27 2005 ;; MSG SIZE rcvd: 104
The remaining BIND 9 utility to keep in mind is
rndc utility controls the operation of a name server. It supersedes the
ndc utility that was provided in older BIND releases. If
rndc is invoked with no command-line options or arguments, it prints a short summary of the supported commands. See the manpage for
rndc for full information on its use.