6.6. The Windows XP ResolverWe'll cover the resolver in Windows XP because most modern Windows resolversWindows 2000, Windows Server 2003look similar and act similarly. This resolver can be a little tough to find; its configuration is well hidden. To get to it, click on Start, then Control Panel, then Network and Internet Connections, then Network Connections. This brings up the window shown in Figure 6-1. Figure 6-1. Windows XP Network Connections
Right-click on Local Area Connection and choose Properties. This brings up a window like the one shown in Figure 6-2. Figure 6-2. Windows XP Local Area Connection Properties
Double-click on Internet Protocol (TCP/IP). This posts the basic resolver configuration window shown in Figure 6-3. Figure 6-3. Basic Windows XP resolver configuration
If you check the Obtain DNS server address automatically radio button, the resolver queries the nameservers 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 nameservers you specify in the Preferred DNS server and Alternate DNS server fields.[*]
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-4. Figure 6-4. Advanced Windows XP resolver configuration
If you've specified the addresses of nameservers 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:. The buttons allow you to add, edit, remove, and reorder the nameservers listed. There doesn't seem to be a limit to the number of nameservers you can list, but it doesn't make much sense to list more than three. The Windows XP resolver uses an aggressive retransmission algorithm first introduced in Windows NT 4.0 SP4: the resolver sends its first query to the first nameserver in the DNS Server Search Order. However, the resolver waits only one second before retransmitting the query and retransmits simultaneously to the first nameserver configured for each of the network adapters on the host. If after two more seconds the resolver doesn't receive a response, it simultaneously queries all the nameservers configured for all of the host's adaptersstatically configured, configured via DHCP, whatever. If none of those nameservers responds in four seconds, the resolver retransmits to all the nameservers again. It keeps doubling the timeout and retransmitting for a total of 4 retransmissions and 15 seconds. (See the Windows 2000 DNS white paper, at http://www.microsoft.com/windows2000/docs/w2kdns.doc, for details.) Since it's possible, in these days of split namespaces, to get two different answers from two different nameservers, the Windows XP resolver temporarily ignores negative answers (no such domain name and no such data) while querying multiple nameservers. Only if it receives a negative answer from a nameserver configured for each interface does it return a negative answer. If the resolver receives even a single positive answer from a nameserver, 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, or via a DHCP option sent by the DHCP server. The primary DNS suffix, on the other hand, is set in the Control Panel by clicking on System (from the Classic view), choosing the Computer Name tab, then clicking on Change . . ., then clicking on More . . . . This brings up the window shown in Figure 6-5. Figure 6-5. Configuring the primary DNS suffix in Windows XP
To set the Primary DNS suffix of this computer, enter it in the field below that label. By default, on computers that are members of an Active Directory domain, the primary DNS suffix is set to the AD domain's name. The checkbox labeled Append parent suffixes of the primary DNS suffix (see Figure 6-4) 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.edu and movie.edu. Note that connection-specific DNS suffixes aren't "devolved" (in Microsoft's words) into a search list, but if they're configured, connection-specific suffixes are 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 nameservers, 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 this client will try to use dynamic update to add an A record mapping its name to the address of this connection, and a PTR record mapping the address back to a name if it's a statically configured address. 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 featureautomatic registration is designed to ensure that the domain name of your Windows client always points to its current IP address, even if that address was delivered by a DHCP server. (For DHCP clients, 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 proprietaryand much malignedMicrosoft NetBIOS naming service. Once all your clients are running modern versions of Windows, 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. We discuss registration in more detail in Chapter 17. Allowing clients to dynamically update zones presents certain, er, challenges, though, which we'll explore in Chapter 17. 6.6.1. CachingThe 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_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters 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_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters 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. 6.6.2. Subnet PrioritizationThis 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_MACHINE\SYSTEM\CurrentControlSet\Services\DNSCache\Parameters Data type: REG_DWORD Range: 0 - 1 Default value: 1 (Subnet prioritization enabled) |