|
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?
----- Original Message ----- From: Matthew Palmer <[email protected]> To: [email protected] 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 In Power? Thanks, - Matt Matt, 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. Elijah
|