Gone with the WINS

Windows 2000 replaces WINS with the superior DNS for host identification, but how will it play if you already have a Unix-based DNS?

Follow the discussion of WINS and DNS in the online forum.

Windows Internet Naming Service (WINS) has been, up to Windows NT 4, the preferred name service in the Windows environment. Now with Microsoft's move to the Domain Name System (DNS) in Windows 2000, administrators must adapt to a new mechanism.

Furthermore, users may be not be sure how to proceed with DNS in an enterprise where a Unix-based DNS already exists. Administrators may choose from three different approaches to solve this problem. But first, it's important to understand how Microsoft's DNS differs from WINS, and how it fits a Windows 2000 environment.

Why WINS?

In Windows NT domains, using WINS has some distinct advantages, including:

  • Low use of computer resources
  • Ease of configuration
  • High reliability
  • Dynamic registration of client's IP address at start-up
  • A replication partner to provide fault tolerance
  • Reduced network bandwidth use by reducing the broadcast for host localization

Furthermore, nonWindows clients can speak freely with the WINS server. This feature works in parallel with Microsoft's DNS.

In a Windows implementation, a proprietary record type is added, WINS (and WINS-R, for reverse WINS). This means that in your DNS zone, you can find records like:

@ WINS L2 C900 (10.1.2.3 10.1.2.4)

Where:

  • WINS is the record type
  • 10.1.2.3 and 10.1.2.4 are the IP Addresses of two WINS Servers
  • L2 means Lookup Time-out, default = 2seconds
  • C900 means Cache Time-out, default = 900 secs = 15 minutes

This record lets a DNS server query the WINS server if it can't fulfill the host lookup query. In this way a nonWindows client can query the DNS server using the regular host lookup mechanism, and the WINS server can give back the information to the DNS server and, finally, to the host. This is one example in which a proprietary extension to a public protocol allows interoperability with other operating systems.

Note, however, that in the zone transfer option of Microsoft DNS, there is an option to disable the transfer of these records to a non-Microsoft DNS. Therefore, you could have a Unix Bind server as a slave server in a zone where a Microsoft DNS server is the primary server.

The Problem with WINS

If WINS is fast, reliable and easy to configure, why did Microsoft turn to DNS? There are two reasons.

First, WINS suffers from a severe limitation that applies to any NetBIOS name server: It is impossible to have two computers with the same name. In that case, the system generates a conflict message at start-up, and the network layer is disabled on the faulty computer. This problem is called name collision. While this is not an issue in a workgroup of 10 users, it's likely to become one in a multinational company with 10,000 users.

The second reason for moving to DNS has to do with Windows 2000, which upgrades the Windows NT directory to a more powerful LDAP-based Active Directory (AD) system. AD uses Lightweight Directory Access Protocol (LDAP) to locate objects within a directory. Microsoft could have chosen to implement host localization with AD, but that would have required building a new host locating client. Instead, it chose DNS, a pre-existing, proven industry standard. (DNS was introduced in the early stages of the Internet by the Unix community, when the hosts file exchanged by the first hosts became too big to be transferred.)

Microsoft's DNS avoids the name collision problems in WINS. For example, suppose I have an AD tree in which two child domains exist: Corporateand Paris. With DNS, I can create a host named FileServer1 in both locations. In this scenario the two hosts share the same NetBIOS name, but their DNS names are different: fileserver1.corporate.avanade.com vs. fileserver1.paris.france.avanade.com.

It is still impossible to have two hosts with the same name in the same location, though. Doing so wouldn't be an issue with the host locating system, but the NetBIOS layer would prevent this from working correctly.

Microsoft vs. Unix DNS

While it's clear that DNS is more convenient to use in Windows 2000 (and further versions) than WINS in an all-Microsoft environment, administrators may question its use in a corporate network already running Unix DNS servers. Administrators have three options in this case: use the third-party DNS, use Microsoft's DNS or plan for a coexistence scenario.

Use Microsoft's DNS

This is the recommended scenario if you are designing your network from scratch. Microsoft has tightly integrated its DNS service with the AD so, naturally, this version is best suited for integration in a Windows 2000 environment. However, both the corporate DNS and AD DNS can be hosted on Microsoft's DNS Service.

Use a Third-Party DNS

You can use third-party DNS server implementations for the purpose of supporting AD. These other implementations must, however, support the following:

Dynamic DNS updates aren't mandatory, but they will add administrative overhead if an administrator must perform this task manually. Fortunately, Microsoft provides a way to secure dynamic updates.

Administrators can enable the Dynamic Host Configuration Protocol server that assigns IP address and other information to the client computers for dynamic DNS server updates while disabling this feature for the computers themselves. In this way, only the trusted host can perform updates.

If you're hesitating between a Unix-based DNS server and a Microsoft one, then consider that in Microsoft's DNS, zones can be integrated within AD. This brings two essential advantages over traditional DNS implementations in a Windows environment:

  • AD allows for multiple master servers, so there is no need for a slave DNS zone server to follow up the update request to the zone master, and each DNS server can be master of the same zone.
  • AD will allow the zone transfer to perform on an attribute basis, and not on a full zone basis.

This means that you have to consider only one replication design -- the AD -- while in a typical scenario you would also have to plan the DNS zone replication from master to slave servers.

Note, however, that BIND 8.1.2, the recommended version to use if Unix is to stay the DNS service, does support the required features, except for AD integration and secure updates.

Create a mixed DNS environment

If you want to use Microsoft DNS service but removing the corporate Unix DNS server isn't an option, consider delegation.

To do this, I might, for example, keep the corporate DNS zone for Avanade.com on a legacy Unix DNS server and then delegate corp.avanade.com to the Microsoft DNS service, and use corp.avanade.com as the company AD name. In this way, both environments can coexist. There are no special requirements for the legacy DNS servers, and they can even run BIND versions that AD doesn't support.

Whither WINS?

Microsoft won't abandon its support for WINS -- at least until Windows NT 4 ceases to exist in the enterprise. WINS is sometimes needed during migration, and some services in Windows 2000, such as clustering, rely on NetBIOS names. So, even if it's no longer choice for host localization in the enterprise, WINS is still to be considered in mixed NT4/Win2K environments.

Thierry Demorre is the senior Microsoft Systems consultant at Avanade Inc. in Seattle and specializes in technical infrastructures based on Windows 2000. Thierry has an 8-year background in Microsoft technologies and technical architecture, as well as expertise in technologies related to availability, scalability, security and optimization of Microsoft based Internet platforms. You can reach him at expertsecurite@avanade.com.

For more information:

About Microsoft DNS interoperability with other implementations see Microsoft's Migration Issues paper.

Relating to the WINS Service, read the Microsoft paper.

Copyright © 2002 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon