The local domain name is the domain name in which the resolver resides. In most situations, it’s the domain name of the zone in which you’d find the host running the resolver. For example, the resolver on the host toystory.movie.edu would probably use movie.edu as its local domain name.

The resolver uses the local domain name to interpret domain names that aren’t fully qualified. For example, when you add an entry such as:

relay bernie

to your .rhosts file, the name relay is assumed to be in your local domain. This makes a lot more sense than allowing access to a user called bernie on every host on the Internet whose domain name starts with relay. Other authorization files such as hosts.equiv and hosts.lpd work the same way.

Normally, the local domain name is determined from the host’s hostname; the local domain name is everything after the first “.” in the name. If the name doesn’t contain a “.”, the local domain is assumed to be the root domain. So the hostname asylum.sf.ca.us implies a local domain name of sf.ca.us, while the hostname dogbert implies a root local domain—which probably isn’t correct, given that there are very few hosts with single-label domain names.^[*]

You can also set the local domain name with the domain directive in resolv.conf. If you specify the domain directive, it overrides deriving the local domain name from the hostname.

The domain directive has a very simple syntax, but you must get it right because the resolver doesn’t report errors. The keyword domain starts the line in column one, followed by whitespace (one or more blanks or tabs), then the name of the local domain. The local domain name should be written without a trailing dot, like this:

domain colospgs.co.us

In older versions of the BIND resolver (those before BIND 4.8.3), trailing spaces are not allowed on the line and will cause your local domain to be set to a name ending with one or more spaces, which is almost certainly not what you want. And there’s yet another way to set the local domain name—via the LOCALDOMAIN environment variable. LOCALDOMAIN is handy because you can set it on a per-user basis. For example, you might have a big, massively parallel box in your corporate computing center that employees from all over the world can access. Each employee may do most of her work in a different company subdomain. With LOCALDOMAIN, each employee can set her local domain name appropriately in her shell startup file.

Which method should you use—hostname, the domain directive, or LOCALDOMAIN? We prefer using hostname primarily because that’s the way Berkeley does it, and it seems “cleaner” in that it requires less explicit configuration. Also, some Berkeley software, particularly software that uses the ruserok() library call to authenticate users, allows short hostnames in files such as hosts.equiv only if hostname is set to the full domain name.

If you run software that can’t tolerate long hostnames, though, you can use the domain directive. The hostname command will continue to return a short name, and the resolver will fill in the domain from resolv.conf. You may even find occasion to use LOCALDOMAIN on a host with lots of users.

The local domain name, whether derived from hostname or resolv.conf, also determines 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 names typed at the command line that might be incomplete—that is, that might not be fully qualified domain names.

Most Unix networking commands that take a domain name as an argument, such as telnet, ftp, rlogin, and rsh, apply the search list to those arguments.

Both the way the default search list is derived and the way it is applied changed from BIND 4.8.3 to BIND 4.9. If your resolver is an older make, you’ll still see the 4.8.3 behavior, but if you have a newer model, including BIND 8.4.7,^[*] you’ll see the improvements in the 4.9 resolver.

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

%telnet ftp.ora.com.

means “Don’t bother searching any other domains; this domain name is fully qualified.” This is analogous to the leading slash in full pathnames in the Unix and MS-DOS filesystems. Pathnames without a leading slash are interpreted as relative to the current working directory, while pathnames with a leading slash are absolute, anchored at the root.

domain cv.hp.com

%telnet pronto.cv.hp.com

%telnet asap

domain cv.hp.com

%telnet pronto.cv.hp.com

%telnet asap

What if you don’t like the default search list you get when you set your local domain name? In all modern resolvers, you can set the search list explicitly, domain name by domain name, in the order you want the domains searched. You do this with the search directive.

The syntax of the search directive is very similar to that of the domain directive, except that it can take multiple domain names as arguments. The keyword search starts the line in column one, followed by a space or a tab, followed in turn by one to six domain names in the order you want them searched.^[*] The first domain name in the list is interpreted as the local domain name, so the search and domain directives are mutually exclusive. If you use both in resolv.conf, the one that appears last overrides the other.

For example, the directive:

search corp.hp.com paloalto.hp.com hp.com

instructs the resolver to search the corp.hp.com domain first, then paloalto.hp.com, and then the parent of both domains, hp.com.

