Vendor -Specific Options (DNS and BIND, 4th Edition)

6.4. Vendor -Specific Options

Unix is ostensibly a standard operating system, but there are almost as many Unix standards as flavors of Unix. Likewise, there are almost as many different styles of resolver configuration as there are versions of Unix. Almost all support the original Berkeley syntax, but most add nonstandard enhancements or variations, too. We'll cover as many of the major styles of resolver configuration as we can.

6.4.1. Sun's SunOS 4.x

Configuring a host running SunOS can be a challenge. The behavior of the SunOS resolver is arguably as different from that of standard BIND as major vendors get -- primarily because SunOS's resolver is integrated with Sun's Network Information Service, or NIS (née Yellow Pages).

Briefly, NIS provides a mechanism for keeping important files synchronized between hosts on a network. This includes not just /etc/hosts but also /etc/services, /etc/passwd, and others. Sun positions DNS as a backup option to NIS; if the NIS resolver can't find a host name (or IP address) in the NIS hosts map, you can configure it to query a name server.

Note that the resolver functionality is implemented as part of the ypserv program, which also handles other types of NIS queries. So if ypserv isn't running, neither is your resolver! (Mercifully, the resolver in Solaris 2 doesn't require that you run ypserv.) One benefit of using ypserv to resolve all queries is that you don't need to configure the resolvers on NIS clients, only on NIS servers.[43] The NIS clients will query an NIS server for host data, and the NIS server will query DNS, if necessary.

[43]Actually, you also need to configure the resolver on hosts on which you use sendmail.mx, Sun's MX record-smart version of sendmail.

If you run SunOS 4.x (Solaris 1), you can either (1) follow the party line and configure your resolver to use DNS as a backup to NIS, (2) choose to run NIS without the hosts map, or (3) buck convention and recompile your resolver to use DNS exclusively -- or you can pick up free copies of modified resolvers on the Internet. However, we must warn you that, according to our sources, Sun will not support the modified resolver option.

If you run Solaris 2, you can simply configure the resolver like a normal human being and use the nsswitch.conf file to specify that you want to use DNS for name resolution.

6.4.1.1. Modified resolvers

We won't go into much detail about this option here, primarily because this process was well-documented and nearly automated in the BIND 4 distributions. The process itself usually involves creating a new libc.so -- the standard, shared C library -- by pulling out routines that call NIS and replacing them with pure DNS versions. Although Sun generously provides the necessary replacement routines, they don't support them. Worse, the routines supplied with SunOS 4.x were based on BIND 4.8.1.

