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.
Resolver
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
nameserver 206.26.36.46
nameserver 206.26.36.47
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.
LAN Cache
Another option is to use a single cache for the entire LAN. Install dnscache on a computer with a static IP and then configure the other computer’s resolvers to point to it, replacing any existing nameserver entries:
nameserver 192.168.1.110
This is called an external cache because other hosts are allowed to access it. dnscache comes with built-in authentication, so you must specify which hosts are allowed access. Never ever expose your DNS cache to the world at large. Ever. It’s a big security hole.
FQDN
Host names are a continual source of confusion. Fully-qualified domain names (FQDNs) are always needed for DNS to work correctly. The Internet domain hierarchy is in a tree format, with the first-level domains at the top. FQDNs are read right-to-left. For example, in server1.bratgrrl.com,
- com is the first-level domain (like .org, .net, .gov, .info, and so forth),
- bratgrrl is the second-level domain name, and
- server1 is the specific machine hostname.
There is a limited, official list of first-level domain names. The first- and second-level names combine to form registered domain names. Add a machine hostname, and that makes a FQDN. I own bratgrrl.com, so everything@bratgrrl.com belongs to me. Mine all mine. I can use any designation on my servers that I want, like weirdname.bratgrrl.com or my.cool.server.at.bratgrrl.com.
Setting the hostname on a Linux PC is easy. In /etc/hostname, give the machine a hostname only, such as server1, and in /etc/hosts, give the FQDN mapped to the IP address, then the hostname:
192.168.1.110 server1.bratgrrl.com server1
Use the hostname and the dnsdomainname commands to test that it was done correctly:
$ hostname
server1
$ dnsdomainname
bratgrrl.com
Red Hat does this slightly differently; it uses /etc/sysconfig/network. Other Linuxes may vary as well, so check your documentation. The various Windows versions vary somewhat, too; start at the Network and Dial-Up Connections control panel. Just because it’s easy doesn’t mean you should do it; changing hostnames will affect a variety of network functions.
There are two types of domains: Internet-connected and private. The first- and second-level names only matter for Internet-connected domains — for running Web, mail, and FTP servers, and such. For these you have to purchase unique names in an approved format from a domain name registrar. For a strictly local domain on a private LAN, you can name your hosts anything you like: server.here.andnow, this.weird.name.because.ican, etc.
In Part 2 we’ll take a look at running a DNS server, security considerations, and mixed networks. Please see Resources for excellent companion articles.
Resources
Internet Assigned Numbers Authority
Tinydns: Kiss Your Bind Good-Bye
Kiss Your BIND Good-bye: In-Depth Configuration with Tinydns
djbdns home page
Stroud’s CWSApps, search here for a variety of Windows DNS and proxy software
man resolver, man hosts