This directive might be useful on a host whose users access hosts in both corp.hp.com and paloalto.hp.com frequently. On the other hand, on a BIND 4.8.3 resolver, the directive:

search corp.hp.com

causes the resolver to skip searching the local domain’s parent domain when the search list is applied. (On a 4.9 or later resolver, the parent domain’s name usually isn’t in the search list, so this is no different from the default behavior.) This might be useful if the host’s users access hosts only in the local domain, or if connectivity to the parent nameservers isn’t good (because it minimizes unnecessary queries to the parent nameservers).

Back in Chapter 4, we talked about two types of nameservers: primary nameservers and slave nameservers. But what if you don’t want to run a nameserver on a host, yet still want to use DNS? Or, for that matter, what if you can’t run a nameserver on a host (because the operating system doesn’t support it, for example)? Surely, you don’t have to run a nameserver on every host, right?

No, of course you don’t. By default, the resolver looks for a nameserver running on the local host—which is why we could use nslookup on toystory.movie.edu and wormhole.movie.edu right after we configured their nameservers. You can, however, instruct the resolver to look to another host for name service. This configuration is called a DNS client in the BIND Operations Guide.

The nameserver directive (yep, all one word) tells the resolver the IP address of a nameserver to query. For example, the line:

nameserver 15.32.17.2

instructs the resolver to send queries to the nameserver running at the IP address 15.32.17.2 instead of to the local host. This means that on hosts not running nameservers, you can use the nameserver directive to point them at a remote nameserver. Typically, you configure the resolvers on your hosts to query your own nameservers.

However, since many nameserver administrators don’t restrict queries, you can configure your resolver to query someone else’s nameserver. Of course, configuring your host to use someone else’s nameserver 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.

You can also configure the resolver to query the host’s local nameserver using either the local host’s IP address or the zero address. The zero address, 0.0.0.0, is interpreted by most TCP/IP implementations to mean “this host.” The host’s real IP address, of course, also means “this host.” On hosts that don’t understand the zero address, you can use the loopback address, 127.0.0.1.

Now what if the nameserver your resolver queries is down? Isn’t there any way to specify a backup? Do you just fall back to using the host table?

The resolver allows you to specify up to three (count ‘em, three) nameservers by using multiple nameserver directives. The resolver queries those nameservers, in the order listed, until it receives an answer or times out. For example, the lines:

nameserver 15.32.17.2
nameserver 15.32.17.4

tell the resolver to first query the nameserver at 15.32.17.2, and if it doesn’t respond, to query the nameserver at 15.32.17.4. Be aware that the number of nameservers you configure dictates other aspects of the resolver’s behavior, too.

%telnet tootsie
tootsie: Host name lookup failure

The sortlist directive is a mechanism in BIND 4.9 and later resolvers that lets you specify subnets and networks for the resolver to prefer if it receives multiple addresses as the result of a query. In some cases, you’ll want your host to use a particular network to get to certain destinations. For example, say your workstation and your NFS server have two network interfaces each: one on a standard 100 Mbps Ethernet segment, subnet 128.32.1/24, and one on a gigabit Ethernet segment, subnet 128.32.42/24. If you leave your workstation’s resolver to its own devices, it’s anybody’s guess which of the NFS server’s IP addresses you’ll use when you mount a filesystem from the server—presumably, the first one in a reply packet from the nameserver. To make sure you try the interface on the gigabit Ethernet first, you can add a sortlist directive to resolv.conf that sorts the address on 128.32.42/24 to the preferred position in the structure passed back to programs:

sortlist 128.32.42.0/255.255.255.0

The argument after the slash is the subnet mask for the subnet in question. To prefer an entire network, you can omit the slash and the subnet mask:

sortlist 128.32.0.0

The resolver then assumes you mean the entire network 128.32/16. (The resolver derives the default unsubnetted net mask for the network from the first two bits of the IP address.)

And, of course, you can specify several (up to 10) subnets and networks to prefer over others:

sortlist 128.32.42.0/255.255.255.0 15.0.0.0

The resolver sorts any addresses in a reply that match these arguments into the order in which they appear in the directive, and appends addresses that don’t match to the end.

The options directive was introduced with BIND 4.9 and lets you tweak several internal resolver settings. The first is the debug flag, RES_DEBUG. The directive:

options debug

