How we wound up with a RFC 1918 IP address visible in our public DNS

March 28, 2014

This is kind of a war story.

The whole saga started with a modern, sophisticated, Internet enabled projector, one that supports 'network projection' where you use software to feed it things to display instead of connecting to a VGA port or the like. This is quite handy because an increasing number of devices that people want to do presentations from simply do not have a spare VGA port, for example tablets. This network projection requires special software and, as we found out, this software absolutely does not work if there is NAT'ing in the way between your device and the projector. Unfortunately in our environment this is a real problem for wireless devices (such as those tablets) because there is no way off our wireless network without going through a NAT gateway of some sort.

(One of many reasons that this is required is that the wireless network uses RFC 1918 IP address space.)

If getting off the wireless network requires NAT and the software can't work with NAT, the conclusion is simple: we have to put the data projector on the wireless network (on what is amusingly called the 'wired wireless'). Wireless devices can talk to it, wired devices can talk to it by plugging into a little switch next to it, and everything is happy. But what about DNS? People would like to connect to the data projector by name, not just by IP address.

Like many places we have a 'split horizon' DNS setup, with internal DNS and public DNS. People using our VPN to authenticate on the wireless network and get access to internal services use the internal DNS servers, which are already full of RFC 1918 IP addresses for machines in our sandboxes. Unfortunately it's also possible to register wireless devices for what we call the 'airport experience', where we give devices external connectivity to the campus but no special access to our internal networks (as we feel that wireless MAC addresses aren't sufficient authentication for internal network access).

Devices using the airport experience can't use our internal DNS servers, partly because many of the IP addresses that the DNS servers would return can't be used outside our internal networks. Instead they get DNS from general campus recursive DNS servers, which of course use our public DNS data. Yet these devices still need to be able to look up the name for the data projector and get the wireless network's RFC 1918 IP address for it so they can talk to it directly with no NATing. The simplest, lowest overhead way to do this was to put the RFC 1918 wireless IP address for the data projector into our public DNS.

And that is why our public DNS now has a DNS record with a RFC 1918 IP address.

(I confessed to this today on Twitter so I decided that I might as well tell the story here.)

PS: people will probably suggest dnsmasq as a possible solution. It might be one but we aren't already using it, so at a minimum it'd be much more work than adding a DNS entry to our public DNS.


Comments on this page:

By Robert Sander at 2014-03-28 05:03:30:

Avoid a split brain DNS situation. This is a call for trouble.

Why is having RFC1918 addresses in public DNS a problem? Either they are reachable or they are not, because you have a good firewall. But that's not a DNS issue.

I use to create a subdomain like int.example.com that publicly resolves and where RFC1918 addresses can happily live. This way you do not need to provide "special" internal DNS resolvers to your LAN and VPN clients.

By cks at 2014-03-28 12:48:02:

Split horizon DNS is absolutely essential in our environment because we have machines with different external and internal IP addresses (due to bidirectional NATing to make certain sandbox machines accessible from the outside world).

Written on 28 March 2014.
« Why people keep creating new package managers
Recovering from a drive failure on Fedora 20 with LVM on software RAID »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Mar 28 01:47:19 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.