How To Install Pi-Hole on Ubuntu 26.04 LTS

Pi‑hole looks like “just” a network‑wide ad blocker at first glance, but in practice it becomes a DNS firewall that sits in front of every device on your network. It intercepts DNS queries, checks them against blocklists, and sinkholes anything you deem unwanted—ads, trackers, malware C2 hosts, phishing domains—before the connection even leaves your LAN.

On a modern Ubuntu 26.04 LTS box, Pi‑hole v6 is light on resources, trivial to automate, and much easier to harden than the old v5 stack thanks to its single‑binary architecture and TOML‑based configuration. If you already run Ubuntu for web workloads, it’s natural to dedicate a small VM or bare‑metal node to DNS filtering and tie it into your existing monitoring and backup routines.

From a sysadmin’s point of view, Pi‑hole solves three problems at once:

It reduces noise and page weight for users by stripping ads and trackers at the DNS layer.
It adds a security control that is independent of the endpoint OS—phones, smart TVs, IoT boxes all benefit without running agents.
It generates a clean log of who is talking to what on your network, which is invaluable when you’re hunting down compromises or misbehaving devices.

In this guide, we’ll build a Pi‑hole v6 deployment on Ubuntu 26.04 LTS that is suitable for long‑term use: static IP, Unbound recursive DNS, hardened firewall, and sane performance tuning.

Table of Contents

Understanding Pi‑hole v6 On Ubuntu 26.04 LTS

Pi‑hole v6 introduced a significant architectural shift that matters for how you install and manage it on an LTS server.

What Changed In Pi‑hole v6

The old mix of lighttpd, PHP, and FTL has been collapsed into a single pihole-FTL binary that embeds the web server and REST API.
Configuration now lives in a single TOML file (/etc/pihole/pihole.toml), replacing scattered setupVars.conf and dnsmasq snippets.
Native HTTPS support for the admin UI reduces the need for reverse proxies in simple setups.
There’s a clear split between Basic and Expert interface modes so you can hide the advanced knobs until you need them.

On Ubuntu 26.04 LTS, that translates to fewer moving parts to maintain, easier automation (everything can be controlled via the CLI or REST API), and a smaller attack surface.

Why Ubuntu 26.04 LTS Works Well For Pi‑hole

Current Pi‑hole documentation lists recent Debian and Ubuntu LTS releases as supported, with modest resource needs—512 MB RAM and a few gigabytes of disk are enough for most home or small office deployments. Ubuntu 26.04 LTS gives you:

A long support window for security patches.
Modern systemd, nftables/UFW, and package versions that match documented Pi‑hole and Unbound setups.
Familiar tooling (apt, netplan, timedatectl) that simplifies static IP and DNS configuration.

If you already run Ubuntu for Nginx, databases, or SEO tooling, Pi‑hole slots in nicely as another light service.

Planning Your Pi‑hole Host On Ubuntu 26.04

Before touching the installer, decide where Pi‑hole will live and how it fits into your network.

Hardware and Network Requirements

Pi‑hole doesn’t need much: official guidance calls for 512 MB RAM and 2–4 GB disk, with wired Ethernet and a static IP address as the only hard requirements. For Ubuntu 26.04 LTS you’ll be comfortable with:

1–2 GB RAM if you plan to add Unbound and large blocklists.
A small SSD or VM disk (8–16 GB) so query logs and gravity database don’t crowd the OS.
Stable, wired connectivity; avoid Wi‑Fi for a DNS server—packet loss and link flaps translate directly into “internet is broken” complaints.

Pick an IP outside your router’s DHCP pool, such as 192.168.1.53, and reserve it mentally for the Pi‑hole host. Using .53 is a nice mnemonic for the DNS port.

Ubuntu Server Layout Considerations

On a production‑style Ubuntu 26.04 LTS setup, think in terms of roles:

Dedicated VM or small bare‑metal node for Pi‑hole, separate from web workloads. If DNS goes sideways, you don’t want it entangled with your primary web stack.
Single NIC, single LAN subnet configuration. Complex multi‑NIC setups are possible but introduce more failure modes.

If you already have a hypervisor (Proxmox, KVM, VMware) it’s common to spin up a tiny Ubuntu Server VM and assign it that static address with a reserved DHCP lease.

Step 1: Set A Static IP On Ubuntu 26.04 LTS

Static IP is non‑negotiable for Pi‑hole. If the resolver’s address moves, your entire network loses DNS.

Configure Netplan For A Static Address

