Multiple WINS Servers Enhancement

[Christopher R. Hertel]

On Jul 7,  7:46am, Chris Young wrote:
:
> Have you ever managed an enterprise-level (if there is such a thing ;)
Windows
> NT network?  I'm certain that anyone who dealt with this will understand my
> point.

I manage a network of over 50,000 systems in over 200 subdomains (real domains,
not NT domains).  In an organization this size, WINS simply does not work.  We
do have a central WINS server which has, in the past three years, gone down two
or three times--typically due to the failure of some other service or device.
 Of course, it's running Samba.  On the other hand, very few people use it
since it represents an invalid NetBIOS namespace.

> Relying upon a single WINS server for an enterprise is NOT a good idea.
> No matter how poor WINS is, it becomes very neccessary in large
multi-network,
> routed environments (at least as far as Microsoft network clients go).

I think that the term "necessary" is being overused (and misspelled) a bit.
 WINS is a naming service.  It is a worth-while convenience and I'm not at all
trying to say that it isn't important.  I'm being pedantic regarding the use of
the term "necessary".  The system will work without it.  It's just not pretty.

> Obviously, you can use DNS to make certain that name resolution happens for
> the key servers.

That is not obvious to me.  The DNS name space is separate from the NetBIOS
name space.  Microsoft encourages parallelism between the two for convenience,
but this is artificial and does not scale beyond a single DNS subdomain.
 Believe me, I've tried.

One beautiful example is that a Windows system, when doing a reverse lookup on
an IP address, will attempt a NetBIOS Adapter Status Query before going to
reverse maps in the DNS.  There are some web server log file parsers out there
that run on Windows and generate thousands of these queries.  Of course, even
if they do get a response the domain name will not be included, and the NetBIOS
name is only valid within the union of the machine's local broadcast domain and
the set of systems sharing the WINS server.  I see dozens of blocked netbios-ns
packets on my home firewall each week.

Further, the machine name is not always the same as the service name.  Each
machine may have several NetBIOS names, each representing a separate
communications end-point.  A DNS name represents an IP address which represents
an interface.  A NetBIOS name represents a communications end-point, so:

    (NetBIOS Name) <=~=> (IP Address + Port Number)

That is, under IP the end point is represented by the combination of the IP
address and the port number.  Under NetBIOS the name does both.

So, the two name types are semantically different.

Going back to my original anal retentiveness, I'm questioning the use of the
term "necessary".  In addition to WINS there is local broadcast and the LMHosts
file.  Granted, neither of these does the full job.  I'm simply stating that
the system can work without WINS.  ...it's just not pretty...

> This alleviates alot of the problem, but not all.  Windows client
> depend upon NetBIOS name resolution as well as other services.  For instance,
> there are many products that use NetBIOS name resolution to associate a
logged
> in user with a workstation (hostname).  I'm not saying that this is the best
> way to do this.  I'm saying that it happens.

It's built into Windows, unfortuantely.

Note, though, that the username does become a registered NetBIOS name, as does
the machine name and the workgroup/NTdomain name.  Should the username also be
mapped to the DNS?  Hmm...

Again, I think 'depend' is too strong a word.  The service is used, but the
service consists of many parts and is not intended to be stable.  If a computer
on the LAN shuts down, its name should be released (or it will expire).  If a
Windows client "depends" on the name being resolved then the client has a
problem.  NBT was designed to be transient, and applications need to take this
into account.

> > If the WINS database is corrupted, what happens to the secondary WINS
> > server?  Hmmm...
>
> It becomes your only salvageable copy of the WINS database.  The bottom line
> is:
> IT HAPPENS!  Come on, apply some real world rules to this.  I know I've been

Sure it happens.  Fortunately, the NBNS system is designed to be dynamic and it
will recover.  Reset the WINS server and in a little while the names will start
to show up again.

Read the RFCs.  The system we are talking about was designed a long, long time
ago to emulate a small (80-node absolute max) LAN over a routed IP network.
 It's like emulating a C64 on a Beowolf cluster (which can be done, btw).

> in
> this scenario before.  Now, that I work primarily with Linux and Samba, I
> don't
> deal with these issues.

Well, there you go. :)

Microsoft added WINS replication and the secondary fail-over to add a little
robustness.  As you've discovered, another way to do the same thing is to run
Samba.  :) :) :)

> Well, look like some other must agree with me that at least having this
option
> is a good idea (since it is in HEAD).  We're all not going to agree on these
> issues, so if you don't like it, don't use it.  That's why they are called
> 'options'. :)

It works for small, overlapping name spaces but it failes to scale and it has
security implications.  To use it, the admin needs to have a keen understanding
of both the DNS and the workings of NBT.

Example:  You have two DNS domains:  gruntwork.corporate.com and
slavepit.corporate.com.  You might want machines in these two domains to be
able to share files via CIFS.  Take two machines, one in each subdomain.  Call
them A and B for lack of creativity.

These register in WINS as 'A' and 'B'.  Their DNS names are
a.gruntwork.corporate.com and b.slavepit.corporate.com... except that they're
also in WINS.  What's the DNS domain for the WINS server?  How will a lookup
interpret this?  If names listed in the WINS server are assigned to slavepit,
the machine A has two conflicting DNS names.  This will cause trouble with
reverse map lookups, which are sometimes used to verify connection
authenticity.

If the WINS database can be entirely contained within a DNS domain, and can be
managed as authoritative for that domain (that is, name conflicts between DNS
entries and WINS entries can be resolved per stated policy) then this can be
made to work.  The better solution is to use DynamicDNS (*with* DNSSec) to
correctly register the names in the DNS.

The other problem, of course, is that it's easy to pollute a WINS database with
unauthorized entries.  I've seen this in the wild.  The cool thing is that you
can spoof the source address on the IP packets and, since you've got a trojan
in the WINS database, NetBIOS replies still go where you want them to go.  Neat
trick.

> > No, that's not the point.  Secondary WINS failover has never been added
> > because there hasn't been a lot of demand for it and because Samba
> > doesn't do WINS replication.  A patch makes it easy, of course.
>
> Huh?  You got me here.  Are you agreeing or disagreeing?

You and others read a lot into my original message which wasn't there.  My plan
was to add the patch to HEAD this evening or this weekend (time permitting).  I
needed to know if anyone had objections.

> Input was asked for. I gave mine. I think that coming at people in this
manner
> when they simply provide THEIR feedback (which was asked for) is rather
> disappointing.

Your reading is wildly different from mine.  I thought I said "Hey, I don't see
any big problems with this one.  Anyone have any objections?" and got back "You
idiot we desparately need this feature and Samba is broken without it."

That's the way it sounded to me, though I know that E'mail is a poor medium for
communicating such sentiments so I try to avoid judgement.  I really thought my
reply was polite, if somewhat pedantic.

I've been asking folks for about two years now if anyone wanted WINS
replication.  JF started on it once.  We all lost interest because there was no
one saying 'yes, please'.

> This will do nothing but discourage people from providing
> feedback for a piece of software that many of us rely on heavily.

It'll really discourage me from asking for feedback before I make a change.

> Isn't feedback supposed to be one of the major benefits of Open Source or
> is ESR wrong?

Doctrine of Authority... (but then, I'm something of an academic).

For what it's worth, all sides of this conversation *are* feedback as far as I
can tell.  I'm simply trying to explain the technical aspects of the various
issues raised (you'll note that much of this discussion has little to do with
adding the secondary WINS feature).

The NBNS system is a particular area of study for me.  I've done some work on
the nmbd code, and I'm also working on a Java implementation.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services