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: Peter J. Cherny
  • Date: Mon Sep 18 09:37:36 2006
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=luddite.com.au; b=gDu51Nx/4GGgQNSImE/jCk1WeNqRGohAlfYsCIPIt/uWdTBrSziqNIPYaQc+jT8jBpS1winp3PXEsFpEY+7+WTFB86rbWZ74ZBLcWI6Z3/ctbu3aXgY7e7WgpbUylA3G;
At 04:40 PM 18/9/06, Matthew Palmer wrote:
I've been directed to put all of the internal hosts and such into the public DNS zone for a client.
...

But this client, having a large number of hosts on RFC1918
space and a VPN for external people to get to it,

...

What happens when the external people are coming from 1918 nets that
clash with those of the MP's client ???

It makes sense to use REAL addresses for the client's hosts
so that there are no collisions, and NATing to 1918 space at
one end or the other of the vpn.

I've used this technique, with both VPNs and private interconnects,
when delivering add-on services to client who already had existing
internet connected infrastructure. The various services are listed
in the public dns with public addresses, the traffic normally only
going via the private paths.

If it does leak, they're addresses in your control.

YMMV, I had these sort of tricks in production for 100+ client sites
from back in ISDN days with SS5s doing gw/router/fw/nat