BIND 4 source distributions contained instructions on installing the BIND resolver routines under SunOS 4.x in the package's shres/sunos subdirectory in a file called INSTALL. As of BIND 8, however, the instructions don't work (and as of BIND 8.2.2, they're not included). You can still get older BIND source distributions via anonymous FTP from ftp.isc.org in /isc/bind/src, though. If you want to build a replacement SunOS 4.x resolver from the source code, we recommend using the source code from BIND 4.9.7, available from ftp.isc.org in /isc/bind/src/4.9.7/bind-4.9.7-REL.tar.gz.

If you'd rather skip the potentially edifying experience of creating your own shared C library and leverage someone else's efforts, you can check out resolv+, which is based on the BIND 4.8.3 resolver. resolv+ is an enhanced version of the 4.8.3 resolver routines for SunOS. It was written by Bill Wisner and allows administrators to choose the order in which NIS and DNS are queried (much like the extensions other vendors have added to Unix, which we'll discuss later). The new routines are available, with instructions on how to build them into the file libc.so, from ftp.uu.net as the file /networking/ip/dns/resolv+2.1.1.tar.Z. For more information on the functionality resolv+ provides, see the Linux section later in this chapter.

6.4.1.2. Using DNS with NIS

If you go the socially acceptable route, though, you'll need to make NIS and DNS coexist peacefully. That's a little tricky, so let's go over it in some detail. We won't cover how to set up NIS -- that's already been covered in gory detail in Hal Stern's Managing NFS and NIS (O'Reilly). Note that these instructions apply only to versions of SunOS after 4.1. If you run an older version of SunOS, consider the replacement libraries on ftp.uu.net. Or upgrade.

First, you'll need to modify the Makefile NIS uses to build its maps -- the files that it distributes to other hosts on the network. You should make this modification on the master NIS server, not on the slaves.

The NIS Makefile lives in /var/yp/Makefile on a SunOS host. The change you need to make is simple: you need to uncomment one line and comment another. Find the lines that read:

#B=-b
B=

and change them to read:

B=-b
#B=

Then rebuild your NIS hosts map:

# cd /var/yp
# rm hosts.time
# make hosts.time
updated hosts
pushed hosts

This will insert a "magic cookie" into the hosts map that instructs NIS to query DNS if it can't find a host name in the hosts map. Now, when the ypserv program looks up a name, it checks the appropriate hosts map for the local NIS domain, and if it can't find the name there, it queries a name server. The search list ypserv uses when it queries the name server is derived from either the local NIS domainname or from the domain directive in resolv.conf.

Next, you should create a resolv.conf file, if you need one. The rules for configuring the resolver change slightly with SunOS:

You can't set the hostname to a domain name and have the resolver infer the local domain.
You also can't use the search directive in resolv.conf, since the SunOS 4.x resolver is based on BIND 4.8.1. The resolver will silently ignore it.
You can set the NIS domainname to a domain name (you have to set it to the name of your NIS domain if you're using NIS), and the resolver will derive the name of the local DNS domain from it. However, this doesn't work in quite the same way it does with BIND; if you set domainname to fx.movie.edu, for example, the search list will include only movie.edu. Why doesn't the search list include fx.movie.edu? Because NIS assumes it's already checked an authoritative source of fx.movie.edu host data -- the fx.movie.edu hosts map.
If you want to set the local domain name to the same name as your NIS domainname, you can prepend a dot or a plus sign (+) to the domainname. To set your local domain name to fx.movie.edu, you could set domainname to either +fx.movie.edu or .fx.movie.edu.
You can also override NIS's normal behavior by setting the local domain name with the domain directive in resolv.conf. So if you wanted to force the resolver to include fx.movie.eduin the search list, you could add domain fx.movie.edu to resolv.conf.
You can even set the domain directive in resolv.conf to a DNS domain name totally unrelated to your NIS domainname. In some unfortunate situations, the local NIS domainname isn't the same as, or even similar to, the local DNS domain name. Say the Information Technology Department at Movie U. had originally set up the NIS domain it.dept.movieu, and still uses it. To prevent spurious DNS queries in the nonexistent dept.movieu domain, hosts in this NIS domain should be configured with domain movie.edu (or something similar) in resolv.conf.

Finally, Sun's resolv.conf treats the nameserver directive just as vanilla BIND does. So once you're done with inserting magic cookies and configuring your NIS domainname and possibly your local DNS domain name, you can add any name servers to resolv.conf and be done.

6.4.1.3. Ignoring NIS

If you want to retain Sun's support but would rather not use icky NIS, you still have an option: you can run NIS with an empty hosts map. First, set up your resolv.conf file, insert the magic cookie into the NIS Makefile as we described in the last section, and create an empty hosts map. Creating an empty hosts map just requires moving the NIS master server's /etc/hosts file aside temporarily, generating your NIS hosts map, then replacing the /etc/hosts file:

% mv /etc/hosts /etc/hosts.tmp
% touch /etc/hosts # to keep make from complaining
% cd /var/yp
% make hosts.time
updated hosts
pushed hosts
% mv /etc/hosts.tmp /etc/hosts

Now, when the resolver checks NIS, it doesn't find anything and goes directly to querying a name server.

If you periodically rebuild your NIS maps, you should make sure the hosts map doesn't accidentally get rebuilt from /etc/hosts. The best way to do this is to remove the hosts target from the NIS Makefile. You can just comment out everything in the Makefile from the line that begins with:

hosts.time: $(DIR)/hosts

to the next blank line.

6.4.2. Sun's Solaris 2.x

The resolver in Solaris 2 through 2.5.1 is based on the BIND 4.8.3 resolver. The Solaris 2.6, 7, and 8 resolvers are based on BIND 4.9.4-P1. Interestingly, Sun chose not to follow RFC 1535's advice and trim the search list to just the local domain name, so even the BIND 2.6 and later resolvers include the names of all parent domains with at least two labels in the search list. Patches are available to upgrade Solaris 2.5 and 2.5.1 resolvers to BIND 4.9.3.[44]

[44]Check http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access for current patch numbers.

All Solaris 2.x resolvers support extensions to give you the ability to determine the order in which the resolver consults various sources of host information, including DNS, NIS, NIS+, and /etc/hosts. This service order is configured in a file called nsswitch.conf, which lives in the /etc directory.

Actually, nsswitch.conf is used to configure the order in which a number of different sources are checked. You select the database you want to configure by specifying a keyword. For naming services, the database name is hosts. The possible sources for the hosts database are dns, nis, nisplus, and files (which refers to /etc/hosts in this case). Configuring the order in which the sources are consulted is a simple matter of listing them after the database name in that order. For example:

hosts:  dns files

has the resolver try DNS (i.e., query a name server) first, then check /etc/hosts. By default, resolution moves from one source to the next (e.g., falls back to /etc/hosts from DNS) if the first source isn't available or the name being looked up isn't found. You can modify this behavior by specifying a condition and an action in square brackets between the sources. The possible conditions are:

UNAVAIL: The source hasn't been configured (in DNS's case, there is no resolv.conf file and there is no name server running on the local host).

NOTFOUND: The source can't find the name in question (for DNS, the name looked up or the type of data looked up doesn't exist).

TRYAGAIN: The source is busy, but might respond next time (for example, the resolver has timed out while trying to look up a name).

SUCCESS: The requested name was found in the specified source.

For each of these criteria, you can specify that the resolver should either continue and fall back to the next source or simply return. The default action is return for SUCCESS and continue for all the other conditions.

For example, if you want your resolver to stop looking up a domain name if it receives an NXDOMAIN (no such domain name) answer, but to check /etc/hosts if DNS isn't available, you could use:

hosts:  dns [NOTFOUND=return] files

The default Solaris nsswitch.conf configuration, by the way, is determined by the answers you give SunInstall. Believe it or not, though, none of the default nsswitch.conf configurations includes dns as a source. This from the dot in .com ?

6.4.2.1. nscd

In Solaris 2.x, Sun introduced a name service cache daemon called nscd. nscd caches the results of lookups in the passwd, group, and hosts sources. You can think of nscd as very similar to a caching-only name server, except that it also works for information in passwd and group sources. Sun's intent with nscd was to speed up performance by caching frequently looked-up names. Unfortunately, word on the street is that nscd sometimes actually slows DNS lookups, so many people disable it. Moreover, nscd interferes with round robin (nscd caches records in one order and doesn't rotate them).

nscd is started by default during a multiuser bootup and reads the configuration file /etc/nscd.conf. Administrators can tune a number of parameters in nscd.conf. The most important of these are:

enable-cache hosts (yes | no): Determines whether or not nscd caches the results of host lookups

positive-time-to-live hosts value: Determines how long nscd caches positive results (e.g., addresses), in seconds

negative-time-to-live hosts value: Determines how long nscd caches negative results (e.g., NXDOMAIN), in seconds

But if you're not convinced of nscd 's usefulness, at least with DNS lookups, you can use:

enable-cache hosts no

to turn caching off for the hosts source.

6.4.3. HP's HP-UX

HP's resolver implementation is basically straight BIND; the HP-UX 8.0 through 10.00 resolvers are based on BIND 4.8.3 and support the standard domain, nameserver, and search directives. The order in which a host consults DNS, NIS, and the host table is hard-wired. The host uses DNS if DNS is configured (i.e., if there's a resolv.conf file or a name server is running locally). If DNS isn't configured and NIS is running, the host uses NIS. If neither DNS nor NIS is running, the host uses the host table. The host falls back to using the other services only under the circumstances described earlier in the chapter (i.e., the resolver uses only one name server -- either listed in resolv.conf or on the local host by default -- and four errors are received while contacting that name server).

