Why is RFC1918 space in public DNS evil?

Simon Waters simonw at zynet.net
Mon Sep 18 08:28:36 UTC 2006

On Monday 18 Sep 2006 07:40, you wrote:
> 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".

I believe it is simply because the address isn't globally unique, so you may 
connect to the wrong server.

So they use in "internal.example.com" and get

They then terminate the VPN, try something that should connect to this server, 
and send their credentials (not over the VPN, so not encrypted perhaps) to 
some other server that promptly snaffles them (all untrusted servers are 
assumed to run honeypots, and password grabbing tools, at the very least).

Of course including the DNS inside the VPN doesn't stop the addresses being 
not unique. I'm guessing the logic here is that one must flush ones DNS after 
disconnecting from a VPN that uses RFC1918 address space, and/or block 
RFC1918 addresses at routers (including client VPN hosts or routers) so that 
you don't accidentally connect to the wrong network unless a specific route 
is connected.

I normally block RFC1918  at routers, ever since I found a Windows box sending 
weird traffic to for reasons I never managed to decipher, other than 
it could. Of course my ISP both used, and routed somewhere, so this 
random stray traffic was going somewhere (I know not where to this day).

How this works out for people connection via Wireless lans, which seem 
invariably to use, I'm not sure, but since you read the RFC 
and used a random chunk of 10/8 internally you don't care, right?

More information about the NANOG mailing list