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: Joe Maimon
  • Date: Mon Sep 18 08:36:29 2006 

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.
This sounds like you have made it easy for yourself. Set up proper delegation in the parent public domain pointing to your internal nameservers, natted if need be, and you are done.

For convenience purposes, you may also slave a copy to the public parent nameserver, setup CNAMES from the parent into the child and so on so forth.

Of course, this only works seamlessly across the internet if you had the foresight to use a valid legitimate domain name internaly. So many do not.

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
somewhat.  Their reasoning is that there's no guarantee that forwarding DNS
down the VPN will work nicely, and it's "overhead".
Its only overhead in the sense of something more to manage.

And different VPN products will let you control this to differing extents. Even MS windows has gottent a whole lot more predictable in this fashion. Many SSL vpn products will even offer "split dns".

I know the common wisdom is that putting 192.168 addresses in a public

I would have said "frowned upon". Yours is a pretty strong phrase.
zonefile is right up there with kicking babies who have just had their candy
stolen, but I'm really struggling to come up with anything more
authoritative than "just because, now eat your brussel sprouts".
- Publishing internal host data into public DNS is viewed by many experts as providing a map to the chewy interior of your network

- If VPN clients require access to internal nameservers in order for them to attempt access to internal hosts, this lessens the odds of them attempting to connect to internal hosts while not being connected via vpn

- a compromised/poisened DNS server exposes you to even more vulnerabilities. An attacker could have your VPN clients unknowningly connect to nodes entirely under their own control, whether or not they have their vpn connection established. PKI is probably the only real way to eliminate this kind of threat.