The hard-wired algorithm is less flexible than what other vendors provide, but it's easy to troubleshoot. When you can consult DNS, NIS, and the host table in any order, diagnosing user problems can be awfully difficult.

The HP-UX 10.10 through 11.00 resolvers are based on BIND 4.9.x. Therefore, they support the BIND 4.9.x search list behavior and the options ndots directive.

Patches are available for all versions of HP-UX 10.x and later to upgrade the name server and ancillary programs to BIND 4.9.7. To gain access to the patches, visit the HP-UX patch archive at http://us-support.external.hp.com and register. Then you can search the patch database for the latest patches.

The HP-UX 11.10 resolver is based on BIND 8.1.2. The configuration of a BIND 8.1.2 resolver is nearly identical, from a configuration perspective, to the previous BIND 4.9.x-based resolvers: they understand the same configuration directives and derive their default search list the same way.

HP-UX 10.00 introduced Solaris's nsswitch.conf functionality; that is, you can use nsswitch.conf to control the order in which the resolver consults the various naming services.[45] The syntax is exactly the same as that used in Solaris's nsswitch.conf. The default settings for the hosts database under HP-UX are:

[45]Before HP-UX 10.10, you could only use nsswitch.conf to configure the order of resolution for the hosts source. From 10.10 on, you can also use nsswitch.conf to configure resolution order for the services, networks, protocols, rpc, and netgroup sources.

