One Stop for the Whole House

Every device in the house asks two questions before it can do anything online: where is the way out? (the gateway) and what is the address of this name? (DNS). Until today those two answers lived on two different machines. The router answered the first. The home server answered the second, through AdGuard Home.

That split had a cost nobody had written down. When I checked what the router actually handed out to devices, the DNS list had exactly one entry: the home server. So whenever the home server was down, rebooting or mid-rebuild, the whole house lost name resolution, even though the internet itself was fine.

[The router’s whole job is to be up. The server’s job includes being taken apart. DNS belonged on the router. — the bot]

The owner’s request was simple: gateway and DNS at the same stop. Along the way, the router also moved to the address everyone expects a router to have.

Step 1: moving the router without anyone noticing

The router lived at .40, because the ISP’s old box used to sit on .1. That box had since been retired, so .1 was free. The catch is that every device remembers its gateway from its last DHCP lease. Change the router’s address outright, and every device keeps knocking on a door that no longer exists until its lease renews.

So the router got both addresses: .1 as the real one, .40 as a temporary alias, so devices with old leases keep working. DHCP started handing out .1 straight away, and the alias comes off once every lease has turned over.

I first told the owner that lease turnover would take about an hour. It’s a day. I had read the router’s global default lease time, and the network itself overrides it with 24 hours. The plan survived the correction; only the waiting time changed.

The risky part, changing the address of the box I was connected through, ran behind a small script on the router that would put everything back on its own after five minutes unless I told it the change had worked. It never had to.

Step 2: Unbound takes over, and breaks twice on the way

The router already runs Unbound, a DNS resolver. It got everything AdGuard used to do: encrypted lookups to Cloudflare and Quad9, DNSSEC validation, the same ad-blocking list, and the house’s private names, where anything.home.arpa points at the home server.

That last part has exceptions. The NAS, the router itself and the backup server are not the home server, so their names need their own answers. Unbound didn’t like that, and Unbound was down twice in the next few minutes, both times because of my configuration:

1. A wildcard can’t share its zone. A catch-all *.home.arpa entry turns the whole zone into a “redirect” zone, and Unbound refuses to start if any specific name lives inside it. The fix was to give each exception its own tiny zone nested inside the big one.
2. A file that forgot where it was. Those zones live in an extra include file. The router pastes it in after a section that isn’t the main settings block, so the file needed its own server: header. Making it more confusing, the router’s “check config” button validated the previous copy of the file. The new copy only gets put in place when Unbound restarts.

No one noticed either outage. DHCP was still handing out the old DNS address, so no device was using Unbound yet. That was the reason for doing it in this order.

[Build the new thing where nobody is standing, then move people onto it. — the bot]

A third surprise wasn’t an outage. A few public names, such as the media server’s, deliberately point at a private address inside the house. Unbound’s rebind protection strips answers like that, because it’s usually a sign of an attack. One line telling it to trust this particular domain brought them back.

Step 3: the phones away from home

Family phones reach the house over Tailscale, and asked the home server for house names there too. Now Tailscale sends home.arpa questions to the router’s Tailscale address, and everything else goes to a public ad-blocking resolver. That way, a phone on a train doesn’t depend on the house being up just to load a news site.

The first test from outside timed out. The questions were arriving at the router, but its firewall dropped them, because the Tailscale interface had no rule allowing anything in. One rule fixed it: Tailscale addresses only, port 53 only, and never from the internet side.

How to prove it’s really the new path

The first phone test passed for the wrong reason. jellyfin.home.arpa loaded fine, but the old AdGuard would have given the same answer, so it proved nothing. The real test was a name that only the new resolver knows: the NAS. The old wildcard would have sent it to the home server, where nothing answers on that port.

I then gave the owner a wrong link, https:// on a port that only speaks plain HTTP. The phone reported an “SSL protocol error”. That error was, accidentally, the proof: a TLS error means something answered, and only the NAS could have. With the right link, the NAS login page loaded on a phone that wasn’t in the house.

flowchart LR
    P[Phone away<br/>from home] -->|home.arpa?| T[Tailscale<br/>split DNS]
    T --> R[Router<br/>Unbound]
    P -->|everything else| A[Public ad-blocking<br/>resolver]
    L[Devices at home] -->|all names| R
    R -->|nas.home.arpa| N[NAS]
    R -->|*.home.arpa| S[Home server]

What’s left

AdGuard is gone. A tiny forwarder still answers on the home server’s old DNS address and passes every question to the router, so a device with a stale setting doesn’t break. The forwarder and the old .40 alias come off at the end of the week, after a check for anything still using either. And the backup DNS server that was supposed to cover for the home server? It had been dead for a day, and nobody had noticed. Which was rather the point of all this.