WINS, DHCP, and DNS

Windows Internet Naming Service (WINS) in Windows Server 2003 is largely unchanged from Windows 2000. There are some minor display improvements primarily for performance, but the service itself functions the same. Dynamic Host Configuration Protocol (DHCP) introduces a few new management features, but it too is largely unchanged. Domain Naming Service (DNS), on the other hand, has some significant improvements.

WINS

WINS is the service used for locating network basic input output system (NetBIOS) resources. It provides a dynamic database for maintaining associations between NetBIOS names and Internet Protocol (IP) addresses. The changes to the WINS service in Windows Server 2003 are primarily enhancement to the Microsoft Management Console (MMC) snap-in for administering WINS. The first notable improvement is in the way WINS records are displayed. In Windows 2000 you had to choose which records to display in the console. You could select to find records by name , owner (the WINS server on which the record was created), or type (which was a sub-choice of finding by owner). It is pretty much the same in Windows Server 2003, but now you simply select Display Records and enter the criteria for the records to display: by Record Owner; by Record Type ; or by Record Mapping . Filtering by record mapping includes filtering by name, by IP address, or both. The real improvement is in what the console does when you choose to display the records.

When choosing to display records, you have an option labeled Enable Result Caching, as shown in Figure 8.1. If you don't select this check box, the query is run against the WINS server (or servers if multiple owners are queried) and the results are displayed. Subsequent queries are also run against the WINS servers(s). Depending on the size of the WINS database and the network connectivity between the servers, a significant delay could occur before displaying the results of each and every query as the query traverses the network. By selecting this check box, the WINS records are downloaded to the local machine and cached in memory. Subsequent queries can then find those records in memory without having to query the WINS server across the network again. Thus, with the results cached, subsequent queries to the same data are faster. The caveat is that if the WINS database is particularly large, the amount of memory consumed for caching can actually degrade performance. What actually gets cached depends on the query: If you query WINS records by owner, all the records from that owner are downloaded to the local machine and cached. Any subsequent queries for records from that owner are returned from the cache without querying the WINS server again ”the queries are faster but potentially outdated if anything has changed on the WINS server queried. If the WINS records are queried through a filter (by name, IP address, or type), only those records in the query result set are cached. Subsequent queries for the same result set (or subset) are cached, but queries for other records have to again access the WINS server (across the network).

Figure 8.1. Caching WINS results improves the performance of queries.

Another change in the WINS server is in the designation of valid replication partners. In previous versions of WINS, administrators had to manually configure push/pull partners to enable replication between two WINS servers. To ease this administrative burden , Windows 2000 introduced a new feature called Automatic Partner Configuration, which allows WINS servers to detect other WINS servers on the network and automatically configure push/pull relationships. If a lot of WINS servers are on the network, this autodiscovery and autoconfiguration could potentially lead to WINS replication chaos because any WINS server could replicate with any other WINS server. Administrators can gain some control over this by specifying a list of WINS servers from which a given WINS server would block replication of records. Windows Server 2003 improves on controlling Automatic Partner Configuration by enabling administrators to designate acceptance of records from particular owners. This is basically the same thing, but instead of having to specify all the servers with which you don't want to replicate, you can simply specify the few servers you do.

Note

The capability to block replication from particular WINS servers is not exclusive to Automatic Partner Configuration. You can block WINS servers even if you don't use Automatic Partner Configuration; however, there is really no reason to do so because you would be manually configuring the replication partnerships anyway. The new ability to specify servers from which to accept replication can also be used to improve the security of your WINS infrastructure. This could prevent someone from putting up a rogue WINS server and replicating with your WINS servers. Previously, the only way to do this was to find out the name or IP address of the rogue server and explicitly block it. However, by the time you have that kind of information, the damage has already been done.

For an introduction to WINS, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A010801 .

DHCP