sets RES_DEBUG, producing lots of exciting debugging information on standard output, assuming your resolver was configured with DEBUG defined. (Actually, that may not be a good assumption because most vendors compile their stock resolvers without DEBUG defined.) This is very useful if you’re attempting to diagnose a problem with your resolver or with name service in general, but very annoying otherwise.

The second setting you can modify is ndots, which sets the minimum number of dots a domain name argument must have for the resolver to look it up before applying the search list. By default, one or more dots will do; this is equivalent to ndots:1. The resolver first tries the domain name as typed as long as the name has any dots in it. You can raise the threshold if you believe your users are more likely to type partial domain names that will need the search list applied. For example, if your local domain name is mit.edu, and your users are accustomed to typing:

%ftp prep.ai

and having mit.edu automatically appended to produce prep.ai.mit.edu, you may want to raise ndots to 2 so that your users won’t unwittingly cause lookups to the root nameservers for names in the top-level ai domain. You could do this with:

options ndots:2

BIND 8.2 introduced four new resolver options: attempts, timeout, rotate, and no-check-names. attempts allows you to specify how many queries the resolver should send to each nameserver in resolv.conf before giving up. If you think the new default value, 2, is too low for your nameservers, you can boost it back to 4, the default value before BIND 8.2.1, with:

options attempts:4

The maximum value is 5.

timeout allows you to specify the initial timeout for a query to a nameserver in resolv.conf. The default value is five seconds. If you’d like your resolver to retransmit more quickly, you can lower the timeout to two seconds with:

options timeout:2

The maximum value is 30 seconds. For the second and successive rounds of queries, the resolver still doubles the initial timeout and divides by the number of nameservers in resolv.conf.

rotate lets your resolver use all the nameservers in resolv.conf, not just the first one. In normal operation, if your resolver’s first nameserver is healthy, it’ll service all your resolver’s queries. Unless that nameserver gets very busy or goes down, your resolver will never query the second or third nameservers in resolv.conf. If you’d like to spread the load around, you can set:

options rotate

to have each instance of the resolver rotate the order in which it uses the nameservers in resolv.conf. In other words, an instance of the resolver still queries the first nameserver in resolv.conf first, but for the next domain name it looks up, it queries the second nameserver first, and so on.

Note that many programs can’t take advantage of this because they initialize the resolver, look up a name, then exit. Rotation has no effect on repeated ping commands, for example, because each ping process initializes the resolver, queries the first nameserver in resolv.conf, and then exits before using the resolver again. Each successive invocation of ping has no idea which nameserver the previous one used—or even that ping was run earlier. But long-lived processes that send lots of queries, such as a sendmail daemon, can take advantage of rotation.

Rotation can also make debugging trickier. If you use it, you’ll never be sure which nameserver in resolv.conf your sendmail daemon queried when it received that funky response.

no-check-names, finally, allows you to turn off the resolver’s name checking, which is on by default.^[*] These routines examine domain names in responses to make sure they adhere to Internet host-naming standards, which allow only alphanumerics and dashes in hostnames. You’ll need to set this if you want your users to be able to resolve domain names with underscores or nonalphanumeric characters in them.

If you want to specify multiple options, combine them on a single line in resolv.conf, like so:

options attempts:4 timeout:2 ndots:2

Also introduced with BIND 4.9 resolvers (and it’s about time, if you ask us), is the ability to put comments in the resolv.conf file. Lines that begin with a pound sign or semicolon in the first column are interpreted as comments and ignored by the resolver.

If you’re just moving to a BIND 4.9 resolver, be careful when using the new directives. You may still have older resolver code statically linked into programs on your host. Often, this isn’t a problem because Unix resolvers ignore directives they don’t understand. However, don’t count on all programs on your host obeying the new directives.

If you’re running on a host with programs that include really old resolver code that doesn’t understand the search directive (i.e., older than 4.8.3) but you still want to use search with programs that can take advantage of it, here’s a trick: use both a domain directive and a search directive in resolv.conf, with the domain directive first. Old resolvers will read the domain directive and ignore the search directive because they won’t recognize it. New resolvers will read the domain directive, but the search directive will override its behavior.

We, as the administrators of movie.edu, have just been asked to configure a professor’s new standalone workstation, which doesn’t run a nameserver. Deciding which domain the workstation belongs in is easy: there’s only movie.edu to choose from. However, she is working with researchers at Pixar on new shading algorithms, so perhaps it’d be wise to put pixar.com in her workstation’s search list. The search directive:

