Setting Up Pi-hole on Xfinity: What Actually Happened - 4/22/2026

I set up Pi-hole on a Raspberry Pi because I wanted network-wide ad blocking and a better understanding of how DNS traffic actually moves through a home network. The plan sounded simple: give the Pi a stable address, point the network at it for DNS, and let every device use Pi-hole automatically.

I installed Pi-hole headlessly on the Raspberry Pi, reserved the static IP 10.0.0.50 through the router, and configured Cloudflare as the upstream DNS provider. Before touching the whole network, I tested the Pi directly with nslookup google.com 10.0.0.50. That worked, and the queries showed up in the Pi-hole dashboard, so I knew the Pi-hole service itself was not the problem.

The real issue was the Xfinity gateway. The router did not give me reliable control over custom DNS for the whole network, so devices kept using Comcast DNS instead. I saw traffic still going through cdns01.comcast.net, and IPv6 made it even trickier because Xfinity was handing out DNS like 2001:558:feed::1. That meant some devices could bypass Pi-hole without making it obvious from the normal IPv4 settings.

I also tested whether Pi-hole could take over DHCP, because that would let it tell devices which DNS server to use. That taught me the difference between DNS and DHCP in a way a textbook never really does. DNS decides where name lookups go. DHCP decides who gives devices their network identity and settings. When the router and Pi-hole both tried to be in charge of DHCP, the network became unstable, some devices stopped getting usable addresses, and I lost internet completely for a bit.

What I Debugged

• Confirmed Pi-hole worked by querying 10.0.0.50 directly instead of assuming the router was sending traffic there.
• Checked the Pi-hole dashboard to prove DNS queries were reaching the Raspberry Pi.
• Compared what I configured against what devices actually used, which exposed the Comcast DNS fallback.
• Separated DNS settings from DHCP control after realizing they solve different parts of the problem.
• Tracked IPv6 as a bypass path instead of only looking at IPv4 DNS settings.
• Worked around Pi-hole DHCP page glitches and reloads by focusing on the network behavior, not just what the UI seemed to say.

Instead of randomly changing settings, I started isolating each layer. I tested Pi-hole directly, checked whether queries appeared in the dashboard, looked at which DNS servers devices were actually using, and separated a working Pi-hole install from the router limitations around it. The temporary workaround was per-device configuration: manually point devices at 10.0.0.50 for DNS and disable IPv6 where needed so traffic could not silently bypass the Pi-hole.

The conclusion was pretty clear: full network-wide Pi-hole is not realistic on a stock Xfinity gateway unless I either put the gateway in bridge mode and use my own router, or configure devices one by one. That sounds like a failed setup, but it was honestly a better learning project because I had to understand the actual network instead of just following a guide.

The biggest thing I learned was that you should not start configuring a network until you understand who controls each part of it. I came away with a much better understanding of DNS resolution, DHCP, MAC-based device identity, IPv4 vs IPv6 behavior, router limitations, and how to test safely before making changes that affect every device in the house.

Next time, I would identify router limitations first, choose the architecture before touching global settings, and use either bridge mode with my own router or a deliberate per-device setup. The lesson was simple: understand the system before configuring the system.

Learning Linux and Security Tools - 1/15/2026

I started using Linux freshman year of high school. At first it was mostly live boots, then full installs, then distro hopping because I wanted to understand how different systems felt when I actually had to use them.

I have used Kali, Arch, and Linux Mint. Mint was the one I daily drove for a while because it was stable enough to actually get work done. Kali was useful for learning security tools, and Arch taught me more about how Linux is put together because it makes you touch more of the system yourself.

The biggest value was getting comfortable when something broke. Boot issues, packages, drivers, permissions, network settings, desktop environments, and weird config problems all forced me to troubleshoot instead of panic. That matters because a lot of technical work is just staying calm long enough to find the real problem.

I also spent a lot of hours learning tools like Nmap and Metasploit in lab and authorized environments. Nmap helped me understand hosts, ports, services, and why exposed services matter. Metasploit helped me understand how security testing is structured: modules, payloads, targets, and the difference between a vulnerability existing in theory and actually verifying behavior in a controlled setup.

I do not think the tools are the impressive part by themselves. Anyone can run commands. The useful skill is understanding what the output means, what question you are trying to answer, and what risk you might create if you touch the wrong system.

This experience gave me a stronger base for networking and cybersecurity. It made DNS, ports, services, permissions, shells, and misconfiguration feel real instead of abstract. It also taught me to respect boundaries: test in labs, document what changed, and do not run security tools against systems you do not own or have permission to test.