On Ubuntu 26.04, Netplan is the standard way to manage network configuration. Create or edit /etc/netplan/01-pihole.yaml:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.1.53/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Apply the configuration:

sudo netplan apply

Using public resolvers here is fine during initial setup; Pi‑hole will later take over DNS on the box itself. Confirm the address:

ip a

You should see 192.168.1.53/24 bound to eth0.

Alternative: DHCP Reservation

If you prefer hands‑off configuration, you can set a DHCP reservation on your router keyed to the host’s MAC address, so it always gets the same IP. In practice, explicit Netplan static addresses give you clearer behavior when debugging.

Step 2: Update Ubuntu 26.04 LTS And Install Prerequisites

A DNS firewall should not run on a half‑patched OS. Bring the system current, set the timezone, and install tooling Pi‑hole needs.

sudo apt update && sudo apt full-upgrade -y
sudo timedatectl set-timezone Asia/Jakarta
sudo apt install -y curl git ufw

If the kernel updates, reboot:

sudo reboot

Accurate time matters for logs, TLS verification, and any future use of DNSSEC. curl is required for the one‑line installer; git enables manual installation; ufw will be used later to lock down the host firewall.

Step 3: Install Pi‑hole On Ubuntu 26.04 LTS

Pi‑hole provides a maintained one‑line install script and a more traditional clone‑and‑run flow.

Option A: One‑Line Automated Install

This is the quickest path:

curl -sSL https://install.pi-hole.net | bash

The script pulls the latest Pi‑hole version and runs a curses‑based wizard. The wizard will:

Verify your static IP (it should pick up 192.168.1.53).
Ask you to choose an upstream DNS provider (we’ll replace this with Unbound later, so pick any for now).
Offer to install the web interface and set an admin password.

At the end you’ll see a summary with the admin URL and generated password, such as:

Web Interface password: aXf9-Q2kd
View the web interface at http://192.168.1.53/admin

Make a note or plan to change it immediately.

Option B: Clone The Repository Manually

If you prefer to inspect the installer script first, Pi‑hole documents an alternative where you clone the repo and run basic-install.sh.

git clone --depth 1 https://github.com/pi-hole/pi-hole.git Pi-hole
cd "Pi-hole/automated install/"
sudo bash basic-install.sh

Functionally this is equivalent to the one‑liner; the difference is that you have the script locally and can audit it before execution.

Verify Installation

Once the wizard finishes, confirm Pi‑hole is up:

pihole status

You should see that FTL is running and blocking enabled. On a fresh install, the dashboard will show zero clients and a small number of cached queries until you begin pointing devices at it.

Step 4: Secure The Admin Interface And Password

The admin interface controls both web UI and API, so treat its password like any other privileged credential.

Set A Strong Password

Pi‑hole’s current documentation exposes a CLI command to change the password.

# Interactive
sudo pihole setpassword

# Or non-interactive for automation
sudo pihole setpassword 'Str0ng-Admin-Pass-Here!'

If you followed older guides, you may see pihole -a -p referenced; newer v6 builds use setpassword but your environment may support both forms.

Access The Web Dashboard Over HTTPS

Browse to:

http://192.168.1.53/admin or
https://192.168.1.53/admin (accept the self‑signed certificate warning).

Pi‑hole v6 uses an embedded CivetWeb server and can serve HTTPS natively. Later, you can replace the default cert with one from your internal CA or Let’s Encrypt if you reverse‑proxy from another host.

On first login, flip from Basic to Expert mode in settings so you can see the full range of configuration options: upstream DNS, interface binding, DNSSEC, and more.

Step 5: Make Your Network Actually Use Pi‑hole

Installing Pi‑hole without pointing clients at it is a common “it does nothing” mistake. The clean way is to change your router’s DHCP DNS settings.

Set Pi‑hole As The Sole DHCP DNS Server

On your router:

Find the LAN or DHCP configuration screen.
Set the primary DNS server to 192.168.1.53.
Remove any secondary public DNS server (like 8.8.8.8 or 1.1.1.1).

If the router insists on a second entry, use a second Pi‑hole instance instead of a public resolver, otherwise clients will bypass filtering intermittently.

Renew leases on client devices (reboot, reconnect Wi‑Fi, or trigger a DHCP refresh) and watch the Pi‑hole dashboard; total client count should climb, and the query log should show new requests from your LAN.

Lock Down Direct DNS Bypasses

Some devices or users will try to hardcode their own resolvers. The practical defence is at the firewall level:

Allow outbound DNS (UDP/TCP 53) only from 192.168.1.53.
Block outbound DoT (TCP 853) for all clients except the Pi‑hole host if you later use TLS upstream.

