internal home domains

Who wants to remember all those IPs anyways?

I run a number of services as part of my home network. They’re spread out between three virtual machines, and each of them have their own administration pages on different ports. Of course, I can remember each of the IP address and port combos and if I can’t remember one of them, I can always search my history. But where’s the fun in that? What if I could set up domains for each service and use that instead? As it turns out, I could! And I’d like to share the process in the event that others find it useful.

All you’ll need for this is a domain that you own; you should ensure that it’s not used for anything publicly accessible. It’s probably fine to use one that you’re already using, but personally I feel that it’s good sense to maintain the separation. If you want to use SSL certificates, you should make sure that your DNS provider allows for progammatic access through API keys. Lastly, you should decide what private IP address range to use for your domain and services. If you don’t know what that means, don’t fret; here’s some light reading to get you started.

There’s only a few steps to setting up the domains:

  • installing a reverse proxy
  • creating the domains
  • setting up the routing

reverse proxy

In a general sense, a reverse proxy is a server that receives inbound requests and forwards them to other servers according to a set of rules. For this project, I chose caddy due to its ability to work with CloudFlare and its API, but the process is essentially the same for any other proxy. You can download it using the instructions on its website; the site also provides binaries with certain API interaction functionality included, so make sure to pick the one that works best for you. Also, you should set up your reverse proxy on its own IP as that will be the target for all of the different domains that you’ll create.

Go ahead and start up your reverse proxy to make sure that it works. For demonstration purposes, let’s say that I’m using caddy on the local IP 10.10.10.1 and the following services at the corresponding IPs and ports:

  • ad blocker: 10.10.10.11:1111
  • docker administration: 10.10.10.22:2222
  • landing page: 10.10.10.33:80
  • password manager: 10.10.10.44:4444

domain creation

The next step is to create your domains. There’s not much to this part at all: create as many A (or AAAA for IPv6) records as you please and point each of them at the IP where the reverse proxy is located. For example, here’s a list of of descriptive DNS records for an example domain at beepboop.xyz:

;; A Records
beepboop.xyz.			1	IN	A	10.10.10.1
www.beepboop.xyz.		1	IN	A	10.10.10.1
adblock.admin.beepboop.xyz.	1	IN	A	10.10.10.1
docker.admin.beepboop.xyz.	1	IN	A	10.10.10.1
vault.beepboop.xyz.		1	IN	A	10.10.10.1

As you can see, each of the records points to the aforementioned local IP address. If your DNS provider allows for traffic proxying (like CloudFlare does), then make sure that the record is DNS only by disabling the proxy.

The beauty of this solution is that an address in a private IP range is not accessible through the public internet. So if an external party were to attempt to resolve your domains, they would be pointed to an address inside their own network. You, however, would be pointed to your reverse proxy and then onto the correct address, which you’ll set up in the next section.

routing setup

Lastly, the reverse proxy configuration should be adjusted to include these new domains. Open up the config file with your favorite editor and then add your domains with the requisite instruction for reverse proxying. If you’re using caddy, you would open the Caddyfile and place the following blocks for the records above:

beepboop.xyz, www.beepboop.xyz {
  reverse_proxy 10.10.10.33:80
}

adblock.admin.beepboop.xyz {
  reverse_proxy 10.10.10.11:1111
}

docker.admin.beepboop.xyz {
  reverse_proxy 10.10.10.22:2222
}

vault.beepboop.xyz {
  reverse_proxy 10.10.10.44:4444
}

Save your configuration and reload your proxy server. Visit your domains and ensure they work correctly. Now you can get to your internal services without having to remember all the separate IPs and ports! If you want to add certificates to your internal services, feel free to read the documentation for your proxy server and add the necessary fields to your directives in order to automatically provision your certificates.

And that’s it.