Полезная информация

DNS & BIND

DNS & BINDSearch this book
Previous: 15.8 DNS Versus X.500Chapter 15
Miscellaneous
Next: A. DNS Message Format and Resource Records
 

15.9 DNS and WINS

In our first edition, we mentioned the close alignment between NetBIOS names and DNS domain names, but noted that, alas, there was no way for DNS to function as a NetBIOS name server. Basically, a DNS name server would need to support dynamic updates to function as a NetBIOS name server.

Of course, BIND 8 supports dynamic updates. Unfortunately, Microsoft's DHCP server doesn't yet send dynamic updates to DNS server. It only talks to Microsoft's WINS servers. WINS servers handle dynamic updates, though only for NetBIOS clients. In other words, a WINS name server doesn't speak DNS.

However, Microsoft provides a DNS 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 with a new WINS record in the zone data file. The WINS record is attached to the zone's domain name, like the SOA record. 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 the data file for an in-addr.arpa zone contains a WINS-R record, like:

@        0      IN      WINS-R          movie.edu

and the IP address sought doesn't appear in the file, 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 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 name spaces. 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 WINS and WINS-R.[5] Therefore, if you want lookups in the fx.movie.edu zone to be tried on the Special Effects Department's WINS server, then all fx.movie.edu name servers must be Microsoft DNS Servers. Why? Imagine that the DNS servers for fx.movie.edu were mixed, some Microsoft DNS Servers and some BIND. If a remote DNS server needed to look up a NetBIOS name in fx.movie.edu, it would choose which of the fx.movie.edu DNS servers 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. But if it happened to choose a BIND server, it wouldn't be able to resolve the name.

[5] And a few commercial products, like MetaInfo's Meta IP/DNS, which is a port of BIND 8.1.1 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 DNS zone, say mobile.movie.edu. All the name servers for mobile.movie.edu are Microsoft DNS Servers, and the zone mobile.movie.edu contains just SOA records, NS records, and a WINS record pointing to the WINS servers for mobile.movie.edu. This way, there's no chance of inconsistent answers between authoritative servers for the zone.

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 greater detail in Chapter 13, Troubleshooting DNS and BIND.)

The answer to these problems is the DNS standard dynamic update functionality introduced in BIND 8, described in Chapter 10. Dynamic update will allow authorized addition, modification, 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. Microsoft has promised to do away with WINS and use standard DNS dynamic update with Windows NT 5.0. Whether they make good on their promise remains to be seen. We hope they do. It's hard enough to administer one naming service well.


Previous: 15.8 DNS Versus X.500DNS & BINDNext: A. DNS Message Format and Resource Records
15.8 DNS Versus X.500Book IndexA. DNS Message Format and Resource Records