hosts: dns [NOTFOUND=return] nis [NOTFOUND=return] files

The nsswitch.conf functionality, as well as the BIND 4.9.7 name server upgrade, is also available in patches for versions of HP-UX as old as 9.0. Check the web-based HP-UX patch archive for these. You may need quite a few patches:

One for the standard, shared C library, libc.so, which contains the resolver routines in HP-UX
One for the mount command, which is statically linked
One for nslookup
One for the ifconfig and route commands
One for HP's Visual User Environment (VUE) or the Common Desktop Environment (CDE), which are shipped statically linked

6.4.4. IBM's AIX

The resolver shipped with the recent versions of AIX, including 4.3 and 4.2.1, is also relatively standard. The code is based on BIND 4.9.x, so it understands the domain, search, nameserver, options, and sortlist directives; AIX supports up to three nameserver directives. AIX Versions 4 and 4.1 were based on BIND 4.8.3, so they handle all the directives AIX 4.2.1's resolver does except options and sortlist.

One difference between AIX's behavior and the stock BSD behavior is that AIX uses the existence of the resolv.conf file to determine whether to query a name server. If resolv.conf doesn't exist on the local host, the resolver reads /etc/hosts. This means that on a host running a name server, you should create a zero-length /etc/resolv.conf file even if you don't intend to put any directives in it.

6.4.4.1. AIX 4.3

The AIX 4.3 resolver also supports two environment variables, RES_TIMEOUT and RES_RETRY, that allow you to control the resolver's initial timeouts (à la the options timeout directive) and number of attempts (à la options attempts). You can set these in a shell startup script or on the command line, as in:

# RES_TIMEOUT=2 /usr/sbin/sendmail -bd -q1h

AIX 4.3 supports a mechanism to control resolution order called irs.conf, similar to Solaris's nsswitch.conf. The syntax is slightly different, though. Like nsswitch.conf, irs.conf calls the database hosts. The names of the sources are nearly the same (dns, nis, and local, as opposed to files) but AIX uses the keyword continue at the end of a line to signal that the resolver should try the next source of information, listed on the next line. To indicate that a source of information is authoritative and that the resolver should not try the next source if the previous returns a negative answer (like [NOTFOUND=return] ), add the tag =auth after the argument. So to tell the resolver to try DNS and go on to try /etc/hosts only if DNS isn't configured, you could use the following irs.conf file:

