Re: DNS and Netbios name

In news:ua9Ng45TJHA.3952@xxxxxxxxxxxxxxxxxxxx,
A, Deji <deji@xxxxxxxxxxxxx> requesting assistance, typed the following:
Hi Ace, all is well here. Hope it's the same with you.

I would have PM'ed you on this response, but I want it to be public
in the hope that we could get a few contributions on from others on
it. I know that you did not mention SQL, Cluster, etc. I lumped those
in there because they are the most frequently mentioned when people
talk about applications/services/processes that NEED WINS.

I have found the claim of WINS dependency to be quite unsupportable
in all cases I have investigated. I know that there are a number of
articles, including KBs, out there that make this claim, and what I'm
trying to do here is publicly challenge those claims. An
application/process/whatever just wants to be able to locate a
corresponding partner on the other end of whatever
conversation/transaction it is engaged in at the time. If there is
any process/application that is specifically coded to REQUIRE a
specific method of locating such partners, I say that is a coding
error (an anomaly) and that the vendor needs to be presured to
re-code in a way that leverages the native name resolution scheme of
the underlying client OS.
It should NOT matter to the requesting party whether or not the
record is located on the other end of a cross-over cable or across
the ocean, it should simply request whatever it is looking for and
let the location/resolution facility built into the OS take care of
fulfilling the request. In all of the cases I have personally looked
at, this IS the behaviour. I cannot tell you how many "Exchange NEEDS
WINS" issues I have seen and resolved by encouraging the responsible
admin to simply add the Exchange Server's domain to the requesting
client's search list.
It is quite simple, really - at least IMO. The case is usually in a
forest with more than one domain, with the server/process/application
in one domain and the requesting client in the other. Server is named
(let's say) ServerA.DomainA.Forest.TLD and client is named
ClientB.DomainB.Forest.TLD. Client or server tries to talk to the
other using NetBIOS name.
Because Client is in DomainB.Forest.TLD, it will say "give me ServerA
in .DomainB.Forest.TLD". Since ServerA is NOT in DomainB.Forest.TLD,
ServerA doesn't receive that message. Client will ultimately try to
broadcast to whoever is within earshot that it is looking for
ServerA. Because .DomainB.Forest.TLD is the ONLY search suffix that
ClientB has, it will NEVER know to say "give me ServerA in
.DomainB.Forest.TLD". And, it does not matter if both ClientB and
ServerA were in the same network segment. ServerA will not know that
ClientB was desperately looking for it.
Now, add .DomainA.Forest.TLD to the suffix search list on ClientB and
see what happens. ClientB will now say "give me ServerA in
.DomainB.Forest.TLD". It will not find it, so it will go "OK, how
about ServerA in .DomainA.Forest.TLD".

Why does ClientB find ServerA when there is WINS in the picture?
Simple. Because ServerA publishes its record in WINS, and ClientB is
configured to ALSO ask WINS for records it is looking for. Depending
on the configuration, ClientB will usually either go straight to WINS
before asking DNS and then broadcasting.

Another question - why does ClientB ALWAYS find everything it is
looking for, even in a geographically-dispersed, WINS-less,
single-domain environment? Think about it.

Now, consider where there is WINS in the infrastructure BUT ClientB
is NOT configured to use WINS. ClientB will NEVER find ServerA,
regardless of how many WINS servers are in the infrastructure. So,
what is happening is not a WINS magic, it is just a resolution thing
whereby client will append the suffixes configured on them to every
query they issue, and will loop through all the configured suffixes
until they find the partner they are seeking.
This is what GNZ does in Windows Server 2008 DNS. It is a replacement
for WINS, although it is not automated in the same fashion as WINS.

My long-winded diatribe is my way of saying that IF the client is
given a way to locate the records it is looking for, it does NOT care
whether or not there is WINS anywhere. All it wants to do is find a
record. So, I'd be VERY VERY surprised IF Symantec actually coded an
application that insists on one particular for of naming resolution
facility. But, since I can't claim to have seen it all, I look
forward to your response, and may even try to see about getting a
Beta version of the product in question to verify.
Take care, man.

Deji


Hey, things aren't too bad on this end, other than just getting laid off this morning! Budgets... oh well. Expert help comes with a price! :-)

I agree 100% with your assessments and explanation. Understanding infrastructure resolution, it makes total sense. I hope everyone understands and helps them in their initial or decisions to change their designs.

Just to add, you mentioned the numerous articles out there concerning NetBIOS requirements. I think they were written based on making it easier for most admins to get it to work instead of the KBs going into detail trying to explain search suffixes, forwarding and other DNS resolution criteria. It makes sense and don't see why it wouldn't work. That one article I read about Backup Exec's ability to specifiy port ranges hints towards that as well without spelling it out.

The only thing that I had questions about is NetBIOS services and legacy applications. I remember years ago some apps looked for those NetBIOS specific services, but then again, being around all these years, it still sticks to the back of my mind, and newer and current apps now just look for a resolution, as you've stated. So I am happy with knowing and feeling like the current app devs no longer look for that. It's all well and good, and matter of fact simplifies name resolution across an infrastructure when you are using only one means to resolve, and that is DNS, since it's required by DNS, and will work with anything else if designed correctly with suffixes, forwarding, delegation, stubs, etc, where appropriate.

The only thing the client will miss, that is if they are used to it, is Network Neighborhood. They'll be able to access resources on their own via the neighborhood, but not if they are on other subnets. Printer browsing can be done by AD, so the Browser service wouldn't be needed in that case, but the neighborhood is the only exception.

Cheers man!

Ace

.

Relevant Pages

  • Re: DNS and Netbios name
    ... it will say "give me ServerA ... ClientB has, it will NEVER know to say "give me ServerA in ... what is happening is not a WINS magic, it is just a resolution thing ... whereby client will append the suffixes configured on them to every ...
    (microsoft.public.windows.server.dns)
  • Re: DNS and Netbios name
    ... If there is any process/application that is specifically coded to REQUIRE a specific method of locating such partners, I say that is a coding error and that the vendor needs to be presured to re-code in a way that leverages the native name resolution scheme of the underlying client OS. ... Client or server tries to talk to the other using NetBIOS name. ... Since ServerA is NOT in DomainB.Forest.TLD, ... it does not matter if both ClientB and ServerA were in the same network segment. ...
    (microsoft.public.windows.server.dns)
  • Re: proxy via ssh
    ... > I have a question about the proxy through ssh, ... > ssh client configured to connect serverA ... > for ClientB, ... > HTTP/1.0 400 Bad Request ...
    (comp.security.ssh)
  • Re: Adding a sucsriber
    ... Looking for a SQL Server replication book? ... ClientA (subscriber) and now I want to add another subscriber ClientB ... ClientB or I have to do something to the Publication on ServerA ...
    (microsoft.public.sqlserver.replication)
Loading