Re: Name resolution vs. multiple NICs
From: Dean Roddey (droddey_at_charmedquark.com)
Date: 01/13/05
- Next message: Arkady Frenkel: "Re: Multicasting - Basic Questions and Problems"
- Previous message: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- In reply to: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Next in thread: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Reply: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 12 Jan 2005 22:10:13 -0800
>> Actually I did earlier, but the issue is that when I resolve the
>> FQDN (the canonical name), it's not right
>
> Can you ping it? If so the name is right. There is no such thing as an
> "illegal name" (see below)
>
Not, they cannot ping that name, not even on the same machine. So it is
clearly not resolvable.
> We have been through this before don't we. Being "in a workgroup" is
> orthogonal to TCP/IP name resolution. Most likely their computer
> configuration tells them that they are in .isp.com and that's what they
> see. Exactly as the scenario above.
We've been through all of the places that I know of that it could be
happening, and it is not being set anywhere I can see. It's not in their
computer name stuff, which clearly shows just a standard NetBIOS name. It's
not set in the TCP/IP configuration. It's not set in the DHCP server (which
would just put it into the TCP/IP configuration anyway.) So I think it's
some wierd side effect of name resolution, not anything to do with their
computer configuration.
> Not really. All you can physically get is what is FQDN as it appears to
> _your_ machine. It doesn't have to be the same as FQDN that the target
> machine itself sees. For example I may have a private DNS server that will
> tell me that my FQDN is "host.domain.com" while you will only see me by my
> netbios name "host".
I don't think that's relevant to the situation at hand. It has nothing to do
with private DNS servers, this is all on one network, with no local DNS
service running, it's just a straight Workgroup. Their ISP's DNS servers
konw nothing about their machines at all, they are behind a NAT router in
almost all cases.
The basic issue here is to get a name that's not just a locally ok name, but
a version of that name that will be valid to any computer on the network for
address resolution purposes. See below.
> which means that something does set the suffix for them. Most likely they
> have the suffix hardcoded in the computer name (Right-click My
> Computer/Properties/Computer Name/Change.../More...)
Well of course SOMETHING is. That's the main point of the question. We
aren't stupid, and we know all the obvoius places to look, and it's not
being set in any of those places NOR is it happening when the same exact
machine is configured not to use DHCP to get it's setup. But the DHCP
servers they are using (in their routers in their cases) have no control for
such a thing, nor does anything show up in the TCP/IP configuration that
they are getting from them that would indicate that the NIC should have an
associated domain suffix, and even if it did, why is it their ISP's domain?
It seems like something wierd is happening in the resolving of the canonical
name that's maybe going off-site to their ISP's DNS server, and it's just
returning any such query as having the ISP's domain, or maybe the windows
DNS client service is doing this, I dunno.
> What I don't understand is why you go through all this gyrations to
> discover the correct FQDN. If you can see them by the NetBIOS name isn't
> this enough?
That's the other part of the question. Somethign like PING only cares if it
can resolve the name on the computer you run it on. I'm using an ORB and
these names are published in a name server where others around the network
will have to resolve it. So I was getting the FQDN in order to be sure I was
publishing something fully qualified and therefore resolvable from any
machine in the local network, not just a local name that happens to work on
the local machine.
Maybe that's not true, and I was just being paranoid, but I would like to be
sure that that was the case before I committing to making yet another change
in the way the ORB is publishing server addresses.
So if in a domain based system, I can do ping MYCOMPUTER, and it'll work on
MYCOMPUTER just fine to ping itself. And generally speaking, it would seem
to also work from other computers in my domain based network, since there
are no name clashes. But, what if there was a MYCOMPUTER.domain.com and
MYCOMPUTER.sub.domain.com on the same network, and I publish to the name
server MYCOMPUTER, that's not going to work in some program on a computer
besides one of the MYCOMPUTER machine, if it pulls that short name out of
the name server and tries to resolve it, or it might work but randomly get
one or the other machine. So if a user gives me a name, I'm interested in
being sure it's not just a short name that works locally only because it
might get published.
That's the kind of worry that pushed me to try to get the FQDN. And it
almost always works, but there is something strange about these two people's
systems, and the fact that it only is a problem if two NICs are present
makes it even wierder. He can pull out the wireless NIC and the domain
suffix issue goes away.
I can always just try publishing the name as I get it, and if it works, it
works. But I'd rather not do voodoo programming and understand why this is
happening.
-------------------------------------
Dean Roddey
Chairman/CTO, Charmed Quark Systems
www.charmedquark.com
- Next message: Arkady Frenkel: "Re: Multicasting - Basic Questions and Problems"
- Previous message: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- In reply to: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Next in thread: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Reply: Eugene Gershnik: "Re: Name resolution vs. multiple NICs"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
