Using Pi-hole for Network-Wide Ad Blocking and Security

What Pi-hole Is

Pi-hole is a DNS sinkhole with a web dashboard. It acts as the DNS resolver for your entire network, checking every domain name query against a blocklist of known advertising, tracking, and malicious domains. Queries for blocked domains return 0.0.0.0 instead of the real IP address, preventing the connection from ever being established.

The result is network-wide ad blocking and malware domain filtering that works for every device - phones, tablets, smart TVs, IoT devices, game consoles - without installing anything on the devices themselves. If a device uses your network's DNS, Pi-hole protects it.

Pi-hole started as an ad blocker but has grown into a legitimate security tool. With the right blocklists, it blocks malware distribution domains, phishing sites, cryptomining scripts, and telemetry endpoints alongside advertisements.

Hardware and Installation

Pi-hole runs on almost any Linux system. The most common deployment is a Raspberry Pi (any model from Pi 2 onward), but it runs equally well on a spare Linux laptop, a virtual machine, or a Docker container.

Hardware requirements are minimal. A Raspberry Pi Zero 2 W with 512 MB of RAM handles DNS for a home network without breaking a sweat. DNS queries are tiny and processing each one takes microseconds. The main resource consumption comes from logging - Pi-hole stores query logs in a database that grows over time.

Installation is a single command. SSH into your Linux system or open a terminal and run the official install script. The installer asks which upstream DNS server to use (Cloudflare, Google, Quad9, or custom), which blocklists to enable by default, and whether to install the web interface (say yes). The entire process takes about five minutes.

After installation, Pi-hole runs as a service and starts automatically on boot. The web interface is accessible at the device's IP address on port 80.

graph TD
    subgraph "Installation Options"
        RPI[Raspberry Pi - Dedicated]
        VM[Virtual Machine]
        DOCKER[Docker Container]
        LINUX[Any Linux Box]
    end
    subgraph "Install Process"
        SCRIPT[Run Install Script] --> UPSTREAM[Choose Upstream DNS]
        UPSTREAM --> LISTS[Select Default Blocklists]
        LISTS --> WEB[Install Web Interface]
        WEB --> DONE[Pi-hole Running]
    end
    subgraph "Post-Install"
        DONE --> DHCP_CFG[Configure Router DHCP to Point DNS to Pi-hole]
        DHCP_CFG --> VERIFY[Verify Queries Flowing Through Pi-hole]
        VERIFY --> CUSTOMIZE[Add Custom Blocklists]
    end
    RPI --> SCRIPT
    VM --> SCRIPT
    DOCKER --> SCRIPT
    LINUX --> SCRIPT

Pi-hole installation flow - from hardware choice to running system with network-wide DNS filtering

Pointing Your Network to Pi-hole

Pi-hole only works if devices send their DNS queries to it. There are two ways to achieve this.

Router DHCP configuration is the preferred method. Log into your router, find the DHCP settings, and change the DNS server address to your Pi-hole's IP address. When devices renew their DHCP lease, they receive the Pi-hole as their DNS server automatically. This covers every device on your network without touching individual device settings.

Manual device configuration is the alternative when your router does not allow changing DNS settings (some ISP-provided routers lock this). You set the DNS server manually on each device. This is tedious and does not cover devices you cannot configure (some IoT devices use hardcoded DNS servers).

After configuration, verify it is working. Open the Pi-hole dashboard and check that queries are appearing. Browse to a known ad-heavy website and confirm that ads are blocked. The dashboard shows the query count climbing in real time as your devices make DNS requests.

Block Lists for Ads and Security