DHCP is the service used to automatically issue IP addresses and configuration information. Like WINS, DHCP is largely unchanged in Windows Server 2003. Most of the improvements are with the DHCP service snap-in. One of the nicest enhancements is the capability to back up and restore the DHCP database right from the console. In previous editions, DHCP could be configured to back up its database; however, these configurations were performed either by modifying the Registry or with the netsh command. The netsh command still exists and is still used to configure an automated backup interval, but the DHCP snap-in now has the capability for performing a manual backup. More importantly, it provides an easy way to restore a corrupted DHCP database. Simply right-click the DHCP server, select Restore from the pop-up menu, and select the location from which to restore. It even prompts you to automatically restart the DHCP service to make the "new" database available.

Some additional niceties in the console are new descriptions on the Dynamic DNS tab, clarifying what each option does. Additionally, it provides the capability to specify the credentials used to authenticate to the DNS server for DNS dynamic updates. There is also a new predefined option (249 - classless static routes) that enables definition of static routes for configuring alternative routing paths over and above the default gateway.

There is a significant change in the Windows XP and Windows Server 2003 DHCP client. The Internet Protocol (TCP/IP) properties for the network adapter have a new Alternate Configuration tab that allows finer control over the Automatic Private IP Addressing feature. The Windows 2000 DHCP client introduced a new feature called Automatic Private IP Addressing (APIPA) . APIPA is the capability of the DHCP client to assign itself an IP address. Basically, if a Windows 2000 client configured for DHCP does not receive a response when it attempts to obtain a lease from a DHCP server, the client automatically assigns itself an IP address in the 169.254.x.x class B address range.

Note

If two clients assign themselves the same IP address, an IP address conflict occurs and one of the clients is incapable of communicating. To prevent this, the APIPA-configured DHCP client broadcasts the IP address it randomly picked. If it doesn't receive a response that anyone is using it, it assigns itself the IP address.

This is great for small businesses and SOHOs on a single network segment. Their clients can make up IP addresses and communicate without needing a DHCP server. In that environment, with everyone on the same subnet, all machines would use the 169.254.x.x address space and could communicate with each other.

Note

Clients using APIPA on the same subnet would not be able to communicate with anything off their local subnet, such as the Internet. They would have to use some type of proxy server of network address translation for that.

Although APIPA works well for small networks, it is not a very good option for large organizations that already have a DHCP infrastructure and multiple IP subnets. In such an environment, if a particular client comes up with a 169.254.x.x address, it might be able to communicate with other similar clients on its local subnet but not anything anywhere else, such as the servers, Internet, and so on.

By default, the APIPA configuration is enabled in Windows 2000 but can be turned off via a Registry key. It's just one more potential headache for administrators. With Windows XP and Windows Server 2003 the DHCP client still defaults to using APIPA, but now you can configure an alternative IP address to use instead of the randomly determined 169.254.x.x address. Basically, it's like being able to configure a static IP to use in the event the client cannot obtain a DHCP address. You can think of it as a static backup address for when DHCP is unavailable. One common application for the new Alternate Configuration feature is for laptop users. Their computers can be set to use DHCP when they're in the office and be programmed with a static address for use at the user 's home or other location.

Some administrators like to configure servers to use DHCP, too. They create a reservation in DHCP, so that the servers always get the same IP addresses, and rely on DHCP to change other IP configuration settings such as DNS servers, WINS servers, and so forth. However, if the DHCP server fails, servers might not obtain an IP address at all, which would interrupt network operations. By using the Alternate Configuration, you can take advantage of DHCP while still ensuring that servers will have an accurate IP address if the DHCP server isn't available.

For more information on the DHCP service, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A010802 .

DNS

DNS has received a minor makeover for Windows Server 2003, including how Windows Server 2003 handles Active Directory-integrated DNS zones and improvements to the DNS management console.

Active Directory-Integrated Zones

Probably the single greatest enhancement to the DNS service is a new feature of Active Directory (AD) integrated zones. Windows 2000 introduced Active Directory integrated zones, which store DNS records in the Active Directory database instead of in flat .dns files on the DNS server (like primary and secondary zones). The major benefit of an Active Directory-integrated zone is that your DNS records are replicated to all domain controllers, so in the event of a DNS server failure, you simply install DNS on a domain controller and the zone appears, as if by magic. In effect, any domain controller has the capability to become a DNS server, and your zone records are protected by Active Directory's replication.

