11.2 WINS Linkage

Our next topic requires a short detour into the world of Microsoft networking. Networks based on NetBT (NetBIOS over TCP) need to perform name resolution, too: hosts need a way to map NetBIOS names^[3] to IP addresses. The way this name resolution works has evolved over time. In the early days, hosts broadcasted a query on the LAN to resolve a NetBIOS name. This forced all hosts to listen to every broadcast. Since broadcasts don't leave the local LAN, this method didn't allow name resolution beyond the local network segment. The next evolutionary step was the LMHOSTS file, which is just a list of NetBIOS names and IP addresses. Every host needed an LMHOSTS file to resolve names beyond the local subnet. This model didn't scale very well, either: it was tough to keep the LMHOSTS files up to date and distribute them. And the introduction of the Dynamic Host Configuration Protocol (DHCP) essentially made basing a network's NetBIOS name resolution on LMHOSTS files impossible.

^[3] A host's NetBIOS name is simply the name by which it's known for NetBT networking purposes. NetBIOS names are limited to one label of up to 15 octets (that is, no multiple-label names like DNS domain names). On Windows Server 2003 systems, a host's NetBIOS name is derived automatically from the host's fully qualified DNS name, which is called the computer name and is set in the System Properties window's Computer Name tab (choose Control Panel System). The NetBIOS name is forced to be the first label (i.e., everything to the left of the leftmost dot) of the host's DNS name. Windows 2000 allowed the NetBIOS name to be different from the DNS name, but that feature didn't carry over to Windows Server 2003.

A detailed description of DHCP is beyond the scope of this book,^[4] but suffice it to say that DHCP eliminates the requirement of configuring a static IP address on every one of your hosts. If those hosts support DHCP, they can contact a DHCP server when they boot to obtain an IP address and other configuration parameters, such as the IP addresses of the default router, name servers, and WINS servers.

^[4] But see another book from O'Reilly: TCP/IP Network Administration by Craig Hunt.

WINS, which stands for Windows Internet Naming Service, is a Microsoft invention introduced in Windows NT 3.5. The server component of WINS is an implementation of a NetBIOS Name Server as described in RFCs 1001 and 1002. The idea is nothing new; the RFCs date from early 1987. The function of a NetBIOS Name Server is simple: it maps NetBIOS names to IP addresses.

The name and IP address information in a WINS server comes from the various hosts on the network. Once a host sets its IP address using the value sent by a DHCP server, the host registers its name with the WINS server the DHCP server told it about. Actually, any modern NetBT host registers its name with a WINS server (if it is configured to use a WINS server, of course), regardless of how it obtained its IP address (e.g., dynamically from a DHCP server or statically from a user-input configuration). Modern NetBT hosts also know to contact a WINS server for NetBIOS name resolution, rather than relying solely on broadcasting or an LMHOSTS file.

So where does DNS fit in to all this? Before Windows 2000's support of dynamic update, it wasn't possible to make the new name-to-IP address mappings generated by the DHCP server visible to DNS. Microsoft realized there would be some value to enabling a DNS server to query a WINS server, which knows about names for dynamically assigned IP addresses. After all, a NetBIOS name in the WINS server is usually the same as a machine's hostname (the first label of its fully qualified domain name in DNS), which is what it would be in the DNS server if there were an easy way to get it there. (Remember, we're talking about the days before Windows 2000 with its improved integration with DNS.) So a Microsoft DNS Server can be configured to ask a WINS server when it receives a query for a domain name that's not in its zone data.

You may be thinking that a name server contacting a WINS server is kind of silly; isn't there a way for name servers to know what the DHCP servers are doing directly? There is. In a network with Windows 2000 or Windows Server 2003, DHCP servers can update name servers using dynamic update after every address assignment, as we discussed earlier in this chapter. The importance of WINS in recent versions of Windows (Windows 2000 and Windows Server 2003) is greatly reduced, too. Modern Windows hosts allow domain names (which are resolved with DNS) to be used in places where previously only NetBIOS names (typically resolved with WINS) were allowed. WINS is still required to support older, legacy clients. You can find more information about how modern Windows hosts use DNS for hostname lookups in Chapter 6.

11.2.1 Configuring WINS Lookup

WINS lookup, as it's called, is enabled on a zone-by-zone basis using the WINS tab of a forward zone's properties window. When the DNS server receives an address (A) record query for which it doesn't know the answer, if the zone where the record would exist has WINS lookup enabled, the DNS server queries a WINS server. The NetBIOS name sent to the WINS server is the first label of the domain name in the A record query. For example, if the domain name in the A record query is terminator.movie.edu, the NetBIOS name queried is terminator. If the WINS server responds with an IP address for terminator, the DNS server synthesizes an A record for terminator.movie.edu and returns it to the original querier.

The WINS lookup configuration for the movie.edu zone on the zone's primary, terminator, is shown in Figure 11-6.

Figure 11-6. WINS lookup settings for movie.edu

WINS lookup is enabled by checking the Use WINS forward lookup box. You can specify the IP addresses of up to eight WINS servers, and the DNS server will try them in the order listed.

