Networking lab / April 22, 2026
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 ad blocking and a better understanding of DNS behavior. The intended design was simple: reserve a stable address for the Raspberry Pi, run Pi-hole there, and have the gateway advertise that address as the network’s DNS resolver.
Receives network settings from DHCP.
Receives and filters DNS queries.
Resolves allowed requests.
02 / Direct test
I first tested the Pi-hole directly instead of assuming the router was sending traffic to it:
nslookup google.com 10.0.0.50
The lookup succeeded and appeared in the Pi-hole dashboard. That established two facts: the Raspberry Pi was reachable, and the Pi-hole DNS service itself worked.
03 / Observation
Client devices continued using Comcast DNS, including addresses associated with cdns01.comcast.net. The stock gateway did not provide reliable control over the DNS server advertised to every device.
IPv6 created a second path. The gateway could advertise an IPv6 resolver such as 2001:558:feed::1, 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 network became unstable and some devices stopped receiving usable addresses.
The recovery step was to restore one authoritative DHCP service, reconnect affected devices, and return to direct testing before making additional network-wide changes.
DNS determines where name lookups go. DHCP determines who supplies devices with addresses and network settings. Changing one without defining ownership of the other can affect the entire network.
05 / Result
The safe temporary workaround was per-device DNS configuration pointing to 10.0.0.50, with IPv6 behavior checked so it could not silently bypass Pi-hole.
For reliable network-wide filtering, the recommended architecture is to place the Xfinity gateway in bridge mode and use a router that provides explicit DHCP and DNS control. The alternative is deliberate per-device configuration.
06 / Method