6.2 Resolver Configuration

So, what exactly does the resolver allow you to configure? Most resolvers let you configure at least three aspects of their behavior: the DNS suffix,^[2] the search list, and the name server(s) that the resolver queries.

^[2] We're using the Windows term here for clarity. You may know the DNS suffix as the default domain if you've configured the BIND resolver before.

6.2.1 DNS Suffix

The DNS suffix is the DNS domain in which a system resides. Under certain circumstances, the resolver uses the DNS suffix to generate the search list (which we discuss next). Don't confuse the DNS suffix, which is obviously a DNS domain name, with the name of the Active Directory domain of which the system is a member. The two values are usually the same because the DNS suffix defaults to a host's Active Directory domain, but they don't have to be. As we'll see in a moment, you can configure a host's DNS suffix to be different from the Active Directory domain of which it's a member. We're going to talk much more about domain names—both DNS and Active Directory—in Chapter 8. But for now, it's not necessary to know anything more about Active Directory domains to understand resolver configuration.

All configuration options for the Windows NT 4.0 resolver were found in a single window. The Windows 2000, Windows XP, and Windows Server 2003 resolvers' configuration settings, however, are located on three separate windows. The first of these windows is where you change a host's DNS suffix. To get there in Windows 2000, open the Control Panel, double-click on System, then click the Network Identification tab. In Windows XP, open the Control Panel, click on Switch to Classic View, double-click System, and finally click the Computer Name tab. In Windows Server 2003, open the Control Panel and choose System, then click the tab labeled Computer Name. In any case, a window very much like the one in Figure 6-1 appears. (This is the version from Windows Server 2003.)

Figure 6-1. Computer Name tab

Here you see the host's fully qualified domain name, which Windows refers to as the Full computer name. It's the concatenation of the host's single-label computer name and its primary DNS suffix. The value listed as Domain is not the DNS suffix; it's the host's Active Directory domain. To change the primary DNS suffix, click Change (Properties in Windows 2000), and you'll see a window like the one shown in Figure 6-2.

Figure 6-2. Computer Name Changes window

You can change the computer name—the first label of the host's name—only from this window. The Member of box again refers to Active Directory domain membership, which, strictly speaking, doesn't affect resolver behavior. To change the DNS suffix, click on More to display the window shown in Figure 6-3.

Figure 6-3. DNS Suffix window

Here—finally!—is where you can change the DNS suffix. This window also shows the only linkage between Active Directory and DNS resolver behavior. A host's DNS suffix stays the same as its Active Directory domain as long as the Change primary DNS suffix when domain membership changes box is checked, which is the default setting. By unchecking this box and changing the Primary DNS suffix of this computer setting, you can decouple the DNS default domain and Active Directory domain. You do this only if you want your hosts to reside in (that is, be named in) a different domain than your Active Directory domain. Few organizations who set up Active Directory want to do this, and Microsoft does not recommend setting the primary DNS suffix to any value other than the DNS name of an Active Directory domain to which the computer is joined. But enough about Active Directory until Chapter 8.

The Windows 2000 and Windows Server 2003 resolvers also support a different DNS suffix for each network interface on the system. In fact, each network interface (or adapter in Windows parlance) has its own resolver configuration. Getting to the connection-specific resolver configuration windows is a little involved, though: in Windows Server 2003, click on Start, then Control Panel, then Network Connections. This brings up the window shown in Figure 6-4.

Figure 6-4. Network Connections window

This particular host has one LAN network interface. Right-click on the local area network adapter and choose Properties. This brings up a window like the one shown in Figure 6-5.

Figure 6-5. Local Area Connection Properties window

(If you know which network interface you want to configure, Windows Server 2003 lets you skip this last step by choosing the name of the network adapter from the menu that cascades from the right of Network Connections.)

Double-click on Internet Protocol (TCP/IP). This displays the second of the three windows used for resolver configuration, which is shown in Figure 6-6.

Figure 6-6. Internet Protocol (TCP/IP) Properties window

Further resolver configuration options are available by clicking the Advanced button and selecting the DNS tab, which produces the third and final window with resolver settings; it's shown in Figure 6-7.

Figure 6-7. Advanced TCP/IP Settings window, DNS tab

