Why is RFC1918 space in public DNS evil?
Gadi Evron
ge at linuxbox.org
Mon Sep 18 08:16:20 UTC 2006
On Mon, 18 Sep 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. 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
>
Security-wise:
http://www.linuxsecurity.com/content/view/112264/65/
Operations-wise:
nanog, back in 97 -
http://www.cctec.com/maillists/nanog/historical/9706/msg00187.html
dns-wg back in 2002 -
http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00255.html
Semi-related:
http://ietfreport.isoc.org/idref/draft-ietf-dnsop-bad-dns-res/
http://www3.ietf.org/proceedings/99jul/I-D/draft-ietf-nat-dns-alg-04.txt
http://www.cs.utk.edu/~moore/what-nats-break.html
Gadi.
More information about the NANOG
mailing list