16.7 DNS and WINS

In our first edition—oh, 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 name server. Basically, a name server would need to support dynamic updates to function as a NetBIOS name server.

Of course, BIND 8 and 9 support dynamic updates. Unfortunately, the DHCP server in Windows NT 4.0 doesn't send dynamic updates to name servers. It talks only to Microsoft's WINS servers. WINS servers handle their own peculiar, proprietary dynamic updates, though only for NetBIOS clients. In other words, a WINS server doesn't speak DNS.

However, Microsoft provides a name server in Windows NT 4.0, 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.arpazone contains a WINS-R record, like:

@        0      IN      WINS-R          movie.edu

and the IP address sought doesn't appear in the zone, the name server will attempt 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 result has a dot and the domain name in the record-specific data appended, in this case ".movie.edu".

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 the Microsoft DNS Servers support the WINS and WINS-R records.^[2] 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 name servers must be Microsoft DNS Servers. Why? Imagine that the name servers for fx.movie.edu were mixed, some Microsoft DNS Servers and some BIND. If a remote name server needed to look up a NetBIOS name in fx.movie.edu, it would choose which of the fx.movie.edu name servers to query according to roundtrip 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. But if it happened to choose a BIND server, it wouldn't be able to resolve the name.

^[2] And a few commercial products such as MetaInfo's Meta IP/DNS, which is a port of BIND 8 with WINS capabilities added on. Stock BIND, however, can't talk to WINS servers.

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 name servers for wins.movie.edu are Microsoft DNS Servers, and the zone wins.movie.educontains 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 name servers 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 name servers 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 introduced in BIND 8, described in Chapter 10, and the support for it in Windows 2000. Dynamic update allows authorized addition and deletion of records in a BIND name server, 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 . . .