Every device on your network asks a DNS server where to find things, dozens or hundreds of times an hour. Ad networks depend on that. So does malware. A news app fires off requests to a dozen tracking domains before the headline even renders, and a compromised smart-home gadget usually gives itself away the same way, by phoning home to a command-and-control domain over plain DNS.
Pi-hole turns that weak point into a checkpoint. It’s a free, open-source DNS sinkhole that runs on a Raspberry Pi, an old laptop, a VM, or a Docker container, and it filters every DNS query your network makes before the connection ever happens. As of August 2026 the project’s stable line is Core v6.4.3, released July 6, 2026, along with FTL v6.7 and Web v6.6, shipped as Docker tag 2026.07.0, and this tutorial’s steps assume that generation of the software, more than a year and a half past the version 6 rewrite’s original debut as v6.0.0 on February 18, 2025. This tutorial walks through a full pi-hole setup in 13 steps: flashing the OS, installing Pi-hole, pointing your whole network at it, adding Unbound for private recursive resolution, and deploying it in Docker. Budget about 70 minutes for the base build, longer if you work through the advanced sections too.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why DNS-Level Blocking Is a Real Security Control in 2026
Ad-blocking is the reason most people first hear about Pi-hole, but the security case is the one worth taking seriously this year. Google’s Cybersecurity Forecast 2026 names AI-enabled threats and defensive automation as the year’s dominant themes, and Fortinet’s 2026 trends research flags deepfake-powered social engineering at scale as a specific rising risk. Neither of those threats skips DNS. Phishing kits still need a domain to resolve. Malware droppers still need to reach a command-and-control server by name before they pull down a second-stage payload.
ISACA’s 2026 trend reporting puts Zero Trust, AI governance, and supply chain protection at the top of the list for security teams this year, and identity-and-network hardening keeps showing up as a practical entry point for organizations that can’t rebuild their whole stack at once. A DNS sinkhole is one of the cheapest pieces of that hardening. It doesn’t replace endpoint protection or a firewall, but it adds a layer that blocks a request before a connection even opens. A domain that never resolves can’t deliver a payload, serve a phishing page, or exfiltrate data to a listener.
Security teams have a name for this approach: protective DNS. Most attacks, from ransomware staging to routine ad fraud, depend on DNS resolution working normally, so filtering at that layer catches a wide range of threats with one control instead of many. Enterprises pay for commercial protective DNS services that do roughly what Pi-hole does for a home network, just with a support contract attached.
Pi-hole applies that idea at the network level instead of per device. Install it once, point your router at it, and every phone, laptop, smart TV, and IoT gadget on the network gets the same filtering without installing anything locally. It’s released under the EUPL-1.2 open-source license, it costs nothing to run beyond electricity, and the project has drawn more than 56,000 stars on its GitHub repository, which says something about how many people already treat it as infrastructure rather than a weekend project, especially given the pace of shipped releases since the February 18, 2025 v6.0.0 rewrite, nine separate tagged Core, FTL, and Web releases and matching Docker image builds in under a year and a half. That activity shows up on the community side too, the announcement thread for the July 2026 FTL v6.7 release had already racked up 1,596 views on Pi-hole’s own Discourse forum by August 2026. The rest of this guide treats it the same way.
What Is Pi-hole and How Does FTLDNS Work
Core, FTL, and Web: Three Pieces, Three Version Numbers
Pi-hole stopped shipping as one monolithic package with the release of Pi-hole v6.0.0, which went stable on February 18, 2025, alongside a Docker image rebuilt on Alpine Linux and tagged 2025.02.0. The project now versions its three components separately: Core (the shell scripts and installer logic), FTL (the DNS resolution and blocking daemon), and Web (the dashboard). The pace since has been steady: a March 4, 2025 bugfix brought FTL v6.0.4, Web v6.0.2, and Core v6.0.5, a March 30, 2025 update pushed FTL and Web to v6.1 alongside Core v6.0.6, and a May 30, 2025 release lined up FTL v6.2, Web v6.2, and Core v6.1 behind Docker tag 2025.05.x. A June 12, 2025 patch landed FTL v6.2.3, Core v6.1.4 followed on July 14, 2025, and an October 25, 2025 release brought FTL v6.3, Web v6.3, and Core v6.2 under Docker tag 2025.10.0. The current stable line, which shipped July 6, 2026, sits at Core v6.4.3 with FTL v6.7 and Web v6.6, a release that closed six security advisories according to Pi-hole’s own announcement. Point releases ship often enough that you should check the current numbers on the official GitHub repository before you install, rather than trust any figure printed in an article.
FTL, short for Faster Than Light, does the actual work. It’s the process that decides whether to answer a query, forward it upstream, or hand back a blocked response. Core and Web talk to FTL through its API instead of touching DNS traffic themselves, which is a big part of why the v6 rewrite split the versioning in the first place: each piece now ships and patches on its own schedule.
What Pi-hole Can and Can’t Block
Pi-hole blocks at the domain level. A query for an ad-network domain or a known malware C2 domain gets a null response instead of an IP address, so the connection never opens. That’s effective against anything tied to a fixed hostname: ad networks, tracking pixels, malvertising redirectors, and a large share of malware and phishing infrastructure.
It’s also limited in predictable ways. Ads served from the same domain as the content around them, YouTube’s in-video ads being the classic example, are much harder to block without breaking the site outright, since the ad and the video share a hostname. Apps and devices that hardcode their own DNS server, or quietly switch to encrypted DNS-over-HTTPS with a provider you haven’t accounted for, route around Pi-hole without telling you. And Pi-hole doesn’t inspect traffic content, so it won’t catch a phishing page hosted on a legitimate, unblocked domain, or malware already talking to a bare IP address with no lookup involved. Treat it as one strong layer, not a full security program on its own. The pitfalls and layered-stack sections later in this guide cover where the other layers go.
Prerequisites and What You’ll Need
You don’t need much to follow this pi-hole setup, and you probably already own most of it.
- Hardware: any always-on Linux machine works, from a Raspberry Pi Zero 2 W to a spare mini PC to a VM on an existing hypervisor. Pi-hole’s own resource footprint is light.
- Software: Raspberry Pi OS (Bookworm-based), Ubuntu Server 22.04 or 24.04, Debian 12, or any Docker host on a reasonably current kernel. The installer checks your OS against a supported list before it runs, so stick to something actively maintained.
- Network access: admin access to your router, to change its DNS or DHCP settings later, plus a way to reach your chosen device over SSH or a local console.
- Time: about 70 minutes for the full 13-step build, including the advanced Unbound and Docker sections. The base install alone, steps 1 through 7, usually takes 20 to 25 minutes.
You don’t need deep networking knowledge going in. If you can log into your router’s admin page and follow a settings menu, you can finish every step here. The table below breaks down the most common hardware and deployment choices.
| Platform | RAM | Good For | Notes |
|---|---|---|---|
| Raspberry Pi Zero 2 W | 512MB | Small homes, single-purpose DNS box | Cheapest dedicated option, Wi-Fi only |
| Raspberry Pi 4 or 5 | 2GB–8GB | Most home and small-office setups | Gigabit Ethernet, room to add Unbound or Docker |
| Old laptop or mini PC | 4GB+ | Repurposing hardware you already own | Usually has Ethernet and reliable power already |
| VM (Proxmox, ESXi, Hyper-V) | 1GB–2GB allocated | Homelabs already running a hypervisor | Easy snapshots and rollback before changes |
| Docker container | Shares host resources | Existing Linux servers or NAS devices | Fastest to redeploy, covered in Step 13 |
| Router with third-party firmware | Varies | Advanced users only | Adds load to a device already handling routing |
Setting Up the Hardware and Operating System
Step 1: Choose Your Hardware
Use the table above as a starting point. A Raspberry Pi 4 or 5 is the safe default for most homes, with enough headroom to run Unbound alongside Pi-hole later, and cheap enough that dedicating it to one job doesn’t sting. If you already run a home server or NAS, skip buying anything and jump to the Docker section in Step 13 instead, since a container adds almost no overhead to a machine that’s already running.
If you’re buying new, a mainstream Raspberry Pi board still beats the alternatives on documentation alone. Pi-hole barely taxes a CPU, so raw speed matters less than the pile of existing guides and forum threads you can lean on when something looks unfamiliar. A secondhand office mini PC, a Dell OptiPlex Micro or Lenovo ThinkCentre Tiny for instance, is arguably the better value if you don’t already own a Pi, since these routinely turn up used for not much money and come with a proper power supply and Ethernet built in.
Step 2: Flash the OS and Enable Headless Access
On a Raspberry Pi, use the official Raspberry Pi Imager to write Raspberry Pi OS Lite to a microSD card or SSD. Before you write the image, open the advanced options (the gear icon in the Imager) and set a hostname, enable SSH, and configure your username, password, and Wi-Fi credentials in advance. That gets you a headless box you can reach over SSH the moment it boots, no monitor or keyboard required. On other hardware, a standard Ubuntu Server or Debian netinst image works the same way, most installers offer an SSH-enabled, no-desktop option during setup.
Step 3: Update the System and Set a Static IP
SSH into your device and pull the latest packages before installing anything else.
sudo apt update && sudo apt full-upgrade -y
sudo rebootPi-hole needs a fixed address. If its IP changes after a router reboot, every device you’ve pointed at it loses DNS until you notice and fix the setting by hand. The Raspberry Pi Foundation’s own Pi-hole tutorial puts it plainly: for a router-based setup, “you’ll first assign your Raspberry Pi a static IP address from your router’s interface, then point your router’s DNS server settings to the Pi-hole’s static IP address.” A DHCP reservation in your router, tying a fixed IP to your device’s MAC address, is the cleanest way to do this, since it works the same regardless of which OS or network manager the Pi-hole host runs. If you’d rather set it directly on the device, current Raspberry Pi OS and Ubuntu Server use NetworkManager:
sudo nmcli connection show
sudo nmcli connection modify "Wired connection 1" \
ipv4.addresses 192.168.1.10/24 \
ipv4.gateway 192.168.1.1 \
ipv4.dns "1.1.1.1" \
ipv4.method manual
sudo nmcli connection up "Wired connection 1"Swap in your own subnet, gateway, and connection name. Run nmcli connection show first to see what your system actually calls its interface, since it isn’t always “Wired connection 1.”
Installing Pi-hole
Step 4: Run the Official Installer
Pi-hole’s own basic install documentation recommends a single curl command that pulls down and runs the setup script:
curl -sSL https://install.pi-hole.net | bashIf piping a script straight into bash makes you uneasy, and for anyone reading this in a cybersecurity context it should at least give you pause, download it first and read it before running anything:
curl -sSL https://install.pi-hole.net -o pihole-install.sh
less pihole-install.sh
bash pihole-install.shThe interactive installer walks through several prompts: which upstream DNS provider to forward unblocked queries to (pick any option here, you can swap it for Unbound later in Step 13), which default blocklists to subscribe to, whether to enable IPv4 and IPv6, and whether to install the web admin interface and its lighttpd web server. Accept the defaults unless you have a specific reason not to. The installer detects your static IP and asks you to confirm it, which is exactly why Step 3 matters.
Step 5: Set Your Admin Password and Confirm FTL Is Running
The installer prints a random admin password at the end of setup. Write it down, or set your own right away:
sudo pihole -a -pThen confirm the FTL daemon actually started, since a failed FTL start is the most common reason a fresh install doesn’t resolve anything:
sudo systemctl status pihole-FTLYou’re looking for “active (running)” in green. If it isn’t, jump ahead to the troubleshooting table later in this guide before continuing.
Touring the Dashboard and Verifying DNS
Step 6: Log Into the Web Interface
Open a browser and go to http://pi.hole/admin/ or, more reliably before your network’s DNS actually points at Pi-hole, http://<device-ip>/admin/. Log in with the password from Step 5. The dashboard’s main page shows queries processed today, the percentage blocked, top blocked domains, top clients, and a breakdown of query types. The Query Log tab shows every individual lookup in real time, which is the single most useful screen for the pi-hole setup and tuning work you’ll do over the next few weeks. Domains handles your allow and deny lists, Group Management controls per-device policy (Step 12), and Settings holds DNS, DHCP, and blocklist configuration.
Keep an eye on the “Queries Blocked” percentage on that main dashboard over your first week. Pi-hole’s own user community reports figures all over the map here, but a typical home network often settles somewhere around 10 to 15 percent of total DNS queries blocked, depending heavily on which lists you’ve subscribed to and how many ad-supported apps and smart devices you run. Don’t chase a specific number. A sudden jump usually just means a new device joined the network, not that something broke.
Step 7: Confirm Pi-hole Is Resolving Queries
Before touching your router, test Pi-hole directly. Point a single query at it from any machine on your network, substituting its IP:
dig doubleclick.net @192.168.1.10
dig google.com @192.168.1.10The first should come back as 0.0.0.0 or NXDOMAIN if your default blocklists loaded correctly. The second should resolve normally. As the Raspberry Pi Foundation’s tutorial notes, once a device is actually configured to use it, “your device should immediately start issuing DNS queries to the Pi-hole,” and you’ll see that traffic land in the Query Log within seconds. If nothing shows up there at all, the device isn’t using Pi-hole yet, which is exactly what the next section fixes.
Pointing Your Whole Network at Pi-hole
A pi-hole setup only protects the devices that actually use it for DNS. The Pi-hole project’s own GitHub documentation is direct about this: “once the installer has been run, you will need to configure your router to have DHCP clients use Pi-hole as their DNS server.” There are three ways to do that, in order of how much of your network they cover.
Step 8: Router-Wide DNS Override
This is the method most homes should use. Log into your router’s admin page, find the DNS settings (often under DHCP or WAN/LAN settings), and replace the primary DNS server with your Pi-hole’s static IP. The Raspberry Pi Foundation’s guide describes this as configuring “Pi-hole as the DNS server for your network,” and it’s the single change that covers every device that gets an address from your router, no per-device setup required.
You’ll be asked for a secondary DNS server too. A public fallback like a second resolver adds resilience if Pi-hole goes down, but any device that happens to query the secondary skips filtering for that lookup. Many admins leave the secondary blank or repeat the Pi-hole IP, and rely on the redundancy approach covered in the advanced tips section instead.
Step 9: Pi-hole as Your DHCP Server (Optional)
Some routers, especially ISP-locked ones, don’t let you set a custom DNS server at all. In that case, configure “Pi-hole as the DHCP provider for your network” instead, as the Raspberry Pi Foundation’s tutorial puts it. Disable DHCP on your router entirely first, then enable it under Settings > DHCP in the Pi-hole dashboard, matching your existing subnet and address range. Do not run two DHCP servers on the same network at once. Devices will grab a lease from whichever one answers first, and you’ll spend an afternoon wondering why half your network ignores Pi-hole.
Step 10: Conditional Forwarding for Local Hostnames
If your router assigns friendly local names to devices (like laptop.local) and you want those to keep working, enable Conditional Forwarding under Settings > DNS, pointing your local domain back at your router’s IP. The web interface supports one domain and one target server natively. More complex, multi-domain forwarding setups need manual edits to dnsmasq configuration files, which is a step past what most home networks require.
| Method | Coverage | Setup Effort | Best For |
|---|---|---|---|
| Router DNS override | Whole network | Low | Most homes, router keeps handling DHCP |
| Pi-hole as DHCP server | Whole network + hostnames | Medium | Routers with limited or no DNS options |
| Per-device manual DNS | Single device | Low | Testing before a network-wide change |
| Conditional forwarding | Local hostnames only | Low | Networks that rely on router-assigned local names |
| VPN-based (WireGuard) | Remote devices | Medium | Filtering phones and laptops off the home network |
That last row matters more than it looks. Our WireGuard VPN setup guide covers tunneling a phone or laptop back to your home network, which is the only way a device on cellular data or public Wi-Fi keeps using your Pi-hole filtering. The advanced tips section revisits this later.
Managing Blocklists and Groups
Step 11: Add Blocklists and Update Gravity
Pi-hole compiles every subscribed blocklist into a single database called gravity. Out of the box, it typically subscribes to a curated hosts-style list similar to the widely used StevenBlack unified hosts project, which pulls in multiple separate ad, tracking, and malware-domain feeds and merges them into one file. That’s a reasonable baseline on its own.
To add more, go to Settings > Blocklists, paste in additional list URLs, and run an update. The Firebog is a widely used, curated directory of blocklists organized by category and marked by how likely each one is to cause false positives, which makes it a sane starting point instead of grabbing random lists from forum posts. For the security side of this tutorial specifically, threat-intelligence lists like URLhaus, which tracks active malware-distribution domains, and general-purpose lists like OISD add real protective value on top of plain ad-blocking.
sudo pihole -gThat command rebuilds gravity from every subscribed list. For exceptions, the Domains page in the web interface handles both allowing and denying individual entries, with a choice between an exact match and a regex pattern, so you can block or permit an entire family of subdomains in one rule instead of adding them one at a time.
Step 12: Create Groups for Per-Device Policy
Pi-hole v6 organizes clients into groups, with Default, Bypass, and No Internet available out of the box as built-in examples. Groups let you apply different blocklists and allow/deny rules to different devices instead of one blanket policy for the whole network. In practice this covers a few recurring cases: a stricter group for kids’ devices, a permissive “Bypass” group for a smart TV or game console that breaks under aggressive filtering, and a locked-down “No Internet” group for an IoT device you want isolated entirely. Create a group under Group Management, assign clients to it by IP or MAC address, then scope specific blocklists and domain rules to that group instead of the whole network.
Advanced DNS: Unbound, Docker, and Encrypted Upstream
Step 13: Add Unbound for Recursive, Private Resolution
By default, Pi-hole forwards every unblocked query to whichever upstream provider you picked during install, which means that provider still sees every unblocked lookup your entire network makes. Unbound replaces that upstream with your own local recursive resolver, one that talks directly to the DNS root and authoritative servers instead of asking a third party. No single outside provider ends up with your full browsing history.
sudo apt install -y unboundCreate /etc/unbound/unbound.conf.d/pi-hole.conf with a configuration along the lines of what Pi-hole’s own official Unbound guide publishes:
server:
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: no
prefer-ip6: no
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: no
edns-buffer-size: 1232
prefetch: yes
num-threads: 1
private-address: 192.168.0.0/16
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12Restart Unbound and test it directly before wiring it into Pi-hole:
sudo systemctl restart unbound
dig pi-hole.net @127.0.0.1 -p 5335Once that returns a real answer, open Settings > DNS in the Pi-hole dashboard, uncheck every preset upstream provider, and add a custom upstream at 127.0.0.1#5335. Pi-hole now filters first, then resolves everything it doesn’t block through your own recursive resolver instead of a third party’s.
Running Pi-hole in Docker
If you already run a home server or NAS, Docker is often faster to deploy and easier to roll back than a bare-metal install. Pi-hole publishes an official image on Docker Hub. Here’s a complete two-container stack combining Pi-hole with a maintained community Unbound image, giving you the same filtered, private, recursive setup as Step 13 in one file:
version: "3"
services:
unbound:
image: mvance/unbound:latest
container_name: unbound
restart: unless-stopped
ports:
- "5335:53/tcp"
- "5335:53/udp"
volumes:
- ./unbound:/opt/unbound/etc/unbound
pihole:
image: pihole/pihole:2026.07.0
container_name: pihole
depends_on:
- unbound
restart: unless-stopped
ports:
- "53:53/tcp"
- "53:53/udp"
- "80:80/tcp"
environment:
TZ: "America/New_York"
FTLCONF_dns_upstreams: "unbound#53"
FTLCONF_webserver_api_password: "changeme"
volumes:
- ./etc-pihole:/etc/pihole
- ./etc-dnsmasq.d:/etc/dnsmasq.dCheck Docker Hub for the current image tag before deploying. 2026.07.0 was current at the time of writing, matching the July 6, 2026 Core v6.4.3 / FTL v6.7 / Web v6.6 release that closed six security advisories, but Pi-hole ships new tags regularly, tracing back through 2025.10.0 (October 2025) and 2025.08.0 (August 2025) to 2025.05.x (May 2025) and the original Alpine-rebuilt 2025.02.0 tag that launched alongside Pi-hole v6.0.0 on February 18, 2025. Set a real password before you run this anywhere reachable. Bring the stack up with docker compose up -d, then follow Steps 6 through 12 exactly as written, the web interface and configuration work identically whether Pi-hole runs bare-metal or containerized. One difference worth knowing: pihole -up is disabled inside the container, since Docker upgrades happen by pulling a new image tag and recreating the container rather than patching in place.
Encrypting Upstream Queries With cloudflared
Pi-hole doesn’t natively speak DNS-over-HTTPS or DNS-over-TLS upstream. If you’d rather encrypt unblocked queries to a public resolver instead of running full recursive resolution with Unbound, pair Pi-hole with cloudflared as a local DNS-over-HTTPS forwarder. Grab the current release for your architecture from Cloudflare’s GitHub releases, then run it as a forwarder listening only on localhost:
cloudflared proxy-dns --address 127.0.0.1 --port 5053 \
--upstream https://1.1.1.1/dns-query \
--upstream https://1.0.0.1/dns-query
sudo cloudflared service installThen set Pi-hole’s custom upstream to 127.0.0.1#5053 instead of the Unbound address. Pick one approach or the other, Unbound for full independence from any third-party resolver, or cloudflared if you’d rather trust a named provider but keep the query encrypted in transit. Running both at once serves no purpose.
Common Pitfalls When Setting Up Pi-hole
Most pi-hole setup problems trace back to one of these six mistakes.
- Running two DHCP servers at once. Enable Pi-hole’s built-in DHCP without turning off your router’s, and devices will grab a lease from whichever one answers first. Half your network silently skips Pi-hole with no error message to warn you.
- Skipping the static IP. Point your router at a Pi-hole address that later changes, and DNS breaks network-wide until you notice and update the setting. Do Step 3 before anything else.
- Loading every blocklist you can find on day one. Aggressive third-party lists, especially the more experimental tiers on directories like Firebog, routinely break banking apps, smart TVs, and game consoles that share domains with ad infrastructure. Add lists gradually and check the Query Log after each one before adding the next.
- Forgetting devices with their own hardcoded DNS. Android’s Private DNS setting, and some smart TVs and streaming boxes, bypass whatever your network hands out over DHCP. These need a per-device override, or you need to block outbound DNS-over-HTTPS at the firewall to force the issue.
- No plan for what happens when Pi-hole goes down. If it’s your network’s only DNS server and the SD card fails or the power drops, nobody gets name resolution, not just ad-blocking. Keep a fallback plan, covered in the advanced tips section below.
- Skipping Teleporter backups. A bad blocklist edit or a failed update can leave you rebuilding hours of allow and deny rules from memory. Export a backup under Settings > Teleporter before any change you’re not fully sure about.
Troubleshooting Pi-hole: Common Problems and Fixes
Work through this table in order before assuming something’s seriously broken. Most pi-hole setup issues have a one-line fix.
| Symptom | Likely Cause | Fix |
|---|---|---|
| No internet on any device after pointing the router at Pi-hole | Pi-hole service is down, or the IP was mistyped in router settings | Run systemctl status pihole-FTL, then re-check the IP entered in your router |
| Dashboard won’t load at pi.hole/admin | The pi.hole hostname isn’t resolving on your device yet | Browse directly to the device’s IP address instead, e.g. 192.168.1.10/admin |
| Ads still appear on YouTube or inside mobile apps | Those ads share a domain with the content itself, or the app uses its own DNS | Expected limitation, pair with a browser-based ad blocker for in-page ads |
| Gravity update fails or times out | One subscribed blocklist URL is offline or unreachable | Run pihole -g, note the failing URL, remove it under Settings > Blocklists |
| A specific site or app stopped working after adding a list | An overly broad list blocked a domain the app depends on | Check the Query Log for the blocked domain, then allowlist it |
| Devices seem to skip Pi-hole entirely | Device is using DNS-over-HTTPS or a hardcoded DNS server | Disable Private DNS on Android, or block outbound DoH provider IPs and port 853 at the firewall |
| High latency on first-time lookups after adding Unbound | Unbound’s cache is cold and prefetching hasn’t warmed up yet | Confirm prefetch: yes is set, then allow a few hours of normal use |
| Web login rejected after changing the password | Password change wasn’t applied in the right context | Re-run sudo pihole -a -p on bare metal, or update the container’s environment variable and recreate it in Docker |
| FTL won’t start after an update | Corrupted gravity database from an interrupted update | Run pihole -r, choose Repair, and let it rebuild |
| IPv6 clients bypass Pi-hole filtering | The router is still advertising a public IPv6 DNS server via Router Advertisement | Disable the router’s own RA-supplied DNS, or set Pi-hole’s IPv6 address as the RDNSS value |
Advanced Tips: Backups, Remote Access, and a Layered Security Stack
Once the base pi-hole setup is stable, a handful of habits keep it that way and make it more useful.
Back up before you touch anything. Settings > Teleporter exports your full configuration, blocklists, and rules into one archive. Get in the habit of pulling one before any change you can’t easily undo.
Update deliberately, not automatically. On a bare-metal install, sudo pihole -up checks for and applies the latest Core, FTL, and Web releases. In Docker, pull a new image tag and recreate the container instead, since in-place upgrades are intentionally disabled there.
Filter your phone off the home network too. Pi-hole only protects devices that query it. Pair it with our WireGuard VPN setup guide so a phone on cellular data tunnels home and keeps using Pi-hole for DNS. Tailscale offers a lower-friction mesh alternative to raw WireGuard for the same purpose, using an exit node to route DNS back through your Pi-hole from anywhere.
Plan for redundancy. If Pi-hole is your only DNS server, its downtime is your network’s downtime. Several community tools exist to mirror one Pi-hole’s configuration to a second instance running on separate hardware, so a failed SD card or a bad update doesn’t take your whole network offline.
Build out the rest of the stack. Pi-hole handles DNS-layer blocking, and that’s one layer among several worth running together. Our Fail2ban tutorial stops SSH brute-force attempts on the same box. CrowdSec blocks malicious IPs network-wide using crowd-sourced threat intelligence. Wazuh adds host-level monitoring and alerting across your fleet. And if you’re ready to replace your ISP router entirely, our pfSense vs OPNsense comparison covers dedicated firewall distributions that sit in front of everything else.
Pi-hole vs AdGuard Home vs Router-Level Blocking
AdGuard Home is the closest open-source alternative to Pi-hole, built as a single Go binary rather than Pi-hole’s more modular shell-and-daemon architecture, and it includes native DNS-over-HTTPS and DNS-over-TLS support out of the box, where Pi-hole needs Unbound or cloudflared bolted on for the same result, as covered in Step 13. Router-level blocking, now built into some mesh router firmware, asks for zero setup but rarely matches either tool’s blocklist customization or query-level logging.
| Feature | Pi-hole | AdGuard Home | Router-Level Blocking |
|---|---|---|---|
| Cost | Free, open source | Free, open source | Varies, sometimes bundled with firmware |
| License | EUPL-1.2 | GPL-3.0 | Vendor-dependent |
| Built-in DHCP server | Yes | Yes | Yes, native |
| Native encrypted upstream (DoH/DoT) | No, needs Unbound or cloudflared | Yes, built in | Rare |
| Web dashboard with query log | Yes | Yes | Varies, often limited |
| Per-client or per-group rules | Yes, via Groups | Yes, via Clients | Rare or absent |
| Setup complexity | Moderate | Moderate | Low if supported, otherwise not available |
For most readers of this pi-hole setup guide, the choice between Pi-hole and AdGuard Home comes down to preference rather than a clear technical winner. Pi-hole has the larger community and more third-party guides. AdGuard Home trades that for a simpler single-binary deployment and encrypted upstream support without extra components. Router-level blocking is fine as a zero-effort baseline, but if you’ve read this far, you’re clearly after more control than that.
What You’ve Built: A Complete, Layered DNS Security Stack
Walk back through what’s actually running at this point. FTL is filtering every DNS query on your network against multiple threat-aware blocklists. Unbound is resolving anything unblocked directly from the DNS root instead of leaking your household’s browsing pattern to a third-party resolver. Groups are applying different rules to your kids’ devices, your IoT gadgets, and everything else on the network. A Teleporter backup is sitting somewhere safe in case any of it needs to be rebuilt from scratch. That’s not a toy ad blocker anymore, it’s a real piece of network infrastructure.
If you followed the Docker path from Step 13, that entire stack lives in one docker-compose.yml file, which means rebuilding it on new hardware after a failure is a five-minute job instead of a lost evening. Either way, extend it deliberately from here. Add one blocklist or one group at a time, using the advanced tips and layered-stack section above as your roadmap, rather than turning on every feature this guide covers in a single sitting.
Frequently Asked Questions
Is Pi-hole really free?
Yes. It’s open source under the EUPL-1.2 license, hosted on GitHub with more than 56,000 stars, with no premium tier or subscription. The only ongoing cost is electricity for whatever device you run it on, typically a few dollars a year for something as small as a Raspberry Pi Zero 2 W.
Will Pi-hole slow down my internet or my devices?
No. If anything, blocked domains resolve faster, since Pi-hole returns an instant local answer instead of waiting on an upstream lookup. Cached queries for allowed domains are also faster than hitting your ISP’s resolver every time. The one exception is right after you add Unbound, when its cache is still cold. That settles within a few hours of normal use.
Can Pi-hole block ads inside apps and on YouTube?
Partially. It blocks ads and trackers served from separate ad-network domains, which covers a large share of mobile app and website advertising. It can’t cleanly block ads served from the same domain as the content, which is how YouTube delivers most in-video ads.
Does Pi-hole protect me when I’m away from home?
Only if you route your traffic back to it. Pair it with a VPN like WireGuard or Tailscale so your phone tunnels home over cellular or public Wi-Fi, and it keeps using Pi-hole for DNS the same way it would sitting on your home network.
Is Pi-hole a replacement for a firewall or antivirus?
No. It’s one layer, DNS-level filtering, not a full security program. It won’t inspect file downloads, scan a device for malware already installed, or stop an attacker who’s already inside your network. Pair it with endpoint protection, and if you’re running servers, tools like Fail2ban or CrowdSec.
How much maintenance does Pi-hole actually need?
Minimal. Gravity updates on its own schedule once configured, and pihole -up handles version updates on bare-metal installs. Budget occasional attention for when a blocklist goes stale or a new device on your network needs an allowlist exception.
Can I run Pi-hole without a Raspberry Pi?
Yes. Any Linux machine works, including old laptops, VMs, and Docker hosts. The Docker route from Step 13 is often the fastest path if you already run a home server or NAS, since there’s no new hardware to buy or maintain.
What happens if the device running Pi-hole goes offline?
If it’s your network’s only DNS server, every device loses name resolution until it comes back, not just ad-blocking. That’s why the pitfalls section recommends a fallback plan, and why some households run a second, synced instance for redundancy.
Related Coverage
- How to Set Up WireGuard VPN: 12 Steps, 45 Min [2026]
- Fail2ban: Stop SSH Brute-Force in 12 Steps, 30 Min [2026]
- CrowdSec: Block Malicious IPs in 12 Steps, 40 Min [2026]
- Wazuh Tutorial: Free SIEM in 14 Steps, 40 Min [2026]
- pfSense vs OPNsense 2026: Free, but 26 vs 2 Updates
- How to Set Up TOTP MFA: 12 Steps, 60 Min [2026]