The connection-specific DNS suffix is set in the field on the screen in Figure 6-7. Connection-specific DNS suffixes do affect resolver behavior (as we'll talk about in the next section, which discusses the search list), but their primary purpose is to assist with DNS registration. As we discuss in Chapter 8, hosts running Windows 2000, Windows XP, and Windows Server 2003 automatically register their names in DNS. You'd specify a connection-specific suffix if your host connects to multiple networks and needs a different fully qualified domain name on each network. For example, perhaps one interface is connected to a network in which the host is named diehard.movie.edu and another interface is connected to a network in which the host has a different fully qualified domain name, such as diehard.fx.movie.edu.

6.2.2 Search List

The primary DNS suffix and any connection-specific suffixes determine the default search list. The search list was designed to make users' lives a little easier by saving them some typing. The idea is to search one or more domains for incomplete names—that is, names that might not be fully qualified domain names.

Most Windows networking commands that take a domain name as an argument, such as ftp and ping, apply the search list to those arguments.

With the Windows resolver, a user can indicate that a domain name is fully qualified by adding a trailing dot to it.^[3] For example, the trailing dot in the command:

^[3] Note that we said the resolver can handle a trailing dot. Some programs, particularly mail user agents, don't deal correctly with a trailing dot in email addresses. They cough even before they hand the domain name in the address to the resolver.

C:\> ftp ftp.oreilly.com.

means "don't bother searching any other domains; this domain name is fully qualified." This is analogous to the leading backslash in full pathnames in the Windows filesystem. Pathnames without a leading backslash are interpreted as relative to the current working directory while pathnames with a leading backslash are absolute, anchored at the root.

The default search list includes the primary DNS suffix and any connection-specific suffixes. If the Append parent suffixes of the primary DNS suffix box is checked (see Figure 6-7), each of the primary DNS suffix's parent domains with two or more labels is also included in the default search list. So on a Windows 2000, Windows XP, or Windows Server 2003 host configured with a primary DNS suffix of cv.hp.com and the Append parent suffixes of the primary DNS suffix box checked, the default search list would contain first cv.hp.com, the primary DNS suffix, then hp.com (the primary DNS suffix's parent), but not com, as it has only one label.^[4]

^[4] One reason resolvers don't append just the top-level domain is that there are few hosts at the second level of the Internet's namespace, so just tacking on com or edu to foo is unlikely to result in the domain name of a real host. Also, looking up the address of foo.com or foo.edu might well require sending a query to a root name server, which taxes the roots and can be time-consuming.

The search list is usually applied after the name is tried as-is. As long as the argument you type has at least one dot in it, it's looked up exactly as you typed it before any element of the search list is appended. If that lookup fails, the search list is applied.

Why is it better to try the argument first if it contains one or more dots? From experience, people who wrote resolvers found that, more often than not, if a user bothered to type in a name with even a single dot in it, he was probably typing in a fully qualified domain name without the trailing dot. Better to see right away whether the name was a fully qualified domain name than to create nonsense domain names unnecessarily by appending the elements of the search list to it.

Thus, a user typing:

C:\> telnet pronto.cv.hp.com

causes a lookup of pronto.cv.hp.com first since the name contains three dots, which is certainly more than one. If the resolver doesn't find an address for pronto.cv.hp.com, it then tries pronto.cv.hp.com.cv.hp.com, and, if necessary, pronto.cv.hp.com.hp.com.

A user typing:

C:\> telnet asap

on the same host causes the resolver to look up first asap.cv.hp.com and then asap.hp.com, if necessary, but not just asap.

Note that application of the search list stops as soon as a prospective domain name finds the needed data. In the asap example, the search list would never get around to appending hp.com if asap.cv.hp.com resolved to an address.

6.2.2.1 Setting the search list manually

What if you don't like the default search list you get when you set your local domain? Windows lets you set the search list explicitly, domain name by domain name, in the order in which you want the domains searched. You do this with the Append these DNS suffixes (in order) field on the main resolver configuration window (see Figure 6-8).

Figure 6-8. A search order example

You can add as many domain names as you like to this field,^[5] in the order in which you want them appended, and this becomes the host's search list. Setting the search list with Append these DNS suffixes (in order) overrides the default search list.

^[5] Or so it appears; we stopped after adding 10.

The user interface is simple to use: click Add to add a domain name to the list, select a domain name and click Remove to remove it from the list or click Edit to change the domain name. You can also use the Up and Down arrow buttons to reorder the list. The basic search algorithm still applies: the resolver looks up domain name arguments as-is if they contain at least one dot.

The settings shown in Figure 6-8, for example, instruct the resolver to search the corp.hp.com domain first, then paloalto.hp.com, then both domains' parent, hp.com.

This setup might be useful on a host whose users frequently access hosts in both corp.hp.com and paloalto.hp.com. On the other hand, the configuration shown in Figure 6-9 has the resolver search only corp.hp.com (and not that domain's parent, hp.com) when the search list is applied.

Figure 6-9. Another search order example

This might be useful if the host's users access hosts only in the local domain or if connectivity to the parent name servers isn't good, because the configuration minimizes unnecessary queries to the parent name servers.

6.2.3 Name Servers to Query

This section discusses how to tell your resolver which name servers to query. By default, the resolver looks for a name server running on the local host, which is why we could use nslookup on terminator and wormhole right after we configured their name servers. You can, however, instruct the resolver to look to another host for name service. This configuration is sometimes called a DNS client.

The DNS server addresses, in order of use field (see Figure 6-7) tells the resolver the IP addresses of the name server(s) to query. What's potentially confusing is that the information in this field is linked to the Use the following DNS server addresses field in the main TCP/IP properties window (see Figure 6-6). You can specify as many name servers as you want^[6] in the DNS server addresses, in order of use field. As with the list of DNS suffixes in Figure 6-8, the Add, Edit, and Remove buttons have the expected effect. You can also use the Up and Down arrows to reorder the list of addresses. The first two addresses show up as the Preferred DNS server and Alternate DNS server^[7] on the main TCP/IP properties window. Likewise, changes made to the Preferred DNS server and Alternate DNS server fields are reflected in this list.

^[6] As with the DNS suffix list, we stopped after entering 10 values.

^[7] Kudos to Microsoft for clarifying their labels. In previous versions of Windows, name servers were sometimes labeled Primary DNS and Secondary DNS. This sometimes misled users into listing the primary master and secondary name servers for some zone or another in those fields. Besides, "DNS" is an abbreviation for "Domain Name System," not "domain name server."

The settings in Figure 6-7 instruct the resolver to send queries to the name servers running at IP addresses 192.249.249.3 and 192.249.249.1. Typically, you configure the resolvers on your hosts to query your own name servers, but you can configure your resolver to query almost anyone's name server. Of course, configuring your host to use someone else's name server without first asking permission is presumptuous, if not downright rude, and using one of your own usually gives you better performance, so we'll consider this only an emergency option.

If you want the resolver to query the name server running on the local host, you have two choices: you can specify the address of one of the host's adapters, or you can specify the loopback IP address of 127.0.0.1.

6.2.3.1 Query behavior

The way the Windows 2000, Windows XP, and Windows Server 2003 resolvers determine which of the name servers you specify to query is significantly different than in other versions of Windows. Older versions of Windows send a query to the first name server specified. If that name server doesn't respond—say it's down or there's a network problem—the resolver tries subsequent name servers in the order configured, waiting a few seconds between each query. If it queries all configured name servers without getting a response, it cycles through the list again—six more times on some Windows resolvers! In the case of Windows NT 4.0 SP3, if three name servers are configured and none of them are responding, the resolver tries for 75 seconds before finally giving up.

Microsoft's customers must have complained about this long resolver timeout, because things changed drastically with the release of Service Pack 4 for Windows NT 4.0. The resolver retransmission algorithm became much more aggressive. The Windows 2000, Windows XP, and Windows Server 2003 resolvers exhibit the same behavior.

Here's how these resolvers behave after applying the search list to determine the name to look up:

What does the resolver do after it gives up? It times out and returns an error to the calling application. Typically this results in an error like:

C:\> ping tootsie 
Bad IP address tootsie.

Adding up all the waiting time, you can see that the maximum timeout is much less than in older resolvers: 17 seconds (1+2+2+4+8), as opposed to 75 seconds for Windows NT 4.0 SP3—quite a difference!

As soon as the resolver receives a positive answer during this process, it stops and returns that answer to the calling application. A positive answer is a list of resource records answering the query. If the resolver receives a negative answer (indicating that a domain name doesn't exist or that the particular type of record queried doesn't exist for a domain name), it doesn't immediately halt and return that answer. Instead, it just removes from consideration all name servers configured on the network adapter from which it received a negative answer for the duration of that query round. Only if it receives a negative answer from a name server configured for each adapter does it return a negative answer. If the resolver receives even a single positive answer from a name server, it returns that. The net effect of this mechanism is that if the resolver is configured to query name servers on multiple adapters that have different "views" of the namespace, the resolver sees the aggregate view.

The resolver also tracks the response time of individual name servers and shuffles the fastest-responding one to the top of the list. In other words, it adaptively changes the order of the name servers you specify (although these changes are not permanent, nor are they reflected in the resolver configuration windows). As you can see from the retransmission algorithm, the first name server gets only two or three seconds to reply before the resolver begins blasting queries to all configured name servers. By tracking how fast individual name servers respond and favoring the best performer, the resolver tries to minimize simultaneous querying.

The newer resolvers add another twist: if no name servers from a particular adapter respond during a query round, all name servers from that adapter are ignored—that is, not queried—for 30 seconds. This penalty-box treatment cuts down on unnecessary retransmission: if a network connection appears to be dead, there's no sense trying its name servers for every query.