Taking Control of Home DNS and DHCP with Pi-hole

DNS is one of those services that disappears when it works and makes almost everything look broken when it does not. In my home lab, Pi-hole grew from an advert-blocking experiment into part of the network’s core infrastructure: it provides DNS and DHCP for wired and Wi-Fi devices in the home.lan domain.

The internet edge is still an EE Smart Hub Plus, model SH31B. I was not trying to replace every domestic component with enterprise equipment. I wanted to keep the ISP router for the broadband connection while moving the parts of the local network I cared about onto something I could inspect and control.

Why move DHCP as well as DNS?

Pi-hole can be used only as a DNS filter, leaving the router to allocate addresses. Running DHCP on Pi-hole made the local network much easier to reason about. One service could associate leases, hostnames and queries, while consistently assigning the home.lan search domain.

The request path became:

client joins network
  └── Pi-hole DHCP lease + home.lan identity
        └── Pi-hole DNS filtering
              └── configured upstream resolver

That improved visibility. When an unfamiliar client appeared in the query log, I had a better chance of connecting its address to a lease and a recognisable hostname. Local systems could also be addressed by name rather than relying on a list of numbers in my head.

Only one DHCP server should answer on a broadcast domain unless multiple servers have been designed to cooperate. The EE hub’s DHCP service therefore needed to be disabled before Pi-hole became authoritative. The Pi-hole itself also needed a stable address outside the pool it was handing to clients.

The current host

The active Pi-hole is reachable at 192.168.1.10 and is running the current Pi-hole v6 API layout. The same Raspberry Pi also runs Docker and Portainer. That makes useful use of a small always-on machine, although it also means DNS and DHCP share a failure domain with general container administration.

That is a trade-off worth documenting. Portainer makes the containers convenient to inspect, but a mistaken host reboot or storage problem could now affect basic network services as well as an experimental stack. Convenience should not disguise dependency.

I had previously experimented with Unbound as a local recursive resolver. It appears to have been removed, so the present article should not describe Unbound as part of the live request path. Before publishing the exact resolver configuration, I need to verify Pi-hole’s current upstream settings rather than relying on memory.

The awkward duplicate

The configuration also contains a duplicate or conflicting host entry involving 192.168.1.11. That address is currently the GMKtec Docker host, whose hostname is gmktec-docker; it is not currently running a Pi-hole container.

This is exactly the kind of configuration debt that accumulates in a long-lived home lab. A machine changes purpose, an old local-DNS record survives, and everything appears healthy because clients already have cached answers. It only becomes obvious when a new client resolves the unexpected name.

The safe correction is to identify every place the name can be defined before deleting anything:

• Pi-hole DHCP reservations;
• local DNS records and CNAMEs;
• the DHCP lease database;
• /etc/hosts entries on relevant machines;
• stale client caches;
• names supplied by the EE hub or another discovery protocol.

Once the authoritative record is clear, the duplicate can be removed and leases renewed deliberately. Changing several sources simultaneously would make it harder to prove which one had caused the conflict.

Operational checks that matter

Because Pi-hole now supplies both addressing and name resolution, testing needs to cover both roles. A client should receive the expected address, gateway, DNS server and home.lan domain. It should resolve local names and public names, and blocked domains should behave as intended.

Useful checks include:

ipconfig getpacket en0        # macOS DHCP details
dig @192.168.1.10 example.com
dig @192.168.1.10 gmktec-docker.home.lan

A maintenance test should also answer a more uncomfortable question: what happens to new and already-connected devices when the Pi is rebooted? Existing leases may keep devices addressed for a while, but DNS dependence will be felt immediately.

What I would change next

The next improvement is not to add complexity blindly. It is to clean the duplicate record, capture the current configuration, decide which Docker workloads genuinely belong on the Raspberry Pi and test restoration of the Pi-hole configuration.

After that, a secondary DNS service may be worthwhile. DHCP redundancy needs more care than simply launching a second server, and any backup DNS instance must have consistent local records and filtering policy. The objective is predictable recovery, not two dashboards that happen to look similar.

Pi-hole made the home network easier to see. The next stage is making that important little service as deliberate to recover as it is convenient to use.