North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: Why is RFC1918 space in public DNS evil?
- From: Daniel Senie
- Date: Mon Sep 18 08:52:15 2006
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?
|