Working around another Android misfeature.

20 April 2022

I've been using Android phones for probably ten years now. Not because I have any particular loyalty to Google or the platform, but just because I can afford the phones. The last time I tried to text on a candybar phone using T9 I about went out of my mind because it was so different from what I'd been using for years. Additionally, my fingertips are just too damned big to use that form factor of keypad reliably anymore. I don't have any particular beef against Apple and the iDoohickey product lines, I just can't particularly afford them. I can fairly readily afford Android devices. Plus, with Android I can cajole if not outright force it to do what I want. Most of the time.

Last summer while picking around on my phone I tried logging into one of my wireless access points running OpenWRT to check on something, as well as see just how mobile-friendly OpenWRT's control panel was. Much to my chagrin my phone didn't resolve the hostnames of any of my wireless access points around the house. I should have just been able to type http://upstairs/ or http://downstairs/ into a web browser and get a login page. Same thing on my tablet and my work phone. I couldn't hit Leandra either. So, off I went down a rabbit hole. I'll spare you all the troubleshooting and debugging I did over the next couple of days because it's elementary networking stuff and outside of the scope of this post. Suffice it to say that everything was working the way it was supposed to, with the notable exception of my phones and tablet.

I then did some poking around and discovered that I wasn't the only person that this started happening to without warning. As it turns out, an OS patch released for Android (which my devices had installed a few days previously) broke DNS resolution in a crucial way. Without going off on too much of a tangent, Android now ignores any and all DNSes handed out to Android devices with DHCP. Instead, Android devices are now hardwired to always and only use Google's Public DNSes to look up IP addresses. Because why would anybody want to do something so stupid as log into a device on their home network.

I figured that, because I wasn't the only person who barked their shins on this particular change somebody had to have come up with a solution. Most of what I found wasn't helpful at all. I did happen across something called nip.io, which is a free and public service (open source, too!) that does nothing but map internal IP addresses (e.g., 192.168.23.5) to public hostnames (192.168.23.5.nip.io). This is pretty cool, don't get me wrong. However, the whole point of DNS is so that you can give stuff on your network memorable names so that you don't have to remember IP addresses. Sure, I can type http://192.168.0.1/ into a browser to get to the upstairs access point, but what about Leandra? Or my media box? Or anything else I have running at home which gets its network information from DHCP? Even for me that's a non-starter.

Thanks to the Fediverse I realized that there just might be a use case for novelty domain names1. So, I vented my spleen by registering a domain that accurately describes how I feel about this - goats.rodeo from my domain registrar of choice and set up DNS for the domain there.

Fun fact: You can set up hostname-to-IP address mappings for private IP addresses on public DNSes. So that's what I did. I logged into my wireless access point upstairs (which is also the DHCP server) and set static IP addresses (note: despite the "attention" line, it is possible and well supported to set static leases from the control panel) for my wireless access points, Leandra, and one or two other things.

When I go to one of those systems from one of my Android devices, Android ignores the DNS it's configured for and looks up, for example, leandra.goats.rodeo using Google's Public DNS. Google's Public DNS looks up leandra.goats.rodeo at name.com, doesn't care that it gets an RFC 1918 private address2, and sends the IP address (192.168.0.170) back to my device. My device then goes to the IP address it received.

The one I want to point out (and it's a minor one, really) is that this won't work the way you want if you have any virtual hosts set up on your internal network. At least, not unless you set up DNS records for them. That's not my use case, probably not a lot of other folks' use cases, but if you've got a reasonably complex homelab you might. So, just so you know.

There are in theory a few security considerations. It is generally considered bad practice to advertise your external IP addresses to the world. In sensitive environments (like your average corporation) this is is true. For my setup at home which is not exposed to the world at large (you'd have to be within spitting distance of my house to see my network) this is less of a concern. To put it another way, my threat model does not need to factor in the leakage of private addresses for my use case or network architecture.

1 I don't like GoDaddy. I don't condone what their management does in their spare time. They're the first registrar I found which has a list of said novelty TLDs.

2 It would surprise me not a bit if Google caught onto this and started blocking looked-up private IP addresses. So, let's enjoy it while we can.