Preventing Vexation and Woe: DNS Fundamentals, Part 1
DNS makes the Internet world go 'round. Carla Schroder takes a look at how DNS works on both the client and server sides in this two-part tutorial.
DNS, domain name services, makes the Internet world go 'round. It should be a simple thing -- match names to IP addresses -- but it's not quite that simple, especially when security and authentication issues are considered. Administering DNS wrongly is surprisingly easy, and can lead to all kinds of headaches. On Internet-connected machines, one little mistake on your server could have a big bad effect on someone else. First, let's take a look at how DNS works on the client side.
Every network-connected computer makes use of a name resolver, which is a collection of library routines, that is called by various network processes. The resolver's job is to find network hosts by going through the hosts file, which contains static lookup tables, or by pointing to a DNS server. To put it another way, the resolver is part of what makes it possible to surf local networks and the Internet by names rather than by IP addresses. Users typically configure resolvers without knowing what they're called when they edit their Internet service provider settings. On Windows, it's the "DNS Configuration" tab in the TCP/IP control panel. On Linux systems, three files are used to control the resolver: resolv.conf, hosts, and host.conf.
The default entry in every hosts file is 127.0.0.1 localhost localhost.localdomain, which is needed for all computers. Do not delete it, as this is a special loopback IP that is available only to the local machine. (This is the only literal IP address used in this article, and localhost must use the 127.0.0.1 IP address. All the other addresses in this article are fake IPs; use whatever is appropriate for your systems.) Hosts files are an alternative to running a DNS server on a small network. Every node on the network needs a copy of the same hosts file. This works fine on small, static networks, but for larger networks that change often, it quickly gets unwieldy. That's why DNS servers were invented.
Local DNS Cache
A typical home or small business user on a dialup or broadband account uses their ISP's domain name servers. In /resolv.conf it might look something like this:
$ cat /etc/resolv.conf
The resolver will always query the first server listed. It will query the second one only if the first one does not respond. Most users input the name servers in the order given by their ISP's instructions, which leads some people to think that reversing the order will query a lesser-used server, and in turn lead to faster Web surfing. It won't hurt anything to try. The resolver will accept up to 3 nameservers.
A more dependable way to speed things up is to use an internal DNS cache. Windows 2000 and XP have built-in DNS caches. To view the contents, use the command
C:\> ipconfig /displaydns
Examining the contents of your cache can yield some surprising results, such as all sorts of applications "phoning home." On my Win2k system, I found that some programs had created a whole raft of entries in the cache. I had configured them to not run any background Internet processes, but they deceived me and did it anyway. Time to plug some holes! A reboot will erase the cache; otherwise, cache entries will eventually expire on their own, depending on their TTL, or time to live. To flush the cache whenever you darn well feel like it, use the following command:
C:\> ipconfig /flushdns
On Linux, there are several programs for local caching. BIND is the most common, and it comes with most Linux distributions. I do not recommend it, though, for long reasons I'll not go into here. My preference is dnscache, which is part of djbdns (see Resources). dnscache is small, lightweight, fast, and secure.