Local DNS: reaching your services by name, without hacking hosts files

At first you just remember the addresses. The NAS at .20, the hypervisor at .10, the monitoring stack at .35. Then the services multiply, ports get added, and you end up keeping a list in a text file.

The next step is usually the hosts file, duplicated on every machine. It works — until the third machine, or the first address change.

The principle: a resolver that is authoritative

The answer is to run a resolver on your network that is authoritative for your internal domain. Every machine uses it as its DNS server, handed out automatically by DHCP.

It answers for your internal names itself, and forwards everything else upstream. A single change there propagates instantly to the whole network. No more hosts files, no more duplication.

It is also the natural place for network-wide filtering, if you want any — the same tools usually do both.

The made-up-domain trap

Then comes the question of the name. The temptation is to invent an extension: something in .lan, .home or .local, which sounds right and costs nothing.

That is a bad idea, for two distinct reasons.

First, an extension that is not delegated today can be assigned publicly tomorrow. Your internal names then collide with real internet names, with symptoms that make no sense and vary depending on which resolver was asked. This is not theoretical: several extensions widely used internally ended up existing publicly.

Second, some extensions are already reserved for other purposes by the standards — notably for service discovery on the local network — and using them for regular DNS causes erratic behavior, particularly on Apple systems.

The clean answer: a subdomain of a domain you own. You control the name, nobody will take it away from you, and it opens the door to publicly trusted certificates.

Split-horizon: one name, two answers

The mechanism that makes the whole thing comfortable is split-horizon: the same name answers differently depending on where you ask from.

From home, the internal resolver returns the service's private address: traffic stays local and fast, and never leaves the network. From anywhere else, public DNS returns the public address and you come in through the intended path.

The benefit is having only one address to remember. Your bookmarks work at home and on the road, with no second set of links to maintain.

It also avoids a common oddity: without it, a machine on the network that asks for the public name gets the public address, leaves the network and comes back in — which sometimes works, often fails depending on the gear, and always hurts performance.

Certificates, without the warnings

A point that often surprises people: a certificate attests to a name, not to an address. If your browser asks for a name the certificate covers, validation succeeds — whether that name resolves to a private address is irrelevant.

So you can obtain a publicly trusted certificate for a service that is never exposed to the internet. The only constraint is to use DNS validation rather than HTTP validation, since the authority cannot reach your service.

It is the simplest way to get clean HTTPS internally, without pushing a homegrown certificate authority onto every device — an exercise that gets painful fast as soon as you add phones, or devices whose certificate store you do not control.

Two operational traps

The browser's encrypted DNS. Modern browsers can send their DNS queries straight to a public resolver, bypassing the system's. Your internal names then stop resolving — but only in the browser. Resolution still works on the command line, which makes the diagnosis disorienting. You have to disable the feature, or point it at your own resolver.

The single resolver. If it goes down, nothing resolves on the network any more, public names included. The symptom looks like a total internet outage while the connection is working perfectly. Two resolvers handed out by DHCP remove that risk. Failing that, at least keep access by IP address to your critical gear: the day DNS goes down, that is your only way in.

The order to roll it out

Start by declaring a subdomain on a domain you own. Then install the resolver and create a few test records, without touching DHCP. Check resolution by querying that resolver explicitly. Only once that is conclusive do you hand it out over DHCP to the whole network — and you add the second one at the same time, while you are at it.