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’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’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’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’s say *.apps.rogena.me). The reverse proxy would extract whatever subdomain was being hit, let’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 “who to send the request to first”. 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’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’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...