Integrating DNS and WINS

Since many networks running NT 4.0 relied on WINS as their primary name resolution facility, Microsoft provided a non-standard method for integrating DNS with WINS. This involved configuring a DNS server with special WINS-related records that would then be used to extend name resolution beyond the records known to DNS. In a nutshell, if configured with the address of a WINS server (using the non-standard WINS record), the DNS server would attempt to query WINS for any records not found in the DNS zone database file. It would do this by reformatting the request as a NetBIOS query, and the WINS server would respond if a match was found. This provided many companies with an efficient way to create a type of dynamic DNS in NT 4, since clients whose IP addresses were not in DNS (since they used DHCP) could still be found via DNS, since WINS is updated dynamically.

This same functionality still exists in Windows 2000, even though dynamic DNS now exists. Remember that non-Windows 2000 clients still do not use dynamic DNS, and many companies have large WINS implementations that work quiet well, and as such, might wish to continue using this rather than switching to DHCP-initiated client updates. Before looking at how integration between WINS and DNS should be handled, remember that a DNS query is resolved by a DNS server that is authoritative for the zone within which a DNS domain exists. That is, a name server whose zone is responsible for the domain will answer a query for The reason that I mention this is because the placement of the WINS records will differ based on a company’s DNS implementation.

For example, imagine that my company has set up DNS to support Active Directory, and my implementation is such that only records for domain controllers appear in DNS. If I configure my single DNS forward lookup zone with a WINS record pointing to my WINS server, this WINS server will be queried if the associated host record is not found in DNS. While this works fine for a single forward lookup zone, it becomes more complex when my company has many domains in its DNS implementation (perhaps because of a large multi-domain AD design). In cases like these, you might want every forward lookup zone to be configured to do WINS resolution, and this might involve a great deal of administration. For this reason, Microsoft recommends creating a separate Active Directory domain strictly for the purpose of WINS resolution. At first glace this may not may sense, so let me explain. In the Advanced TCP/IP properties of a system (on the DNS tab, as shown below), you can control the order in which domains are searched for the purpose of name resolution. By default, the suffix for the domain in which the local system exists is searched, followed by parent domains. For example, imagine you typed ping server3. If the client system from which the command was issued was in the domain, it would first try resolving (notice is automatically appends the domain name since you didn’t use an FQDN). If this fails, it will then attempt (appending the suffixes of the parent domain – If this also fails to resolve the name, resolution fails.

Consider what would happen if you were to create a separate DNS domain just for WINS resolution, however. You might create a special domain within your DNS structure called, and have this be the second domain appended in a search to resolve a hostname.

Now, if a client were to attempt to ping an unqualified hostname, like server3, it would first attempt to query followed by The idea is that if an answer could not be found in subdomain ‘west’, it would then attempt subdomain ‘wins’. The forward lookup zone for subdomain ‘wins’ would only need to be configured with 1 (or more) WINS records (and WINS-R records in the associated reverse lookup zone), pointing to the appropriate WINS servers where clients and servers are registered. This setup is best when you have many domains and/or subdomains, where client DNS properties are set to query their own domain first, followed by the special ‘wins’ domain second, thereby making use of the existing WINS facility for resolution.

Author: Dan DiNicolo

Dan DiNicolo is a freelance author, consultant, trainer, and the managing editor of He is the author of the CCNA Study Guide found on this site, as well as many books including the PC Magazine titles Windows XP Security Solutions and Windows Vista Security Solutions. Click here to contact Dan.