hosts dns=auth continue
hosts local

If you need to specify the order on a user-by-user basis or override the system's default, you can use the NSORDER environment variable. NSORDER takes the same arguments as irs.conf but formatted as a comma-separated list, as in:

NSORDER=dns,local

As with irs.conf, you can specify that a source is authoritative using =auth:

NSORDER=dns=auth,local

6.4.4.2. AIX 4.2.1

The AIX 4.2.1 mechanism to control resolution order is similar but more limited. AIX 4.2.1 uses a file called /etc/netsvc.conf. The netsvc.conf file also calls the database hosts, but it uses an equals sign between the database name and the sources instead of a colon, uses commas between sources, and uses bind for DNS and local for /etc/hosts. So:

hosts = local,nis,bind

has the AIX resolver check the local /etc/hosts first, then check the NIS hosts map, and finally try DNS. As with AIX 4.3, individual users or processes can override the systemwide resolution order configured with netsvc.conf by setting the NSORDER environment variable.

We should also note that you can configure the resolver using AIX's System Management Interface Tool (SMIT).

6.4.5. Compaq's Tru64 Unix and Digital Unix

The resolver shipped with Tru64 Unix 5.0 is based on the BIND 8.1.2 resolver. The resolver shipped with Digital Unix 4.0 is based on the BIND 4.9.x resolver. As such, both understand all five main resolver directives covered in this chapter, but not BIND 8.2 additions such as options timeout.

The Tru64 Unix 5.0 resolver does name checking but also lets you specify certain otherwise-illegal characters that you want to allow in domain names. To do this, simply list the characters, backslash-quoted, after the allow_specialdirective. To allow underscores, for example, you could use:

allow_special \_

You can also specify the argument all to allow any character, but that's probably not a good idea.

Both of Compaq's versions of Unix allow you to configure the order in which the resolver checks NIS, DNS, and the host table via a file called svc.conf (check out the svc.conf(4) manpage).[46] svc.conf also allows you to configure which services are consulted for other databases, including mail aliases, authentication checks (mapping from IP address to host or domain names), password and group information, and a slew of other things.

[46]Poor old Ultrix also supports svc.conf.

To configure the resolver with svc.conf, use the database name hosts, followed by an equals sign and the keywords for the services you want checked, separated by commas in the order you want them checked. The legal keywords for the hosts database are local (/etc/hosts), yp (for "Yellow Pages," the old name for NIS), and bind (for DNS). local must be the first service listed for hosts. Don't use any whitespace on the line, except (optionally) after commas and at the end of the line. For example, the line:

hosts=local,bind

instructs the resolver to check /etc/hosts for host names first and, if no match is found, to use domain name service. This is very useful when the host has a small local host table that includes the local host's domain name and IP address, the host's default router, and any other hosts referenced during startup. Checking the local host table first avoids any problems using domain name service during startup, when networking and named may not have started.

Compaq's Unixes also include a utility called svcsetup (see the svcsetup(8) manpage), which allows you to set up the svc.conf file interactively, without the aid of an editor. Typing svcsetup will throw you into a mode where you can choose the database you'd like to configure. svcsetup will prompt you for the order of the services you want checked.

6.4.6. Silicon Graphics' IRIX

As of IRIX 6.5, IRIX has a BIND 4.9.x resolver and name server. The resolver understands the domain, search, nameserver, options, and sortlist directives. The previous version of IRIX, 6.4, had a BIND 4.9.x-based name server, but a 4.8.3-based resolver. There are also patches available for versions of IRIX as old as 5.3 to bring the name server up to BIND 4.9.7. For the current patch numbers, see http://support.sgi.com/colls/patches/tools/browse.

