At 04:33 AM 9/18/2006, Jim Mercer wrote:
On Mon, Sep 18, 2006 at 03:18:07AM -0500, Gadi Evron wrote:
On Mon, 18 Sep 2006, Petri Helenius wrote:
Matthew Palmer wrote:
I've been directed to put all of the internal hosts and such into the public DNS zone for a client. My typical policy is to have a subdomain of the zone served internally, and leave only the publically-reachable hosts in the public zone. But this client, having a large number of hosts on RFC1918 space and a VPN for external people to get to it, is pushing against this
In many scenarios the VPN'd hosts will ask for the names from the public DNS anyway, so I feel your client is right and it would be better for you to go with their wishes.
Putting all other issues aside, I believe you are right. Still, if VPN is the problem than it is solvable. These machines can be configured with a DNS server that knows where to go.
if the hosts inside the VPN can only be accessed by hostnames served up inside the VPN, then it is more likely the users can be confident that their data is actually traversing the VPN.
it works, or it don't.
Or, the user's computer is still caching information. Internet Explorer is does this, and other browsers may as well. I keep a link to a script on my Windows desktop labelled "Flush DNS" and wind up using it often. If the user is accessing sites across the VPN, and as another poster writes the VPN drops, packets containing juicy, private information could well leak out in places people didn't intend. As risks go, this might not be too severe in many cases, but if you were doing a security assessment for sarbox or hippa, would you consider it safe? Do the remote sites indeed have filters blocking traffic to/from RFC1918 space that don't traverse the VPN?