The Beauty of Having a Pi-Hole (2024)

Original Article ↗ Hacker News Discussion ↗

DNS arms race and Pi-hole limitations

  • Many comments note that simple iptables rules that redirect port 53 only catch plain DNS; apps using DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), hardcoded DNS, or even custom HTTP-based DNS bypass Pi-hole completely.
  • Browsers and apps increasingly ship with DoH (e.g., Telegram, iOS, some IoT), making router-level DNS interception less effective.
  • Workarounds discussed:
    • Blocking known DoH/DoT IPs and hostnames via curated blocklists.
    • Enterprise-style tools (e.g., Zenarmor) that detect and intercept DoH.
    • Aggressive approaches: mapping every AAAA/A lookup to NAT’d addresses and only allowing connections to those, or stateful rules that drop connections to IPs not resolved via the local resolver.
  • Several people frame this as an endless “arms race”; some think TLS MITM and certificate pinning make deeper inspection increasingly impractical, especially for IoT.

Alternatives and deployment models

  • You don’t need a Raspberry Pi or Pi-hole specifically: dnsmasq, Unbound, AdGuard Home, pfBlocker, OPNSense/RouterOS, etc., can provide similar DNS-level blocking.
  • Many run Pi-hole/AdGuard in Docker or VMs on always-on machines, NASes, or VPSes. Others use NextDNS (cloud), sometimes combined with Tailscale for roaming devices.
  • Several point out that a Pi 5 kit is overkill; even very old Pis (Zero, Model B) or small x86 mini-PCs easily handle the load.

Why use network-wide blocking at all?

  • Pro-Pi-hole arguments:
    • Covers non-browser traffic: mobile apps, smart TVs, game consoles, IoT, desktop software telemetry.
    • Useful for nontechnical family members and guests without configuring every device.
    • Provides insight into what devices are “phoning home”.
  • Many combine Pi-hole/AdGuard with uBlock Origin/SponsorBlock in browsers for layered blocking.

Usability, breakage, and reliability

  • DNS-level blocking can break services expecting ads or ad domains (e.g., streaming services, Google ad click-throughs, some payment/log-in flows).
    • Typical mitigation: inspect Pi-hole logs and selectively whitelist problem domains.
  • Some report months–years of “set and forget” stability; others mention mysterious failures, network outages when the Pi-hole is down, or family unable to troubleshoot.
    • Suggested mitigations: static IPs, dual Pi-holes, fallback DNS, separate SSIDs/guest networks, VPN access to fix issues remotely.

Broader views on the modern web

  • Several see Pi-hole as essential because “raw” internet with full ads/telemetry feels unusable.
  • Others argue the underlying problem is hostile, ad-driven service design; some try to reduce connected devices or avoid ad-heavy sites altogether, or worry about depriving smaller sites of ad revenue.