In IRIX 6.x, the resolv.conf file moved from /usr/etc/resolv.conf, its former location, to the more standard /etc/resolv.conf. (For compatibility with software compiled under older versions of IRIX, you may need to create a link from /usr/etc/resolv.conf to /etc/resolv.conf.)

Like Solaris 2.x and HP-UX, IRIX 6.5 supports the nsswitch.conf file. IRIX's nsswitch.conf has the same format as Solaris's, but adds noperm (no permission to use the service) to the list of conditions. The default for the hosts database is:

hosts: nis dns files

The IRIX name service daemon, nsd, reads nsswitch.conf. Like Sun's nscd, nsd maintains a systemwide cache of previously looked-up data, including host information derived from DNS and NIS. nsd supports many attribute settings in nsswitch.conf that Solaris and HP-UX don't support. For example, you can also add a timeout setting in parentheses to determine how long nsd will cache records learned from DNS:

hosts: files dns (timeout=600)      # cache timeout of 10 minutes

You can also specify a negative caching timeout with negative_timeout. For a complete list of attributes, see the nsd(1m) manpage.

Older IRIX resolvers (until 6.4) support a hostresorder directive instead of nsswitch.conf. Like nsswitch.conf, the hostresorder directive allows the administrator to determine the order in which NIS, DNS, and the local host table are searched. Individual users can set the environment variable HOSTRESORDER to determine the order in which the services are used for their commands. The IRIX 6.5 resolver ignores the hostresorder directive.

hostresorder takes one or more of the keywords nis, bind, and local as arguments. (The keywords correspond to the obvious services.) The keywords may be separated by either whitespace or a slash. Whitespace indicates that the next service should be tried if the previous service doesn't return an answer (e.g., the name isn't found in the host table or the name server returns "no such domain name") or isn't available (e.g., the name server isn't running). A slash indicates that the preceding service is authoritative, and if no answer is returned, resolution should stop. The next service is tried only if the previous isn't available.

6.4.7. Linux

Since we first published this book, Linux has taken the computing world by storm. A couple of the reasons are that Linux is freeware and that it does a better job of keeping up with developments in the Unix and Internet communities than any vendor's version of Unix. Attesting to that is the fact that Red Hat Linux 7.0, the latest version of one of the predominant strains of Linux, ships with a BIND 8.2.2-P5 name server. The resolver, however, is still based on the BIND 4.9.x resolver. It supports the nsswitch.conf file.

However, some older Linux resolvers are based on Bill Wisner's resolv+ library, which is in turn based on BIND 4.8.3. Consequently, the resolv.conf file can include any legit 4.8.3 resolver directives (domain, search, and nameserver, but not options or sortlist) and has the older default search list described in this chapter.

resolv+, as the name suggests, also provides several enhancements over the standard 4.8.3 resolver. These include the ability to determine the order in which DNS, NIS, and /etc/hosts are consulted (replaced by the more standard nsswitch.conf in newer versions), the ability to detect certain types of DNS spoofing, and the ability to reorder address records in replies to favor local subnets.

All of these enhancements are controlled by the /etc/host.conf file. The most interesting keywords that host.conf accepts are:

order: Controls the order in which the various name services are consulted; the valid arguments are bind, hosts, and nis, at least one of which must follow the keyword. Multiple arguments must be separated by commas.

nospoof: Takes the single argument on or off. nospoof instructs the resolver to check any reverse-mapping (PTR) information it gets from remote name servers by issuing a forward (address) query for the domain name in the reply. If the address returned by the address query isn't the same as the address the resolver originally tried to reverse map, the PTR record is ignored.

reorder: Takes the single argument on or off. With reorder on, the resolver sorts the addresses of multihomed hosts so that any address on a local subnet appears first.

[47]To access a Microsoft Knowledge Base article by article ID number, go to http://search.support.microsoft.com/kband check the Specific article ID number radio button, then type the article ID number in the search field.

6.4.9. Windows 98

The resolver in Windows 98 is almost identical to Windows 95's resolver. (Graphically, in fact, it is identical, so we won't show you any screen shots.) The major differences between the two resolvers are due to the fact that Windows 98 ships with Winsock 2.0.[48]

