17.9. DNS and WINS

In our first editionoh, for those simpler days!we mentioned the close alignment between NetBIOS names and domain names, but noted that, alas, there was no way for DNS to function as a NetBIOS nameserver. Basically, a nameserver would need to support dynamic updates to function as a NetBIOS nameserver.

Of course, BIND 8 and 9 do support dynamic updates. Unfortunately, neither NetBIOS clients nor WINS servers send dynamic updates to nameservers. WINS servers accept only the peculiar, proprietary dynamic updates sent by NetBIOS clients. In other words, a WINS server doesn't speak DNS.

However, Microsoft provides a nameserver, the Microsoft DNS Server, which in turn can talk to WINS servers. The Microsoft DNS Server has a nice graphical administration tool, as you would expect from Microsoft, and provides a handy hook into WINS: you can configure the server to query a WINS server for address data if it doesn't find the data in a DNS zone.

This is done by adding a new WINS record to the zone. The WINS record, like the SOA record, is attached to the zone's domain name. It acts as a flag to tell the Microsoft DNS Server to query a WINS server if it doesn't find an address for the name it's looking up. The record:

@        0       IN     WINS            192.249.249.39 192.253.253.39

tells the Microsoft DNS Server to query the WINS servers running at 192.249.249.39 and 192.253.253.39 (in that order) for the name. The zero TTL is a precaution against the record being looked up and cached.

There's also a companion WINS-R record that allows a Microsoft DNS Server to reverse-map IP addresses using a NetBIOS NBSTAT request. If an in-addr.arpa zone contains a WINS-R record such as:

@        0      IN      WINS-R          movie.edu

and the IP address sought doesn't appear in the zone, the nameserver attempts to send a NetBIOS NBSTAT request to the IP address being reverse-mapped. This amounts to calling a phone number and asking the person on the other end, "What's your name?" The nameserver then appends a dot and the domain name in the record-specific data, in this case ".movie.edu," to the result.

These records provide valuable glue between the two namespaces. Unfortunately, the integration isn't perfect. As they say, the devil is in the details.

The main problem, as we see it, is that only Microsoft DNS Servers support the WINS and WINS-R records. Therefore, if you want lookups in the fx.movie.edu zone to be relayed to the Special Effects Department's WINS server, then all fx.movie.edu nameservers must be Microsoft DNS Servers. Why? Imagine that the nameservers for fx.movie.edu were mixed, with some Microsoft DNS Servers and some BIND nameservers. If a remote nameserver tried to look up a NetBIOS name in fx.movie.edu, it would choose which of the fx.movie.edu nameservers to query according to round-trip time. If the server it happened to choose were a Microsoft DNS Server, it would be able to resolve the name to a dynamically assigned address. However, if it happened to choose a BIND nameserver, it wouldn't be able to resolve the name.

The best DNS-WINS configuration we've heard of so far puts all WINS-mapped data in its own zone, say wins.movie.edu. All the nameservers for wins.movie.edu are Microsoft DNS Servers, and the zone wins.movie.edu contains just an SOA record, NS records, and a WINS record pointing to the WINS servers for wins.movie.edu. This way, there's no chance of inconsistent answers between authoritative servers for the zone.

Reverse-mapping data, of course, can't easily be split into separate zones for BIND and Microsoft nameservers to maintain. So if you want both traditional, PTR record-based reverse mapping and WINS-R-enhanced reverse mapping, you'll need to host your reverse-mapping zones solely on Microsoft DNS Servers.

Another problem is that WINS and WINS-R are proprietary. BIND nameservers don't understand them, and, in fact, a BIND slave that transfers a WINS record from a Microsoft DNS Server primary master will fail to load the zone because WINS is an unknown type. (We discussed this, and how to work around it, in Chapter 14.)

The answer to these problems is the DNS standard dynamic update functionality that was first introduced in BIND 8 (described in Chapter 10) and the support for it in Windows 2000, Windows XP, and Windows Server 2003. Dynamic update allows the addition and deletion of records from a zone, which in turn gives the folks at Microsoft the functionality they need to use DNS as a name service for NetBIOS. So without further ado . . .