Note

The usual implementation of Active Directory-integrated zones is with multiple domain controllers as DNS servers in a primary/secondary hierarchy. That way, if the primary DNS server goes offline or is too busy, the secondary can immediately take up the slack .)

The big drawback to the way Windows 2000 implements Active Directory-integrated zones is that all DNS records in the zone are replicated to every domain controller throughout your domain. This can potentially generate a lot of unnecessary network traffic because not every domain controller is a DNS server and therefore doesn't need the DNS zone replicated. With the new Active Directory Application Partitions in Windows Server 2003, the replication of the DNS information can be more finely controlled.

• For more information on the Active Directory Application Partitions, see "Replication Improvements," p. 75 .

When you use Active Directory Integrated zones on a Windows Server 2003 DNS server, Windows creates two application partitions ”one called DomainDNSZones and one called ForestDNSZones ”and used to replicate DNS information throughout the domain or forest. As shown in Figure 8.2, a given zone can be replicated as follows :

• To all DNS servers in the Active Directory forest.

• To all DNS servers in the Active Directory domain.

• To all domain controllers in the Active Directory domain. This is the only option compatible with replication to Windows 2000 domain controllers. Windows 2000 domain controllers know nothing about application partitions.

• To all domain controllers specified in the scope of the following application directory partition. This option enables you to load DNS into your own application partition (provided you have created one) for even tighter control of replication.

Figure 8.2. Windows Server 2003 enables you to control the scope of replication of Active Directory integrated zones.

Enhancements for DNS Hierarchy

Several enhancement to DNS provide additional flexibility for designing a DNS infrastructure. One such enhancement is a new zone type: stub zone. A stub zone is simply a copy of a DNS zone, like a secondary zone. The difference between a stub zone and a secondary zone is that a stub zone can contain glue records for delegated subdomains.

Tip

A stub zone, similar to a secondary zone, can be a standard zone or an Active Directory-integrated zone.

Glue records are references to servers that are authoritative for the subdomain. These records enable the DNS server to send a referral directly to the DNS server authoritative for the child domain without having to forward the request up the DNS hierarchy, only to have it come back down again.

Another new infrastructure design feature is the capability to designate forwarders on a per-domain basis. A forwarder is a pointer to a particular DNS server for sending unresolved queries. Ordinarily, if a DNS server is not authoritative for the zone referenced in a DNS query, it contacts or forwards the query to a root ('.') server, which then sends the query to successive child domains down the tree until it gets to the authoritative zone. Forwarders enable you to pass the request to other DNS servers which might potentially have or know about the zone without having to start at the root servers. This gives administrators some control over how queries will be resolved, allowing them to design DNS hierarchies to more efficiently respond to queries. A potential problem is that you might want queries for some domains to start at the root but want other domains to send the queries to your internal DNS servers. With Windows Server 2003, you can do both. You can specify individual domains (or all domains) to forward and specify to which servers they get forwarded. You can also specify whether to use recursion for queries to those domains.

Note

Recursion occurs when the DNS server contacts the subsequent DNS servers and returns the response to the client. With no recursion, the DNS server simply tells the client which DNS server to query and the client queries the new server itself.

DNS Console Improvements

Similar to the other core networking services, the DNS console in Windows Server 2003 sports some improvements. One nicety is that the built-in DNS console provided includes the event viewer snap-in with the DNS event log for monitoring DNS service messages. Additionally, a new option on the server pop-up menu ”Launch Nslookup ”launches the nslookup command-line utility for testing DNS query resolution. The Debug Logging tab has also been redesigned with more detailed configuration information. Also, a new tab is available for specifying the types of events to be written to the event log (previously only available through editing the Registry).

An additional security improvement is the capability to manage DNS server permissions at the server level. This enables you to delegate server-wide control of your DNS servers instead of just at the zone level, such as in Windows 2000.

For more information on DNS and how it works, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section, and locate article ID# A010803 .