search movie.edu pixar.com

makes movie.edu her workstation’s local domain name and searches pixar.com for names not found in movie.edu.

The new workstation is on the 192.249.249/24 network, so the closest nameservers are wormhole.movie.edu (192.249.249.1) and toystory.movie.edu (192.249.249.3). As a rule, you should configure hosts to use the closest nameserver available first. (The closest possible nameserver is a nameserver on the local host; the next closest is a nameserver on the same subnet or network.) In this case, both nameservers are equally close, but we know that wormhole.movie.edu is bigger (it’s a faster host, with more capacity). So the first nameserver directive in resolv.conf should be:

nameserver 192.249.249.1

Since this particular professor is known to get awfully vocal when she has problems with her computer, we’ll also add toystory.movie.edu (192.249.249.3) as a backup nameserver. That way, if wormhole.movie.edu is down for any reason, the professor’s workstation can still get name service (assuming toystory.movie.edu and the rest of the network are up).

The resolv.conf file ends up looking like this:

search movie.edu pixar.com
nameserver 192.249.249.1
nameserver 192.249.249.3

Next, we have to configure the university mail hub, postmanrings2x.movie.edu , to use domain name service. postmanrings2x.movie.edu is shared by all groups in movie.edu. We’ve recently configured a nameserver on the host to help cut down the load on the other nameservers, so we should make sure the resolver queries the nameserver on the local host first.

The simplest resolver configuration for this case is no configuration at all: don’t create a resolv.conf file, and let the resolver default to using the local nameserver. The hostname should be set to the full domain name of the host so that the resolver can determine the local domain name.

If we decide we need a backup nameserver—a prudent decision—we can use resolv.conf. Whether we configure a backup nameserver depends largely on the reliability of the local nameserver. A good implementation of the BIND nameserver will keep running for longer than some operating systems, so there may be no need for a backup. If the local nameserver has a history of problems, though—for example, it hangs occasionally and stops responding to queries—it’s a good idea to add a backup nameserver.

To add a backup nameserver, just list the local nameserver first in resolv.conf (at the host’s IP address or the zero address, 0.0.0.0—either will do), then one or two backup nameservers. Remember not to use the loopback address unless you know your system’s TCP/IP stack doesn’t have the problem we mentioned earlier.

Since we’d rather be safe than sorry, we’re going to add two backup nameservers. postmanrings2x.movie.edu is on the 192.249.249/24 network, too, so toystory.movie.edu and wormhole.movie.edu are its closest nameservers (besides its own). We’ll reverse the order in which they’re queried from the previous resolver-only example to help balance the load between the two.^[*] And because we’d rather not wait the full five seconds for the resolver to try the second nameserver, we’ll lower the timeout to two seconds. The resolv.conf file ends up looking like this:

domain movie.edu
nameserver 0.0.0.0
nameserver 192.249.249.3
nameserver 192.249.249.1
options timeout:2

As you’ve seen earlier in this chapter, programs such as telnet, ftp, rlogin, and rsh apply the search list to domain name arguments that aren’t dot-terminated. That means that if you’re in movie.edu (i.e., your local domain name is movie.edu, and your search list includes movie.edu), you can type either:

%telnet misery

or:

%telnet misery.movie.edu

or even:

%telnet misery.movie.edu.

and get to the same place. The same holds true for the other services, too. There’s one other behavioral difference you may benefit from: because a nameserver may return more than one IP address when you look up an address, modern versions of Telnet, FTP, and web browsers try to connect to the first address returned, and if the connection is refused or times out, for example, they try the next, and so on:

%ftp tootsie
ftp: connect to address 192.249.249.244: Connection timed out
Trying 192.253.253.244...
Connected to tootsie.movie.edu.
220 tootsie.movie.edu FTP server (Version 16.2 Fri Apr 26
    18:20:43 GMT 1991) ready.
Name (tootsie: guest):

And remember that with the resolv.conf sortlist directive, you can even control the order in which your applications try those IP addresses.

One oddball service is NFS. The mount command can handle domain names just fine, and you can put domain names into /etc/fstab (your vendor may call it /etc/checklist), too. But watch out for /etc/exports and /etc/netgroup. /etc/exports controls which filesystems you allow various clients to NFS-mount. You can also assign a name to a group of hosts in netgroup and then allow them access via exports using the name of the group.