By default, the WINS lookup configuration you establish on the primary takes effect on the secondaries as well. The primary inserts a special WINS record that gets transferred with the rest of the zone to the secondaries. If the secondaries are Microsoft DNS Servers, they understand the WINS record and perform WINS lookups accordingly. If the secondaries are BIND name servers, they complain about the unknown WINS record. You can suppress sending this WINS record to the secondaries by checking Do not replicate this record.

The Time to live (TTL) field in the lower left corner specifies the TTL for the synthesized A records that result from WINS lookups.

Pressing the Advanced button yields a window like that in Figure 11-7. Cache time-out controls how long the DNS server will cache the synthesized A records. The default value is 15 minutes. That value may seem small, but it's a good choice: information in the WINS server is transient by nature, so you don't want the DNS server to hold onto it for a long time. If it needs a name again, the DNS server can just ask the WINS server for it. Lookup time-out controls how long the DNS server will wait after querying a WINS server. The default is 2 seconds.

Figure 11-7. Advanced WINS lookup settings

You can enable WINS lookup on in-addr.arpa zones, too. It's called WINS reverse lookup, and it's implemented differently than plain WINS lookup. When the name server receives a PTR query it can't answer and WINS reverse lookup is enabled for the zone, it sends a NetBIOS Adapter Status request directly to the IP address referenced by the PTR record. In other words, the name server asks the host directly what its name is. The name server can't ask a WINS server because lookups based on IP address aren't supported: you can't give a WINS server an IP address and get the corresponding NetBIOS name back. WINS servers have obviously never heard of Jeopardy! ("The host with IP address 192.249.249.3.," "What is terminator?")

WINS reverse lookup is configured similarly to WINS lookup: select the WINS-R tab of the zone properties window of any in-addr.arpa zone. The WINS reverse lookup configuration for the 249.249.192.in-addr.arpa zone on the zone's primary, terminator, is shown in Figure 11-8.

Figure 11-8. WINS reverse lookup settings for 249.249.192.in-addr.arpa

Use WINS-R lookup enables the NetBIOS Adapter Status requests for unknown PTR records in this zone. Do not replicate this record has the same effect as its WINS forward-lookup counterpart. If you look in an in-addr.arpa zone datafile, though, you'll see a WINS-R record instead of a WINS record. The Domain to append to returned name field takes a DNS domain name that will be appended to the NetBIOS name returned by the host to form a fully qualified domain name. The Advanced button controls cache and lookup timeouts, just like its WINS forward-lookup counterpart.

11.2.2 Using WINS Lookup and WINS Reverse Lookup

What's WINS lookup good for? In most networks, not a lot. For one thing, Windows Server 2003 integrates tightly with DNS so that in a properly configured network, all Windows hosts have forward- and reverse-mapping information in DNS. (More information about this new integration with DNS is found in Chapter 8.) But let's say you still have a lot of older Windows hosts on your network. Do you need WINS lookup? Well, we still can't get excited about it. Think about it this way: the names that get resolved the most are the servers, and they usually have fixed IP addresses and thus static DNS entries. They're resolved directly in DNS, not via the WINS lookup detour. Most networks don't have much peer-to-peer networking; your average desktop host usually doesn't offer network services, such as a web server, name server, and so on. It's the need to reach those kinds of network services that requires DNS name resolution to work for every host. (Sure, there's a lot of NetBIOS-based file and print sharing among desktop hosts, but that process uses WINS natively.)

If you do need to support WINS lookup in your network, a big problem with it is that the standard BIND name server doesn't support it.^[5] Many people find that they need WINS lookup after they have a DNS infrastructure in place using BIND name servers. One option is to replace all those name servers with the Microsoft DNS Server and enable WINS lookup. That's not realistic for most people. A better, but not perfect, option is to create a new subdomain for DHCP clients resolvable via WINS lookup and delegate the subdomain to a set of Microsoft DNS Servers.

^[5] MetaInfo, a subsidiary of Check Point, has ported BIND to Windows and added WINS lookup and WINS reverse lookup. See http://www.metainfo.com/.

For example, let's say the folks running the domain acme.com suddenly find themselves with dozens of PCs doing peer-to-peer networking with DHCP-assigned IP addresses. Since they've already got a BIND infrastructure in place, they decide to create the domain pcs.acme.com for these PCs. (The domain name could be anything: dhcp.acme.com, wins.acme.com, whatever.) They configure a couple of Microsoft DNS Servers for this zone and enable WINS lookup. Finally, they delegate to the pcs.acme.com zone from the acme.com zone.

In practice, we find WINS reverse lookup is much more useful. It's really nice to have complete reverse-mapping information for your network in DNS. Network-management applications can report names rather than IP addresses. Web servers can log usage statistics by name and make named-based authorization decisions, such as giving access only to hosts in the movie.edu domain. Troubleshooting is easier as well. Without WINS reverse lookup, the name server can't reverse map dynamically assigned IP addresses in networks with older Windows hosts. Of course, for you to be able to use WINS reverse lookup in your network, all the name servers for your in-addr.arpa zones need to support it.