Names Matter
Systems are built for people, and people remember names much more easily than numbers. So even if they never think about it directly, DNS matters to people. It is one of the quiet cornerstones of any environment. Without it, we are left remembering strings of numbers and building mental maps that only work as long as memory holds. With it, a collection of machines starts to feel more like a place.
For a long time, my homelab mostly worked by memory.
I knew the IP addresses for anvil and hammer. I knew where my Jekyll development VM lived, and I knew how to reach the things I cared about. But knowing is not the same as having a system. Knowing is often just a sign that you have memorised enough to work around the absence of one.
As the lab started to come back together after the rebuild, that began to bother me more.
I had already rebuilt the hosts, set up Incus, sorted out storage, and got bridged networking working. VMs could sit directly on my LAN, and services were beginning to take shape again. At that point, raw IP addresses started to feel like a step backwards. They worked, but they did not scale well in my head. More importantly, they made the lab feel more temporary than it really was.
I already owned cdilks.com, and for internal homelab naming I had settled on forge.cdilks.com. That gave me a clean separation between public things and private ones. Public services could live under names like voice.cdilks.com. Internal services and hosts could live under names like anvil.forge.cdilks.com and hammer.forge.cdilks.com. Once I had that in mind, the next step became obvious: I needed proper internal DNS.
I spent some time thinking about what I wanted from it. I did not want to go all the way down the CoreDNS path yet. CoreDNS is powerful, but it also felt like another layer of complexity at a point where I was trying to be more careful about adding layers just because I could. I wanted something focused on DNS, something with a decent interface, something that would let me run an internal zone cleanly and without too much ceremony.
Technitium looked like a good fit.
I decided to run it on anvil, inside a small Incus container. That felt like the right level of weight for the job. DNS is important, but it does not need a whole VM in my lab. I created a container called dns1, attached it directly to the LAN, and gave it a static private address. I could have used a DHCP reservation, and that would have been a perfectly sensible choice, but sadly my ISP-provided router makes this less reliable than it should be.
Once the network side was sorted, the rest was pleasantly straightforward. The container was updated, a few basic tools installed, and then Technitium itself went on without much fuss. The service came up, the web interface appeared on port 5380, and the first feeling I had was relief. There is always a small moment with foundational services where you wonder whether they are going to become a story. This time, it was refreshingly uneventful.
I configured upstream forwarders to Cloudflare using DNS-over-HTTPS. That gave me a nice split in responsibilities. Technitium would be authoritative for my internal zone, forge.cdilks.com, and recursive for everything else. That was exactly what I wanted: one place to answer internal questions, and one place to send the rest.
Then I created the zone.
That part felt more significant than it probably should have. There is something about typing in a zone name and beginning to add records that makes a homelab feel more real. Suddenly I was no longer just keeping track of hosts. I was naming a small world.
The first records were simple:
anvil.forge.cdilks.comhammer.forge.cdilks.comjekyll-dev.forge.cdilks.comdns1.forge.cdilks.com
I also added dns.forge.cdilks.com, pointing to the same container. dns1 is the host. dns is the role. I liked having both.
One of the nice things about Technitium is that it makes this part very visible. You can see the zone, the records, the SOA, the NS entry, the whole shape of it. That matters more than it sounds like it should. Good infrastructure often becomes easier to trust when it becomes easier to see.
The real test, of course, was not whether the interface looked tidy. The test was whether the names resolved properly from real machines.
I started with explicit lookups against the address for dns1. dns1.forge.cdilks.com resolved correctly. So did anvil, hammer, and jekyll-dev. Public lookups worked too. github.com came back through the forwarders just as it should. That was the first point where I felt confident the service was not just running, but actually useful.
After that, I pointed a few systems at it directly.
anvil, hammer, and jekyll-dev were all configured to use dns1 as their resolver, with forge.cdilks.com as the search domain. That was enough to let me use short names cleanly. anvil became just anvil. hammer became just hammer. jekyll-dev became just jekyll-dev. That may not sound dramatic, but it changes the feel of a lab. It is the difference between remembering numbers and trusting names.
Even better, the same thing worked from my Windows machine. Once that was resolving anvil, hammer, and jekyll-dev correctly, I knew the setup had crossed from experiment into infrastructure.
There were a couple of small reminders along the way. Ubuntu still resolves its own short hostname through /etc/hosts, so on hammer, the name hammer pointed to 127.0.1.1 locally while hammer.forge.cdilks.com pointed to the real LAN address. That looked odd at first, but turned out to be normal and harmless. It was a useful reminder that “working” does not always mean “working the way I first expected.”
I have not rolled this out to everything yet, and I do not think I need to. One of the quiet lessons of this rebuild has been that not every useful thing needs to become universal immediately. Right now, the systems that matter most are using dns1, and that is enough. The internal DNS exists, it works, and it already makes the lab easier to live with.
More than anything, this change made the homelab feel coherent.
That is what I keep coming back to. So many homelab projects are exciting because they add capability. This one feels important because it adds shape. It takes machines and services that already existed and makes them part of a system that is easier to understand, easier to document, and easier to trust.
A homelab starts to feel different when it has names instead of numbers.
This did not make the lab faster. It did not make it louder. It did not add a flashy new application. What it did was make the whole thing feel more intentional. For a service as quiet as DNS, that feels like a surprisingly meaningful result.