On Ubuntu using UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow from 192.168.1.0/24 to any port 53 proto udp
sudo ufw allow from 192.168.1.0/24 to any port 53 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 443 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

sudo ufw enable
sudo ufw status verbose

This assumes your LAN is 192.168.1.0/24; adjust for your environment.

On your main router or firewall (OPNsense, MikroTik, UniFi, etc.) mirror the same idea: DNS out to the internet only from Pi‑hole, everyone else MUST talk to Pi‑hole.

Step 6: Add Unbound For Private Recursive DNS

By default, Pi‑hole forwards allowed queries to an upstream provider like Google or Cloudflare. That works, but hands a full log of your browsing to a third party. Unbound gives you a recursive resolver running locally, so queries are resolved from the root DNS servers down, with DNSSEC validation.

Install Unbound On Ubuntu 26.04 LTS

sudo apt install -y unbound

Pi‑hole’s documentation provides a reference configuration for using Unbound. Create /etc/unbound/unbound.conf.d/pi-hole.conf:

server:
    verbosity: 0
    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
    so-rcvbuf: 1m

    private-address: 192.168.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

This is drawn directly from Pi‑hole’s Unbound guide and tuned to avoid EDNS fragmentation and to cache aggressively.

Restart and test Unbound:

sudo systemctl restart unbound
dig pi-hole.net @127.0.0.1 -p 5335

You should see status: NOERROR and a valid A record.

Point Pi‑hole At Unbound

In the Pi‑hole web UI (Settings → DNS):

Uncheck all default upstream DNS providers (Google, Cloudflare, etc.).
Add a custom upstream: 127.0.0.1#5335.

Or via CLI with the v6 config tool:

sudo pihole-FTL --config dns.upstreams '[\"127.0.0.1#5335\"]'
sudo systemctl restart pihole-FTL

Now Pi‑hole asks Unbound for every non‑cached domain, and Unbound walks the DNS tree itself.

Optional: Performance Tuning For Unbound

On modest hardware, you can balance latency and memory with a few extra directives:

    serve-expired: yes
    cache-min-ttl: 300
    cache-max-ttl: 86400
    msg-cache-size: 128m
    rrset-cache-size: 256m

These allow Unbound to serve slightly stale answers while it refreshes them and give hot records more cache space. On a 1 GB VM this is comfortable; on 512 MB, reduce the cache sizes accordingly.

Step 7: Choose And Manage Blocklists Carefully

Pi‑hole ships with a default blocklist (often based on StevenBlack’s unified hosts) that already covers a large number of ad and tracker domains. Many tutorials suggest piling on multiple lists, but in practice too many lists lead to false positives and broken sites.

Adding Security‑Focused Lists

Through the web UI (Lists / Adlists):

Start with the default unified list.
Add one or two curated malware/phishing feeds.
Optionally add a telemetry/analytics list if you’re comfortable blocking some “big tech” domains.

After adding or removing list URLs, rebuild gravity:

sudo pihole -g

This aggregates all lists into a single optimized block database.

Watch your “Domains on Adlists” count on the dashboard. Jumping from ~80k entries to several hundred thousand is fine; leaping into the millions is when you start breaking legitimate services.

DNSSEC And False Positives

If you’re using Unbound with DNSSEC validation enabled (as in the reference config), leave Pi‑hole’s own DNSSEC toggle off to avoid double validation that often results in SERVFAIL. When a site misbehaves, use Pi‑hole’s query log to spot which domain is blocked, then whitelist only that entry.

Step 8: Harden Pi‑hole On Ubuntu 26.04 (Security Considerations)

Pi‑hole v6 recently addressed multiple security advisories in its FTL and web components, including session bypasses and potential CivetWeb configuration injection. Good hygiene on the Ubuntu host goes a long way.

Keep Pi‑hole Updated

Pi‑hole provides a CLI updater:

sudo pihole -up

This pulls current versions of Core, FTL, and Web. Make it routine—after OS patching, check Pi‑hole releases and update when a new v6 build lands.

Restrict Listening Interfaces

Within Pi‑hole settings or via CLI, ensure it only listens where it should:

Bind DNS only to the LAN interface or “Local networks” mode.
Do not expose port 53, 80, or 443 from the WAN to the Pi‑hole host.

Never port‑forward Pi‑hole’s admin UI from the internet; if you need remote access, reach it through a WireGuard or other VPN tunnel.

Use UFW Or nftables On The Host

