Why is RFC1918 space in public DNS evil?

Mailman List Mirror (Read Only)
1

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

2

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

3

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.

4

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.

5

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?

6

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.

7

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.

8

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?

9

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?

10

Likewise our inbound sanity route-maps deny all RFC1918 space.

11

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?"

12

> 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.

13

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

14

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

15

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.

16

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

17

Another option is split-horizon DNS for the internal stuff, if it never needs to be publicly visible.

18

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.