Add a local service name

Nobody in your house wants to remember 192.168.1.20:8081. Names make services easier to move, too: when the service migrates to new hardware, you update one DNS record instead of re-teaching every person and reconfiguring every client.

The pieces stack: the router reservation keeps the server’s address stable, and local DNS can map a private hostname to the server address on top of it.

Pick a name you control

Use a private zone like lab.test — the .test top-level domain is reserved and will never exist on the public Internet. Avoid inventing names under public domains you do not control: if you name your server homeserver.somestartup.com and that company later serves something at that name, your clients will resolve to the wrong side depending on which resolver answers first.

So the target record is:

homeserver.lab.test  ->  192.168.1.20

Configure it where your clients look

The name must be answered by the DNS server your LAN clients actually use. That’s usually one of:

• the router’s DNS settings, if it supports custom local records
• a self-hosted resolver such as Pi-hole or Unbound, if you already run one and point DHCP at it

Configure the name in the local DNS system you control. As a last resort, /etc/hosts entries on each client work, but they don’t scale past two devices and they’re exactly the kind of hidden state runbooks forget.

Verify from two clients

Inspect the intended answer from a client:

dig homeserver.lab.test
curl -I http://homeserver.lab.test

The dig answer section should show 192.168.1.20. The curl -I result depends on where you are in the course: while the service is still bound to loopback, a refused or timed-out connection from your laptop is correct — the name resolves, and the next lesson’s proxy provides the actual entry point.

Then verify answers from two clients and document the authoritative source. Two clients, because one device may carry a stale cache or a manual hosts entry; two matching answers mean the DNS server is really doing the work.

The failure mode

Split DNS must have clear ownership and recovery. If the record lives in a Pi-hole nobody documented, then when that box dies, every service name on the LAN dies with it — and whoever debugs it will chase “the server is down” when the server is fine. Write down which device answers lab.test queries, and put that fact in the runbook.