[48]The version of Winsock in Windows 95 can be upgraded to 2.0; see Knowledge Base article Q182108.

Winsock 2.0, for example, sorts responses according to the local routing table. So if a name server returns multiple addresses in a response and one of those addresses is on a network that the local host has an explicit (not default) route to, the resolver sorts that address to the beginning of the response. For details, see Knowledge Base article Q182644.

Configuring DUN-specific name servers also works with Windows 98. The resolver queries both the name servers listed in the TCP/IP Properties panel and the DUN-specific name servers simultaneously, and takes the first positive answer it receives from either set. If the resolver receives only negative answers, it returns that.

6.4.10. Windows NT 4.0

In Windows NT, LAN resolver configuration is done from a single panel that looks remarkably similar to Windows 95's since NT 4.0 incorporated the Windows 95 "shell." In fact, other than the new Edit button and the presence of handy little arrows that allow you to reorder name servers and elements of the search list, there's really no semantic difference between them, as shown in Figure 6-3.

Figure 6-3. Resolver configuration under Windows NT

To get to the DNS Configuration panel, go to the Control Panel, click on Network, and select the Protocols tab. Double-click on TCP/IP Protocol, then select the tab for DNS.

Windows NT also allows the user to configure resolver settings specific to particular dialup networking connections. To configure these, click on the My Computer icon, select Dial-Up Networking, pull down the top selection box, and choose the name of the DUN connection whose resolver you'd like to configure. Then click on the More pull-down and select Edit Entry and Modem Properties. Select the Server tab on the resulting window, and click on the TCP/IP Settings button. You'll see the very same window you'd see in Windows 95 (shown earlier). If you leave the Server assigned name server addresses radio button checked, the resolver retrieves the name servers it should query from the server you dial into. If you check Specify name server addresses and specify the addresses of one or two name servers, Windows NT uses those name servers when the DUN connection is active. When you drop the DUN connection, NT reverts to using the LAN resolver's settings.

The Windows NT 4.0 resolver caches name-to-address mappings on a per-process basis, according to the time to live on the returned address records. Good for Microsoft!

Microsoft updated the resolver fairly extensively in Windows NT 4.0, Service Pack 4. The SP4 resolver supports a sortlist, like a BIND 4.9.x resolver does, though the sortlist isn't configurable. Instead, the sortlist is based on the computer's routing table: addresses on networks that the computer has direct routes to are sorted to the beginning of responses. If you don't like this behavior -- for example, because it interferes with round robin -- you can disable it using a new registry value. See Microsoft Knowledge Base article Q196500 for details.

The SP4 resolver also gives you the ability to turn off caching in the resolver using (guess what?) a registry value. For details, see Knowledge Base article Q187709.

The SP4 resolver sports a new retransmission algorithm, too. The resolver still sends its first query to the first name server in the DNS Server Search Order. However, the resolver waits only one second before retransmitting the query, and it retransmits to all of the name servers it knows about -- name servers it has learned about via static configuration, DHCP, and RAS. If none of these name servers responds in two seconds, the resolver retransmits to all the name servers again. It keeps doubling the timeout and retransmitting for a total of four retransmissions and 15 seconds. See Knowledge Base article Q198550 for details.

For you name server administrators, this behavior may mean significantly higher load on your name servers, so take care that the first name server listed in your SP4 resolvers' DNS Server Search Order is fast (usually responds in less than a second) and that you don't unnecessarily configure an SP4 resolver to query a name server (i.e., trim the DNS Server Search Order down to the minimum).

6.4.11. Windows 2000

The resolver in Windows 2000 is a little tough to find. To get to it, click on Start, then Settings, then Network and Dial-up Connections. This brings up the window shown in Figure 6-4.

Figure 6-4. Windows 2000 Network and Dial-up Connections

Right-click on Local Area Connection and choose Properties. This brings up a window like the one shown in Figure 6-5.