Unfortunately, older versions of NFS don’t really use DNS to check exports or netgroup; the client tells the NFS server its identity in a Remote Procedure Call (RPC) packet. Consequently, the client’s identity is whatever the client claims it is, and the identity a host uses in Sun RPC is the local host’s hostname. So the name you use in either file needs to match the client’s hostname, which isn’t necessarily its domain name.

Some electronic mail programs, including sendmail, also don’t work as expected; sendmail doesn’t use the search list quite the same way that other programs do. Instead, when configured to use a nameserver, it uses a process called canonicalization to convert names in electronic mail addresses to fully qualified domain names.

In canonicalization, sendmail applies the search list to a name and looks up data of type ANY, which matches any type of record. sendmail uses the same rule newer resolvers do: if the name to canonicalize has at least one dot in it, check the name as-is first. If the nameserver queried finds a CNAME record (an alias), sendmail replaces the name looked up with the canonical name the alias points to and canonicalizes that (in case the target of the alias is itself an alias). If the nameserver queried finds an A record (an address), sendmail uses the domain name that resolved to the address as the canonical name. If the nameserver doesn’t find an address but does find one or more MX records, one of the following actions is performed:

sendmail uses canonicalization several times when processing an SMTP message; it canonicalizes the destination address and several fields in the SMTP headers.^[†]

sendmail also sets macro $w to the canonicalized hostname when the sendmail daemon starts up. So even if you set your hostname to a short, single-part name, sendmail canonicalizes the hostname using the search list defined in resolv.conf. sendmail then adds macro $w and all aliases for $w encountered during canonicalization to class $=w, the list of the mail server’s other names.

This is important because class $=w names are the only names sendmail recognizes, by default, as the local host’s name. sendmail will attempt to forward mail that’s addressed to a domain name it thinks isn’t local. So, for example, unless you configure sendmail to recognize all of the host’s aliases (by adding them to class w or fileclass w, as we showed in Chapter 5), the host will try to forward messages that arrive addressed to anything other than the canonical domain name.

There’s another important implication of class $=w, which is that sendmail recognizes only the contents of class $=w as the local host’s name in MX lists. Consequently, if you use anything other than a name you’re sure is in $=w on the right side of an MX record, you run the risk that the host will not recognize it. This can cause mail to loop and then be returned to the sender.

One last note on sendmail: when you start running a nameserver, if you’re running an older version of sendmail (before version 8), you should set the I option in your sendmail.cf file. Option I determines what sendmail does if a lookup for a destination host fails. When using /etc/hosts, a failed lookup is fatal. If you search the host table once for a name and don’t find it, it’s doubtful it’ll miraculously appear later, so the mailer may as well return the message. When using DNS, however, a lookup failure may be temporary, because of intermittent networking problems, for example. Setting option I instructs sendmail to queue mail if a lookup fails instead of returning it to the sender. Just add OI to your sendmail.cf file to set option I.

Once you start using DNS, you may also need to disambiguate hostnames in your host’s authorization files. Entries that use simple, one-part hostnames will now be assumed to be in the local domain. For example, the lpd.allow file on wormhole.movie.edu might include:

wormhole
toystory
monsters-inc
shrek
mash
twins

If we move mash and twins into the comedy.movie.edu zone, though, they won’t be allowed to access lpd; the entries in lpd.allow allow only mash.movie.edu and twins.movie.edu. So we have to add the proper domain names to hostnames outside the lpd server’s local domain:

wormhole
toystory
monsters-inc
shrek
mash.comedy.movie.edu
twins.comedy.movie.edu

Here are some other files you should check for hostnames in need of domain-ification:

hosts.equiv
.rhosts
X0.hosts
sendmail.cf

Sometimes, simply running these files through a canonicalization filter—a program that translates hostnames to domain names using the search list—is enough to disambiguate them. Here’s a very short canonicalization filter in Perl to help you out:

#!/usr/bin/perl -ap
# Expects one hostname per line, in the first field (a la .rhosts,
# X0.hosts)

s/$F[0]/$d/ if ($d)=gethostbyname $F[0];

Even if you cover all your bases and convert all your .rhosts, hosts.equiv, and sendmail.cf files after you configure your host to use DNS, your users will still have to adjust to using domain names. Hopefully, their confusion will be minimal and more than offset by the benefits of DNS.

