Why is RFC1918 space in public DNS evil?

Mon Sep 18 12:36:44 UTC 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?