North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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
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.
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
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.
Its only overhead in the sense of something more to manage.
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".
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
- Publishing internal host data into public DNS is viewed by many
experts as providing a map to the chewy interior of your network
stolen, but I'm really struggling to come up with anything more
authoritative than "just because, now eat your brussel sprouts".
- 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.