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
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
In many scenarios the VPN'd hosts will ask for the names from the public DNS anyway, so I feel your client is right and it would be better for you to go with their wishes. Pete
On Mon, 18 Sep 2006, Petri Helenius wrote:
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
In many scenarios the VPN'd hosts will ask for the names from the public DNS anyway, so I feel your client is right and it would be better for you to go with their wishes.
Putting all other issues aside, I believe you are right. Still, if VPN is the problem than it is solvable. These machines can be configured with a DNS server that knows where to go.
Pete
On Mon, Sep 18, 2006 at 03:18:07AM -0500, Gadi Evron wrote:
On Mon, 18 Sep 2006, Petri Helenius wrote:
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
In many scenarios the VPN'd hosts will ask for the names from the public DNS anyway, so I feel your client is right and it would be better for you to go with their wishes.
Putting all other issues aside, I believe you are right. Still, if VPN is the problem than it is solvable. These machines can be configured with a DNS server that knows where to go.
if the hosts inside the VPN can only be accessed by hostnames served up inside the VPN, then it is more likely the users can be confident that their data is actually traversing the VPN. it works, or it don't. -- [ Jim Mercer jim@reptiles.org +971 50 436-3874 ] [ I want to live forever, or die trying. ]
At 04:33 AM 9/18/2006, Jim Mercer wrote:
On Mon, Sep 18, 2006 at 03:18:07AM -0500, Gadi Evron wrote:
On Mon, 18 Sep 2006, Petri Helenius wrote:
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
In many scenarios the VPN'd hosts will ask for the names from the public DNS anyway, so I feel your client is right and it would be better for you to go with their wishes.
Putting all other issues aside, I believe you are right. Still, if VPN is the problem than it is solvable. These machines can be configured with a DNS server that knows where to go.
if the hosts inside the VPN can only be accessed by hostnames served up inside the VPN, then it is more likely the users can be confident that their data is actually traversing the VPN.
it works, or it don't.
Or, the user's computer is still caching information. Internet Explorer is does this, and other browsers may as well. I keep a link to a script on my Windows desktop labelled "Flush DNS" and wind up using it often. If the user is accessing sites across the VPN, and as another poster writes the VPN drops, packets containing juicy, private information could well leak out in places people didn't intend. As risks go, this might not be too severe in many cases, but if you were doing a security assessment for sarbox or hippa, would you consider it safe? Do the remote sites indeed have filters blocking traffic to/from RFC1918 space that don't traverse the VPN?
On Mon, Sep 18, 2006 at 08:36:44AM -0400, Daniel Senie wrote:
At 04:33 AM 9/18/2006, Jim Mercer wrote:
if the hosts inside the VPN can only be accessed by hostnames served up inside the VPN, then it is more likely the users can be confident that their data is actually traversing the VPN.
it works, or it don't.
Or, the user's computer is still caching information. Internet Explorer is does this, and other browsers may as well. I keep a link to a script on my Windows desktop labelled "Flush DNS" and wind up using it often. If the user is accessing sites across the VPN, and as another poster writes the VPN drops, packets containing juicy, private information could well leak out in places people didn't intend.
As risks go, this might not be too severe in many cases, but if you were doing a security assessment for sarbox or hippa, would you consider it safe? Do the remote sites indeed have filters blocking traffic to/from RFC1918 space that don't traverse the VPN?
maybe ut some null routes on the PC's for the blocks, and have them overridden when the VPN comes up. could be done as part of the install of the VPN software/config? -- [ Jim Mercer jim@reptiles.org +971 50 436-3874 ] [ I want to live forever, or die trying. ]
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.
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 192.168.0.1 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 10.0.0.1 for reasons I never managed to decipher, other than it could. Of course my ISP both used, and routed 10.0.0.1 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 192.168.0.0/24, I'm not sure, but since you read the RFC and used a random chunk of 10/8 internally you don't care, right?
Likewise our inbound sanity route-maps deny all RFC1918 space. -- Michael Nicks Network Engineer KanREN e: mtnicks@kanren.net o: +1-785-856-9800 x221 m: +1-913-378-6516 Simon Waters wrote:
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 192.168.0.1
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 10.0.0.1 for reasons I never managed to decipher, other than it could. Of course my ISP both used, and routed 10.0.0.1 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 192.168.0.0/24, I'm not sure, but since you read the RFC and used a random chunk of 10/8 internally you don't care, right?
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.
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. 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.
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".
Its only overhead in the sense of something more to manage. 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 stolen, but I'm really struggling to come up with anything more authoritative than "just because, now eat your brussel sprouts".
- Publishing internal host data into public DNS is viewed by many experts as providing a map to the chewy interior of your network - 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.
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 think the best answer to that is to turn it on its head. As Joe points out, exposing interior information unnecessarily is a security risk - leaving a treasure map with "X marks the spot" invites pirates of all sorts. In this case, it is not only exposing interior information (the.host.you.want.to.attack.example.com) unnecessarily, but also in a way that doesn't actually help anyone else. The address of my telephone is 10.32.244.220. But do a traceroute to that address (ar the address of my family computer, which is 192.168.1.20), and I about guarantee that you will come to a different computer, for the simple reason that you aren't in any of my private domains. So putting those addresses in the public DNS actually *only* helps me if I am someone who is bombarding your prophylactic defenses with messages intended to reach your chewy innards. Anyone else has no actual use for the internal addresses. I think the right question for your client is: "why exactly did you want to do that?"
On Mon, 18 Sep 2006, Fred Baker 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 think the best answer to that is to turn it on its head.
As Joe points out, exposing interior information unnecessarily is a security risk - leaving a treasure map with "X marks the spot" invites pirates of all sorts. In this case, it is not only exposing interior information (the.host.you.want.to.attack.example.com) unnecessarily, but also in a way that doesn't actually help anyone else. The address of my telephone is 10.32.244.220. But do a traceroute to that address (ar the address of my family computer, which is 192.168.1.20), and I about guarantee that you will come to a different computer, for the simple reason that you aren't in any of my private domains.
A good illustration would be: firewall.* firewall2.* radius.* exchange.* Etc. Which are not necessarily accesible from the orld.
So putting those addresses in the public DNS actually *only* helps me if I am someone who is bombarding your prophylactic defenses with messages intended to reach your chewy innards. Anyone else has no actual use for the internal addresses.
I think the right question for your client is: "why exactly did you want to do that?"
At 04:40 PM 18/9/06, Matthew Palmer wrote:
I've been directed to put all of the internal hosts and such into the public DNS zone for a client. ... But this client, having a large number of hosts on RFC1918 space and a VPN for external people to get to it, ...
What happens when the external people are coming from 1918 nets that clash with those of the MP's client ??? It makes sense to use REAL addresses for the client's hosts so that there are no collisions, and NATing to 1918 space at one end or the other of the vpn. I've used this technique, with both VPNs and private interconnects, when delivering add-on services to client who already had existing internet connected infrastructure. The various services are listed in the public dns with public addresses, the traffic normally only going via the private paths. If it does leak, they're addresses in your control. YMMV, I had these sort of tricks in production for 100+ client sites from back in ISDN days with SS5s doing gw/router/fw/nat
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".
It can make sense: I am sending my mails mostly from lumbamba.peter-dambier.de (192.168.48.226) my router is krzach.peter-dambier.de (192.168.48.2) my mailer is echnaton.peter-dambier.de (192.168.48.228) My traceroute looks ok although some of the hosts are RFC1918 If somebody looks into my email headers they find information that makes sense although they could not ping the hosts. As long as you do not allow AXFR, nobody can see the information about RFC1918 hosts. So there is no risk. Even if they could get the data via AXFR they could not reach the hosts behind nat. I have seen zones allowing AXFR with lots of RFC1918 hosts. I dont see any harm. Leaking routing information would be evil.
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
It is common wisdom like the lie about spinach beeing healthy. (It is told spinach contains iron. Well not much really. They mixed up milligrams and micrograms. But it does containt oxal-acid, a deadly poison for babies)
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
Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/
On Mon, 18 Sep 2006 17:57:43 +0200, Peter Dambier said:
It can make sense:
I am sending my mails mostly from lumbamba.peter-dambier.de (192.168.48.226) my router is krzach.peter-dambier.de (192.168.48.2) my mailer is echnaton.peter-dambier.de (192.168.48.228)
My traceroute looks ok although some of the hosts are RFC1918 If somebody looks into my email headers they find information that makes sense although they could not ping the hosts.
As long as you do not allow AXFR, nobody can see the information about RFC1918 hosts. So there is no risk.
Unless of course you're leaking it in Received: headers.. Or DNS requests across the public Internet (remember, we *started* with the question of having this stuff on a public-facing DNS server..).. Or all the other myriad ways this stuff tends to leak out. AXFR is the *least* of your problems.
----- Original Message ----- From: Matthew Palmer <mpalmer@hezmatt.org> To: nanog@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 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
On Sep 18, 2006, at 12:12 PM, Elijah Savage wrote:
I've been directed to put all of the internal hosts and such into the public DNS zone for a client.
Another option is split-horizon DNS for the internal stuff, if it never needs to be publicly visible. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice Any information security mechanism, process, or procedure which can be consistently defeated by the successful application of a single class of attacks must be considered fatally flawed. -- The Lucy Van Pelt Principle of Secure Systems Design
----- Original Message ----- From: Roland Dobbins <rdobbins@cisco.com> To: nanog@merit.edu Sent: Monday, September 18, 2006 3:17:01 PM GMT-0500 Subject: Re: Why is RFC1918 space in public DNS evil? On Sep 18, 2006, at 12:12 PM, Elijah Savage wrote:
I've been directed to put all of the internal hosts and such into the public DNS zone for a client.
Another option is split-horizon DNS for the internal stuff, if it never needs to be publicly visible.
Yes, that's what views will give you. You have an internal view only your vpn and lan users can see. Then you have a public view for all others that do not mix. All can be run on the same servers vice having 2 external and 2 internal name servers and also without having to run multiple instances of bind.
participants (14)
-
Daniel Senie -
Elijah Savage -
Fred Baker -
Gadi Evron -
Jim Mercer -
Joe Maimon -
Matthew Palmer -
Michael Nicks -
Peter Dambier -
Peter J. Cherny -
Petri Helenius -
Roland Dobbins -
Simon Waters -
Valdis.Kletnieks＠vt.edu