Earlier we configured UFW to restrict incoming DNS and web access to the LAN. For more granular setups (multiple VLANs), you can mirror that logic in nftables with per‑subnet rules, but the high‑level intent is the same: the resolver should only ever answer traffic from your trusted internal addresses.

Step 9: Performance Tuning On Ubuntu 26.04

Pi‑hole’s impact on CPU, RAM, and disk IO is small, but on low‑resource nodes—or busy home/office networks—it’s worth tuning.

CPU And RAM

Pi‑hole’s FTL engine is written in C and efficient; CPU spikes usually come from:

Excessive blocklists causing large lookup work.
DNS‑over‑HTTPS clients outside Pi‑hole causing load and timeouts.

Keep blocklists lean and disable browser DoH (Firefox policies, Chrome flags, Apple iCloud Private Relay) so Pi‑hole sees standard DNS.

Unbound’s caching settings (see earlier) trade RAM for latency. On a small VM:

Check top or htop during peak usage.
Adjust msg-cache-size and rrset-cache-size if you consistently run high memory.

Disk IO And Logging

Pi‑hole logs queries to its database for long‑term statistics. On spinning disks or shared VM storage:

Consider shortening query retention from the GUI if IO becomes a concern.
Place Pi‑hole’s data directory (/etc/pihole) on SSD where possible.

For larger networks, offload logs to a central syslog server or SIEM to avoid bloating local storage.

Network Latency

Because Pi‑hole sits in front of every DNS query, network health between clients and the Ubuntu host matters:

Keep Pi‑hole on the same switch or VLAN as your main clients when possible.
Avoid problematic power‑saving NIC settings or flapping interfaces.

A simple dig from a client will tell you a lot:

dig example.com @192.168.1.53

Look at the query time—in a healthy setup, cached answers should be near‑instant, and fresh queries still in the low‑millisecond range.

Step 10: Backups And Updates (Teleporter, Unattended Upgrades)

Treat Pi‑hole like any other service: configuration and state should be recoverable in minutes, not hours.

Use Teleporter For Configuration Backup

Pi‑hole’s Teleporter tool exports settings, lists, and clients as a zip archive.

From the CLI:

sudo pihole-FTL --teleporter

This writes a file like pi-hole_<host>_teleporter_<timestamp>.zip. Copy it off the host—NAS, encrypted backup volume, or your existing backup tooling. Restoring this archive on a fresh install reconstructs your configuration without redoing all the manual steps.

Automate OS Patching

Ubuntu’s unattended-upgrades is a good fit for a Pi‑hole host; you don’t want DNS locked to quarterly manual patch windows.

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

This keeps security updates flowing automatically. Combine it with monitoring so you know when reboots happen and can confirm Pi‑hole comes back cleanly.

Troubleshooting Pi‑hole On Ubuntu 26.04 LTS

Even with careful planning, some failure modes pop up regularly. Understanding them saves a lot of frustration.

Common Symptoms And Fixes

Pi‑hole and third‑party guides document recurring issues very similarly.

Web UI unavailable / “connection refused”
Likely FTL isn’t running or port conflicts with an old lighttpd. Check:
```
sudo systemctl status pihole-FTL
sudo systemctl restart pihole-FTL
```
Ensure no other service listens on port 80/443 if Pi‑hole owns them.
No DNS resolution from clients
Often Unbound not listening or upstream misconfigured. Test directly:
```
dig pi-hole.net @127.0.0.1 -p 5335
```
If that fails, fix Unbound; if it works, check Pi‑hole’s upstream settings.
Ads still appear
Client isn’t using Pi‑hole, is using DoH, or is falling back to a secondary DNS in DHCP. Verify client DNS settings and firewall rules; disable browser DoH and remove secondary DNS values.
Random SERVFAIL errors
Most often caused by double DNSSEC validation (Unbound + Pi‑hole). Turn off Pi‑hole’s DNSSEC toggle and let Unbound handle it.
Slow initial lookups to new domains
Normal under recursion while cache warms. Confirm Unbound’s prefetch: yes is set; performance improves after a short warm‑up.
Every query appears to come from the router
Router is acting as DNS forwarder. Either set Pi‑hole as DHCP DNS so clients talk to it directly, or enable conditional forwarding in Pi‑hole so hostnames resolve, but in general you want clients to point directly at Pi‑hole.

The Pi‑hole query log is your primary debugging tool: it shows source IP, domain, action (allowed, blocked, cached, forwarded), and upstream. When users claim “site X is broken,” check the log at that time; you’ll usually see the blocked domain that needs whitelisting.