I auto-configure my reverse proxy and uptime monitoring using DNS-DS

jasonrogena1 pts0 comments

Running My Home Lab Using DNS-SD | Not /.well-known

Home<br>All Posts<br>Tags

Previous post<br>Next post<br>Back to top<br>Share post

This post has NOT been generated using AI.

Like most of those who I believe would be reading this blog, I run my own home lab. My setup has, over the years, evolved from an old laptop running just my media centre, only accessible on my home network. Today, it is a more elaborate setup with containers running on two hosts on my local network, a third host running local LLMs, and a fourth (thin) host in the cloud running a reverse proxy. The reverse proxy forwards requests to services running in the hosts on my local network, allowing me to access some services from anywhere. I like the setup. In essence, it is quite simple. All I have to deal with is a container engine (I use Podman Quadlet) and my reverse proxy, outside the actual services deployed in the lab. I have avoided jumping into the Kubernetes (or similar) bandwagon, as I still don&rsquo;t think the overhead is justified as yet.<br>It being a home lab means I quite often bring up and take down services. One big pain point for me was having to SSH into my cloud host to update the reverse proxy configuration every time I&rsquo;d want to expose or stop exposing a service to the internet. So last year, while in between jobs, I started exploring how I could auto-configure which services to expose to the internet. I was interested in mechanisms that would be agnostic to whatever container engine I use (having moved from systemd-nspawn to Podman, and afraid I&rsquo;d do a similar switch soon after).<br>SRV for the Win<br>DNS was coming out on top for this kind of container-engine-agnostic mechanism of service discovery. The rough idea was I would configure my reverse proxy to accept requests from any subdomain in a wildcard domain (let&rsquo;s say *.apps.rogena.me). The reverse proxy would extract whatever subdomain was being hit, let&rsquo;s say home-assistant in home-assistant.apps.rogena.me, and forward the request to a service running inside whatever container IP address either home-assistant.host1.lan or home-assistant.host2.lan resolves to.<br>Two things I had to figure out:<br>Typical DNS record types (A and AAAA) would only allow discovering the IP address for the container, and not the port the service is running on in the container.<br>What would load-balancing across multiple containers exposing the same service look like?<br>SRV is a lesser-known DNS record type that allows you to discover both the IP address and port a service is running on. Additionally, you can encode, as part of an SRV record, the priority and weight to use for the returned host-port pairs when trying to decide which one to use if multiple host-port pairs are returned when a query is made for an SRV record. The priority field encodes &ldquo;who to send the request to first&rdquo;. A lower value for this field indicates a higher priority. Under normal operation, requests should only be sent to the host-port pair with the lowest priority value. The weight field encodes how to split load amongst the host-port pairs that have the lowest priority value. A higher weight indicates a host-port pair can take more load. With these two fields, you can encode your fail-over as well as load-balancing strategy.<br># dig home-assistant._http._tcp.host1.lan. SRV

; > DiG 9.18.39-0ubuntu0.22.04.4-Ubuntu > home-assistant._http._tcp.host1.lan. SRV<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags:; udp: 65494<br>;; QUESTION SECTION:<br>;home-assistant._http._tcp.host1.lan. IN SRV

;; ANSWER SECTION:<br>home-assistant._http._tcp.host1.lan. 60 IN SRV 0 77 8123 0.home-assistant.host1.lan.

;; ADDITIONAL SECTION:<br>0.home-assistant.host1.lan. 60 IN A 192.168.10.58

;; Query time: 44 msec<br>;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)<br>;; WHEN: Sun Jul 12 20:11:31 UTC 2026<br>;; MSG SIZE rcvd: 169

The above shows an example dig for an SRV record home-assistant._http._tcp.host1.lan.. _http and _tcp in this example encode the service name and protocol. In the answer, 0 77 shows the priority and weight, while 8123 0.home-assistant.host1.lan. shows the port and the A record with the IP address of the container running Home Assistant.<br>Great success! I&rsquo;m able to discover which container IP and port I should hit to access a service. The reverse proxy can, in theory, run a DNS SRV query for home-assistant._http._tcp.host1.lan. and home-assistant._http._tcp.host2.lan. when a user tries accessing https://home-assistant.apps.rogena.me. In a section below, I explain exactly how I configured Caddy (my reverse proxy).<br>I couldn&rsquo;t find a container-engine-agnostic DNS server that exposes SRV records for containers running on hosts, so I wrote container-dns. container-dns runs inside host1 and host2. With container-dns, all I need to do is to configure an appropriate hostname for the container and add the...

home assistant container running host1 reverse

Related Articles