Blocky – a DNS proxy and ad-blocker for the local network

Original Article ↗ Hacker News Discussion ↗

Network-wide DNS ad blockers like Blocky, Pi-hole, and AdGuard Home promise cleaner, more private browsing across all devices, but users report trade-offs such as occasionally broken sites, Google Search ads that can’t be clicked, and added complexity for non-technical household members. Commenters compare tools and configurations — from curated blocklists like OISD to multiple SSIDs, quick toggles, and API integrations — to reduce false positives and make it easier to temporarily disable filtering. There is also debate over privacy strategies, such as whether spreading DNS queries across multiple upstream resolvers actually helps, and how projects like Blocky stack up against mature alternatives in terms of performance, configurability, and ease of deployment.

Network-level ad blocking: benefits and pain points

  • Many use DNS-level blockers (Pi-hole, Blocky, AdGuard Home, dnsmasq setups) plus browser extensions (uBlock Origin).
  • DNS-level blocking shines for:
    • Whole-network coverage (TVs, mobile apps, IoT, “phone home” devices).
    • Silencing chatty or privacy-invasive devices.
  • Main complaint: some sites or features break, often in subtle ways (e.g., banking rewards, e‑commerce search, Google Ads links, Shopify, Home Depot).

Managing breakage and usability

  • Users describe friction for non-technical household members; troubleshooting is harder when cause isn’t obvious.
  • Common workarounds:
    • Temporary disable via Pi-hole API, mobile apps, browser extensions, or Home Assistant / smart-home buttons.
    • Multiple SSIDs/VLANs: some with adblocking, some without.
    • Manually whitelisting problematic domains or switching DNS profiles on device.
    • Using browser containers or SOCKS5 proxies to bypass DNS filtering per-tab.
  • DNS caching can delay seeing the effect of toggling, adding confusion.

Block lists and tuning

  • OISD is repeatedly praised for strong blocking with few breakages; others report more false positives with other lists.
  • Several emphasize that issues are more about blocklist quality/configuration than about DNS-level blocking itself.

Privacy and upstream DNS strategy

  • Blocky’s feature of randomly choosing among upstream resolvers is questioned.
  • Multiple commenters argue this reduces privacy:
    • More providers see parts of your traffic; you must trust all of them.
    • Analogy drawn to Tor’s “entry guard” design: stick to a small, consistent set.
  • Alternatives suggested: single trusted resolver (e.g., with stronger privacy commitments), local recursive resolvers, VPN provider DNS, Oblivious DNS / DNSCrypt v3, Tor.
  • Some note that local resolvers can be brittle (downtime, leaks), leading them to rely on external privacy-focused resolvers.

Blocky vs. Pi-hole / AdGuard / others

  • Blocky perceived as:
    • Single binary, single YAML config, “stateless”, resource-light, and fast.
    • Strong DoH/DoT support and Prometheus metrics integration.
    • Lacks a built-in web UI; favored by users who prefer text configs and Docker deployment.
  • Pi-hole praised for maturity and friendly UI, especially for non-experts.
  • AdGuard Home valued for:
    • Using typical browser adblock lists.
    • Features like optimistic caching.
  • Other options mentioned: dnscrypt-proxy, PFBlockerNG, NextDNS.

Other notes and limitations

  • DNS-level blockers can’t handle app-level issues like YouTube Shorts UI; users resort to alternative clients, patched apps, or browser-based viewing.
  • DNS conditional forwarding (e.g., for archive.* domains vs. Cloudflare) is cited as a useful feature, achievable in Blocky and dnsmasq.