Re: Resolving hostnames in remote VPN network
From: Aaron Seet (poster_at_news.microsoft.com)
Date: 02/25/04
- Next message: Kurt: "Re: ICS quandary"
- Previous message: Bill Grant: "Re: ICS quandary"
- In reply to: Bill Grant: "Re: Resolving hostnames in remote VPN network"
- Next in thread: Aaron Seet: "Re: Resolving hostnames in remote VPN network"
- Reply: Aaron Seet: "Re: Resolving hostnames in remote VPN network"
- Reply: Bill Grant: "Re: Resolving hostnames in remote VPN network"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 25 Feb 2004 10:44:54 +0800
I added the explicit "local" suffix (previously used "." with partial
success) to prevent the OS from using the domain's DNS suffix in its search.
The deal is this: the domain is like corp.company.com which is private in
the office and not known to the public Internet. However, company.com itself
is public. So when you'd attempt to locate an internal host like
workstation.corp.company.com - that gets resolved by the ISP nameservers at
my home end into the wildcard address for the public company.com and goes to
the IP address of the web server instead. Undesirable.
So now if "workstation.local" can't be resolved by ISP or home DNS servers,
I have seen it attempt to ping it with NetBios name "workstation" alone, and
getting the correct IP address at the office LAN. To correct myself, without
monitoring actual packets transmitted (can't now anyway), it appears the NBT
broadcast did get the VPN connection. But that is still NetBios. I'm at a
loss how one can force queries regarding the internal domain name to the
office internal DNS servers instead (associated with PPP adapter).
This situation also applies to router-router VPNs between 2 domains with
internal naming scheme - how can one network resolve the internal FQDNs of
the other network? Supposing in my current situation (where I control both),
I easily transfer zones mutually and that works nicely. But if I'd attempt
to connect with a client or partner or vendor domain, and zone transfers
aren't allowed?
thanks,
Aaron
"Bill Grant" <not.available@online> wrote in message
news:uDIKhL0%23DHA.2184@TK2MSFTNGP12.phx.gbl...
You seem to have a strange idea about how broadcasts work. Adding a DNS
suffix will affect how DNS works, but will have no effect on LAN broadcasts
or Netbios over TCP/IP! Look at WINS. It uses Netbios names and is a "flat"
file. Only the name is significant. The only "suffixes" are the special
Netbios codes like 03 or 1c! (You are probably, in fact, getting a result
from WINS via DNS.)
In any case, if you are using WINS, you are not relying on Netbt
broadcasts for name resolution. Netbios names will be resolved by a direct
name server query to WINS, not by trying to broadcast. Perhaps you could
enable Netmon and have a look at what actually happens.
The problem of which connection is used for DNS was discussed recently
in the windows.server.dns newsgroup. Try posting a query in that newsgroup
on this topic.
- Next message: Kurt: "Re: ICS quandary"
- Previous message: Bill Grant: "Re: ICS quandary"
- In reply to: Bill Grant: "Re: Resolving hostnames in remote VPN network"
- Next in thread: Aaron Seet: "Re: Resolving hostnames in remote VPN network"
- Reply: Aaron Seet: "Re: Resolving hostnames in remote VPN network"
- Reply: Bill Grant: "Re: Resolving hostnames in remote VPN network"
- Messages sorted by: [ date ] [ thread ]