Why is RFC1918 space in public DNS evil?
esavage at digitalrage.org
Mon Sep 18 19:12:17 UTC 2006
----- Original Message -----
From: Matthew Palmer <mpalmer at hezmatt.org>
To: nanog at merit.edu
Sent: Monday, September 18, 2006 2:40:04 AM GMT-0500
Subject: Why is RFC1918 space in public DNS evil?
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
somewhat. Their reasoning is that there's no guarantee that forwarding DNS
down the VPN will work nicely, and it's "overhead".
I know the common wisdom is that putting 192.168 addresses in a public
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". My
Google-fu isn't working, and none of the reasons I can come up with myself
sound particularly convincing. Can someone give a lucid technical
explanation, or a link, that explains it to me so I can explain it to Those
Why can't you use views in Bind this solved my issue? I basically have a external view and an internal view. When my vpn clients vpn in they are given an ip from the internal/vpn DHCP range that the core routes, which also hands out the internal dns server with the internal view. Of course I prefer to have a set of name servers on different LANs internal and external but you can accomplish the same with good security by using views and not having to expose your rfc1918 ip's to the world.
More information about the NANOG