Networking lab / April 2026
Pi-hole DNS, DHCP, IPv4/IPv6, and gateway-control investigation
The Pi-hole service worked. The network-wide design did not. Separating those facts exposed the real DNS, DHCP, IPv6, and router-control problem.
01 / Goal
The initial goal was network-wide filtering and a better understanding of DNS behavior. The intended design was simple: reserve an address for the Raspberry Pi, run Pi-hole there, and have the gateway advertise that resolver to client devices.
Receives network settings from DHCP.
Receives and filters DNS queries at a reserved private address.
Resolves allowed requests.
02 / Direct test
I first queried the Pi-hole directly instead of assuming the gateway was sending traffic to it.
nslookup example.com <pi-hole-private-address>
The lookup succeeded and appeared in the Pi-hole dashboard. That established two facts: the Raspberry Pi was reachable, and the DNS filtering service itself worked.
03 / Observation
Client devices continued using resolvers advertised by the ISP-supplied gateway. The gateway did not provide reliable control over the DNS server advertised to every device.
IPv6 created a second path. The gateway could advertise its own IPv6 resolver, allowing devices to bypass the IPv4 Pi-hole configuration even when their visible IPv4 settings appeared correct.
Direct requests reached Pi-hole and resolved normally.
The gateway did not consistently direct client DNS traffic to Pi-hole.
04 / Failure
I tested whether Pi-hole could take over DHCP so it could advertise the desired DNS configuration. When both the gateway and Pi-hole attempted to control DHCP, the lab network became unstable and some test clients stopped receiving usable addresses.
The recovery step was to restore one authoritative DHCP service, reconnect affected clients, and return to direct testing before making additional network-wide changes.
DNS determines where name lookups go. DHCP determines who supplies clients with addresses and network settings. Changing one without defining ownership of the other can affect the entire segment.
05 / Result
The safe temporary workaround was deliberate per-device DNS configuration, with IPv6 behavior checked so it could not silently bypass Pi-hole.
For reliable network-wide filtering, the recommended architecture is to place the ISP-supplied gateway in bridge mode and use a router that provides explicit DHCP and DNS control. The alternative is controlled per-device configuration.
The investigation preserves the architecture, tests, failure, and recovery while omitting internal addresses, resolver hostnames, physical-network images, and provider-specific identifiers.
06 / Method