Pi-hole comes with a default blocklist (Steven Black's unified hosts list) that covers common advertising and tracking domains. This blocks most web ads, app ads, and tracking pixels. For security, you need to add additional lists.

Recommended security-focused blocklists include abuse.ch URLhaus for domains distributing malware, PhishTank for confirmed phishing domains, CERT.PL for Polish CERT's malware domain list (internationally relevant), and various community-maintained threat lists available through Pi-hole's blocklist ecosystem.

Adding a blocklist is straightforward: go to Group Management, Adlists in the web interface, paste the URL of the blocklist, save, and run a gravity update (which downloads and processes the lists). Pi-hole automatically updates lists on a schedule, typically weekly.

Start with 3-5 well-maintained lists rather than adding dozens. Each list adds domains to check, and overlapping lists waste processing. More importantly, poorly maintained lists may block legitimate domains, causing frustration when websites break for no apparent reason.

The Dashboard

Pi-hole's web dashboard is where monitoring happens. The main view shows total queries in the last 24 hours, queries blocked (with percentage), the number of domains on your blocklist, and a timeline graph of query volume.

The query log is the most useful security feature. It shows every DNS query from every device, with the result (forwarded, blocked, cached). Sorting by client shows which device makes the most queries. Sorting by domain shows which domains are queried most frequently. Filtering for blocked queries shows what Pi-hole is catching.

Client activity reveals patterns. If your smart TV makes 3,000 DNS queries per day to tracking domains, that is visible. If a device starts querying a domain it has never queried before - especially a domain that looks like random characters - that could indicate compromise.

Top blocked domains show what your blocklists are catching. Expect to see advertising networks, analytics platforms, and telemetry endpoints. If you see blocked domains that look like they could be malware C2 (random-looking strings, recently registered domains), investigate the device that made the query.

Adding Threat Intelligence Feeds

Moving Pi-hole beyond ad blocking into genuine security requires threat intelligence feeds. These are blocklists maintained by security researchers that focus specifically on domains associated with active threats.

The abuse.ch feeds are particularly valuable. Their URLhaus feed tracks domains actively distributing malware. Their Feodo Tracker feed covers domains used by banking trojans. These are maintained by security professionals, updated frequently, and have low false positive rates.

SANS Internet Storm Center publishes domain blocklists derived from their sensor network. These capture domains associated with active scanning, exploitation, and C2 activity observed across the internet.

After adding security feeds, your Pi-hole becomes a passive early warning system. A blocked query from a device to a known C2 domain is a strong indicator that the device is compromised. The query log tells you which device, when, and how frequently it tried to reach the malicious domain.

graph LR
    subgraph "Blocklist Sources"
        ADS[Ad/Tracking Lists]
        MALWARE[Malware Domain Lists]
        PHISH[Phishing Domain Lists]
        C2_LIST[C2 Domain Lists]
        CUSTOM[Custom Blocklist]
    end
    subgraph "Pi-hole"
        GRAVITY[Gravity Database]
        RESOLVER[DNS Resolver]
        LOGGER[Query Logger]
    end
    subgraph "Output"
        BLOCKED[Blocked Queries - Ads and Threats]
        ALLOWED[Allowed Queries - Forwarded Upstream]
        ALERTS[Security Alerts - C2 Hits]
    end
    ADS --> GRAVITY
    MALWARE --> GRAVITY
    PHISH --> GRAVITY
    C2_LIST --> GRAVITY
    CUSTOM --> GRAVITY
    GRAVITY --> RESOLVER
    RESOLVER --> BLOCKED
    RESOLVER --> ALLOWED
    LOGGER --> ALERTS

Pi-hole with security feeds - combining ad blocking lists with threat intelligence for comprehensive DNS-level defense

Limitations You Should Know

Pi-hole is not a silver bullet. Understanding its limitations prevents false confidence.

Same-domain ads. YouTube serves ads from the same domain as video content (googlevideo.com). Blocking that domain blocks all YouTube videos. Pi-hole cannot block ads when the ad content comes from the same domain as legitimate content. This is true for several major platforms.

DoH bypass. Firefox, Chrome, and many applications can use DNS over HTTPS, sending DNS queries directly to Cloudflare or Google encrypted over port 443. This bypasses Pi-hole entirely. Disable DoH in browser settings, or block access to known DoH resolver IPs at your firewall.

Hardcoded DNS. Some devices (Google Chromecast, Amazon Echo) have DNS servers hardcoded and ignore DHCP-provided DNS settings. These devices send queries directly to 8.8.8.8 or similar, bypassing Pi-hole. On pfSense, you can create a NAT rule to redirect all DNS traffic to Pi-hole regardless of the destination the device specifies.

No content inspection. Pi-hole operates on domain names only. It cannot inspect the content of web pages, block specific URLs on an allowed domain, or filter HTTPS content. A malicious page hosted on a legitimate domain passes through Pi-hole without issue.

Advanced Configuration

Several tweaks improve Pi-hole's effectiveness once the basics are running.

Local DNS records. Pi-hole can serve as your local DNS for internal hostnames. Instead of remembering IP addresses, you can create entries like "nas.home" pointing to 192.168.1.50 or "printer.home" pointing to 192.168.1.60.

Conditional forwarding. If your router handles DHCP (not Pi-hole), enable conditional forwarding so Pi-hole can resolve local hostnames by forwarding those queries to your router. This makes the query log show device names instead of just IP addresses.

Regex blocking. For patterns that simple domain lists cannot catch, Pi-hole supports regex-based blocking. A regex like ^[a-z0-9]{12,}\.top$ blocks domains consisting of long random strings with a .top TLD - a common pattern for dynamically generated malware domains.

Pi-hole and Your Security Stack

Pi-hole handles DNS-level defense. It pairs naturally with other tools that cover different layers. A firewall (pfSense/OPNsense) handles IP-level blocking and traffic control. An IDS (Suricata) catches attack patterns in network traffic. And wireless monitoring with the BLEShark Nano catches threats at the WiFi and BLE layer that no DNS-based or network-based tool can see.

When Pi-hole blocks a query and your IDS flags traffic from the same device, you have strong corroborating evidence of compromise. When the Nano detects a new wireless device and Pi-hole logs show queries from a new client, you have identified an unauthorized device at both the wireless and network layers. Each tool's alerts become more actionable when correlated with the others.