Communicating with systems that don't understand WINS
This month I have two agendas: to finish up Windows Internet Name Service
(WINS) once and--I hope--for all, and to pass along a smile and some
consternation about some upcoming Microsoft releases of Exchange, Windows
NT, and Windows. Last month I discussed push and pull partners in WINS; you need
this information if you're going to build a large IP-based network of NT and
Windows 95 systems. (For more about WINS, see David Lafferty, "Resolving
Names with WINS," and Darren Mar-Elia's upcoming November
article, "Implementing Enterprisewide WINS.")
But how will your network's systems that don't understand WINS resolve
NetBIOS names? With a WINS proxy agent (WPA).
Suppose you have a domain named US on an intranet with two subnets (call
them A and B). Your only domain controller is on B (the only WINS server), and
you have a workstation on A that doesn't know how to use WINS. Someone tries to
log on to the domain from the workstation on A, so the workstation must find a
domain controller. Therefore, the workstation broadcasts, "Does anyone out
there have the name US<1C>?" (Recall that <1C> is the suffix
that indicates that a machine is a domain controller and can act as a logon
server.) Because the workstation is broadcasting and broadcasts don't
cross routers, the name resolution request will never reach across to subnet B.
Therefore, the domain controller will never respond, and the domain logon will
never happen.
(While I'm on the subject, let me answer a common question. If you don't
use WINS or LMHOSTS, and if you select Use DNS for Windows Name Resolution,
Domain Name System (DNS) will not be able to locate domain controllers.
DNS can find machine names, but DNS can't understand suffixes such as <1C>,
so it can't find domain controllers. The DNS with NT 5.0 can find
special kinds of servers, however, because of RFC 2052 and a new resource record
type.)
Suppose, however, that a WINS-aware machine is on subnet A. Suppose, too,
that the machine is a kind of good samaritan. It hears the workstation's
plaintive cry and repeats the <1C> request, but instead makes the request
to the WINS server on subnet B. The WINS server on B says to the good samaritan,
"I'm here at address X." The good samaritan then relays the response
to the workstation, and the workstation can now locate the domain controller
even though the domain controller is on a different subnet. The good samaritan
is a WPA.
WPAs also help with name registrations. Suppose our workstation has been
named WORKSTATION, but another machine has the same name. Usually, a
non-WINS-aware machine tries to ensure that it has a unique name by broadcasting
the name on startup, saying in effect, "I think my name is
WORKSTATION, but if anyone already uses that name, better tell me now." If
another WORKSTATION on the same subnet has the same name, it will reply, "No,
I've already got that name."
But if the other machine is on another subnet, how will it know that a name
collision has occurred? Usually WINS will tell it, but that service is no help
if the machine registering the name doesn't use WINS. The WPA can help here,
too. When a non-WINS-aware machine broadcasts a name registration, the WPA looks
up that name with the WINS server. If WINS reports a conflict, the WPA acts on
behalf of the WINS server and responds saying, "No, you can't use that
name; I'm using it."
Oddly enough, WPAs help only with name resolution and name registration
conflicts. If a machine named ORANGE on subnet A registers a name, the WPA on A
ensures that the name ORANGE doesn't conflict with any names that the WINS
server on B knows. But the WPA doesn't register the name with WINS; the
WPA just check for conflicts. As a result, the non-WINS-aware workstation named
ORANGE on subnet A registers its name just fine at, let's say, 8:00 a.m. Then if
a workstation on B tries to register the name ORANGE, the WPA won't challenge
the name. Whether the ORANGE on B registers its name via a broadcast or via
WINS, the WPA won't notice the conflict because the WPA checks for a name
collision only when the ORANGE on A starts up. Even with WPA computers, running
a network that combines WINS-aware and non-WINS-aware machines can be a bit
tricky.
Further, suppose the ORANGE on subnet B, the same subnet as the WINS
server, is also not WINS-aware and registers its name through a broadcast.
Because the WINS server is on the same subnet, it hears the broadcast--but does
it put that name registration in the WINS database? Again, oddly, no.
Previous
Register