Figure 6-5. Windows 2000 Local Area Connection Properties

Double-click on Internet Protocol (TCP/IP). This posts the basic resolver configuration window shown in Figure 6-6.

Figure 6-6. Basic Windows 2000 resolver configuration

If you check the Obtain DNS server address automatically radio button, the resolver queries the name servers that the local DHCP server tells it to use. If you check the Use the following DNS server addresses radio button, the resolver queries the name servers you specify in the Preferred DNS server and Alternate DNS server fields.[49]

[49]More 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 slave (secondary master) name servers for some zone or another in those fields. Besides, "DNS" is an abbreviation for "Domain Name System," not "domain name server."

To get at more advanced resolver configuration, click on (what else?) the Advanced... button. Click on the DNS tab and you'll see the window in Figure 6-7.

Figure 6-7. Advanced Windows 2000 resolver configuration

If you've specified the addresses of name servers to query in the basic resolver configuration window, you'll see them again at the top of this window, under DNS server addresses, in order of use:. As in the Windows NT 4.0 resolver configuration window, the buttons allow you to add, edit, remove, and reorder the name servers listed. There doesn't seem to be a limit to the number of name servers you can list, but it doesn't make much sense to list more than three.

The Windows 2000 resolver uses the same retransmission algorithm that the Windows NT 4.0 SP4 resolver does: it retransmits to all of the name servers configured. And since you can have a different set of name servers configured for each network interface (or adapter, in Microsoft's parlance), that can be quite a few name servers. For details, see Knowledge Base article Q217769.

Since it's possible, in these days of split namespaces, to get two different answers from two different name servers, the Windows 2000 resolver temporarily ignores negative answers (no such domain name and no such data) while querying multiple name servers. Only if it receives a negative answer from a name server configured for each interface does it return a negative answer. If the resolver receives even a single positive answer from a name server, it returns that.

Checking the Append primary and connection specific DNS suffixes radio button has the resolver use the primary DNS suffix and the connection-specific DNS suffixes as the search list. The DNS suffix specific to this connection is set in this window, in the field to the right of DNS suffix for this connection. The primary DNS suffix, on the other hand, is set in the Control Panel by clicking on System, choosing the Network Identification tab, clicking on the Properties button, and then clicking on More.... This brings up the window shown in Figure 6-8.

Figure 6-8. Configuring the primary DNS suffix in Windows 2000

To set the Primary DNS suffix of this computer, enter it in the field below that label.

The checkbox labeled Append parent suffixes of the primary domain suffix (see Figure 6-7) configures the resolver to use a BIND 4.8.3-style search list derived from the primary DNS suffix. So if your primary DNS suffix is fx.movie.edu, the search list will contain fx.movie.eduand movie.edu. Note that the connection-specific DNS suffix isn't "devolved" (in Microsoft's words) into a search list, but if it's configured, the connection-specific suffix is included in the search list.

Checking the Append these DNS suffixes (in order) button configures the resolver to use the search list specified in the fields below. As with the list of name servers, you can add, edit, remove, and reorder these with the buttons and arrows.

Finally, it's worth mentioning the two checkboxes at the bottom of the window. Register this connection's addresses in DNS determines whether or not this client will try to use dynamic update to add an address record mapping its name to the address of this connection. Use this connection's suffix in DNS registration controls whether that update will use the domain name associated with this connection or the primary DNS suffix for this computer.

This feature -- automatic registration -- is designed to ensure that the domain name of your Windows 2000 client always points to its current IP address, even if that address was delivered by a DHCP server. (The DHCP server actually adds the PTR record mapping the client's IP address back to its domain name.) It's also the death knell of WINS, the Windows Internet Name Service, the proprietary -- and much maligned -- Microsoft NetBIOS naming service. Once all of your clients are running Windows 2000, they'll all use dynamic update to keep their name-to-address mappings current, and you can drive a wooden stake through the heart of WINS.

Allowing clients to dynamically update zones presents certain, er, challenges, though, which we'll explore in the last chapter of this book .