One way to make your users’ lives less confusing after configuring DNS is to provide aliases for well-known hosts that are no longer reachable using their familiar names. For example, our users are accustomed to typing telnet doofy or rlogin doofy to get to the bulletin board system run by the movie studio on the other side of town. Now they’ll have to start using doofy’s full domain name, doofy.maroon.com. But most of our users don’t know the full domain name, and it’ll be some time before we can tell all of them and they get used to it.

Luckily, BIND lets you define aliases for your users. All we need to do is set the environment variable HOSTALIASES to the pathname of a file that contains mappings between aliases and domain names. For example, to set up a system-wide alias for doofy, we can set HOSTALIASES to /etc/host.aliases in the system’s shell startup files and add:

doofy    doofy.maroon.com

to /etc/host.aliases. The alias file format is simple: the alias starts the line in column one, followed by whitespace and then the domain name that corresponds to the alias. The domain name is written without a trailing dot, and the alias can’t contain any dots.

Now when our users type telnet doofy or rlogin doofy, the resolver transparently substitutes doofy.maroon.com for doofy in the nameserver query. The message the users see now looks something like:

Trying...
Connected to doofy.maroon.com.
Escape character is '^]'.
IRIX System V.3 (sgi)
login:

If the resolver falls back to using /etc/hosts, though, our HOSTALIASES won’t have any effect. So we should also keep a similar alias in /etc/hosts.

With time, and perhaps a little instruction, the users will start to associate the full domain name they see in the telnet banner with the bulletin board they use.

With HOSTALIASES, if you know the domain names your users are likely to have trouble with, you can save them a little frustration. If you don’t know which hosts they’re trying to get to, you can let your users create their own alias files, and have each user point the HOSTALIASES variable in his shell startup file to his personal alias file.

/etc/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 nameserver) 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:

For each criterion, 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 can use:

hosts:  dns [NOTFOUND=return] files

The Windows XP resolver stores every record it receives in a shared cache available to all programs on the system. The resolver also obeys the TTL field of resource records it caches, up to a maximum of 24 hours by default. So if a record specifies a TTL longer than that, the resolver rounds down to 24 hours. This maximum TTL is configurable with a Registry setting:

MaxCacheTtl
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSCacheParameters
Data type: REG_DWORD

Default value: 86,400 seconds (= 24 hours)

The Windows XP resolver also supports negative caching. Windows XP caches negative responses for 15 minutes by default. This negative caching timeout is also configurable with a Registry setting:

MaxNegativeCacheTtl
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSCacheParameters
Data type: REG_DWORD

Default value: 900 seconds (= 15 minutes)

To disable negative caching altogether, set this value to 0.

To view the resolver’s cache, use ipconfig /displaydns. To clear the cache, type ipconfig /flushdns. To disable caching on Windows XP, you can use the command:

C:> net stop dnscache

However, this lasts only until the next reboot. To disable caching permanently, go to Services (in the Administrative Tools program group) and set the DNS Client service’s Startup type to Disabled.

This feature is analogous to the BIND resolver’s address-sorting feature. When the resolver receives multiple address records for the same domain name, it examines the IP address in each record and adjusts the order of the records before returning the list to the calling application: any records with IP addresses on the same subnets as the host on which the resolver is running are moved to the top of the list. Since most applications use addresses in the order returned by the resolver, this behavior causes traffic to remain on local networks.

For example, Movie U. has two mirrored web servers on two different subnets:

www.movie.edu.   IN  A  192.253.253.101
www.movie.edu.   IN  A  192.249.249.101

Let’s say the resolver on toystory.movie.edu (192.249.249.3) sends a query and receives these records. It sorts the record with address 192.249.249.101 to the top of the list because toystory shares a network with that address.

Note that this behavior defeats the round-robin feature implemented by most nameservers. Round robin refers to the nameserver behavior of rotating the order of multiple address records in successive responses to distribute the load among the servers (again taking advantage of the behavior of most applications to use the first address in the list returned by the resolver). With subnet prioritization enabled, the order of the records is subject to shuffling by the resolver. You can disable subnet prioritization with a Registry setting:

PrioritizeRecordData
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSCacheParameters
Data type: REG_DWORD
Range: 0 - 1
Default value: 1 (Subnet prioritization enabled)