PROPER INSTRUCTIONS

Build a Pi-hole alternative on an old computer: proper instructions

A network DNS filter reduces advertising, tracking and known unwanted-domain lookups for devices that use it. It cannot inspect encrypted web pages, block every advert, or make unsafe software safe. This guide uses AdGuard Home as a Pi-hole alternative on patched Debian. The safe design is simple: fixed wired LAN address, private dashboard, one-client trial, router rollout, and a documented fallback.

Know what DNS filtering does

DNS translates names into addresses. A filter can block selected names before a connection begins. It is not a firewall. Apps using encrypted DNS, hard-coded resolvers, a VPN, mobile data, or separately advertised IPv6 DNS may bypass it. Smart TVs, games and banking sites can also break when a required hostname is blocked. Inspect logs and allow the exact necessary domain; do not turn filtering off for the entire house.

Plan and prepare

Use a wired always-on computer with at least 2 GB RAM, 16 GB storage and Debian stable. Reserve its Ethernet address in the router.
Record the router’s current DHCP DNS settings before changing anything and retain a local router-admin path.
Choose two upstream resolvers. Initially these may be the router’s normal upstream DNS or reputable public resolvers. Never set the filter’s own LAN address as its upstream resolver: that forms a loop.
Decide how IPv6 clients will receive the filter address. If router advertisements provide another IPv6 DNS server, capable clients may bypass the filter.
Keep a monitor and keyboard available during router changes.

Update Debian and install download prerequisites:

sudo apt update
sudo apt full-upgrade
sudo apt install curl ca-certificates
sudo reboot

Check whether port 53 is already occupied:
```
sudo ss -ltnup '( sport = :53 )'
```
. Identify an owning service before changing it; do not stop processes blindly.
Download the current AdGuard Home Linux release for the actual CPU architecture from its official documentation. Verify the published checksum or signature where available. Extract it and use its supplied service installer:
```
sudo ./AdGuardHome -s install
sudo systemctl status AdGuardHome
```
. Archive names change by release, so do not use a stale blog URL.
Open the initial setup page from a LAN client at the address and port shown by the installer. Bind DNS to the server’s LAN address, and bind administration to the LAN address where offered. Create a unique administrator password.
Enter the two planned upstream resolvers. Leave optional encrypted upstream DNS for after ordinary resolution works. Add no extra community lists at first; add one maintained list at a time only after testing.

Roll out safely

Set one non-critical client’s DNS manually to the filter IP. Browse normal sites and test an application the user needs. Confirm its queries appear in the filter’s log and that a known listed advertising hostname is blocked without visiting a risky website.
Only when that works, change the router DHCP DNS option to the filter address. Keep router DHCP enabled; this design does not require AdGuard Home to run DHCP. Renew the client lease or reconnect it, then inspect the client’s actual DNS setting.
Check a phone and a different device type. Explicitly check IPv6-capable clients rather than assuming they follow IPv4 DHCP.

Confirm the service and listener:

sudo systemctl is-active AdGuardHome
sudo ss -ltnup '( sport = :53 )'

. Query it directly from a client:

nslookup example.com SERVER_IP

Security, resilience and rollback

DNS logs are browsing metadata. Restrict the dashboard to the LAN, use a unique password, choose sensible log retention and never forward port 53 or the administration port from the internet. An open recursive resolver can be abused, and an exposed dashboard invites account compromise. Patch both Debian and AdGuard Home. Back up configuration before upgrades, but protect that backup because it can include client information and credentials.

For resilience, a second independently powered DNS filter can be advertised through DHCP; two devices on the same power strip are not meaningful redundancy. If household DNS fails, restore the router’s previous DHCP DNS values first and renew a client lease. For one broken service, remove its manual override or add only the exact logged domain needed. Before uninstalling AdGuard Home, restore router DNS, stop the service according to its release documentation, preserve a configuration backup, and confirm no process remains on port 53.

Ongoing review and troubleshooting

Review query logs briefly after a major block-list change, an operating-system update or reports that a site has stopped working. Look for repeated blocked names immediately before the failed action, then confirm the domain’s purpose from the service’s own documentation where possible. An allow-list entry should be as narrow as possible and have a note explaining it. Avoid allowing broad parent domains, disabling all filtering for a device, or importing many anonymous lists merely to improve a blocked-query count.

If clients intermittently lose resolution while the server itself is healthy, compare the DNS server actually shown on each client with the DHCP configuration. Check for a second router, mesh node or VPN supplying alternate DNS. Verify that the host has stable Ethernet and that no other local resolver has taken port 53. DNS filtering improves control only for requests that arrive at it; this limitation is expected and should be documented rather than treated as a mystery failure.

Privacy choices

Choose log retention and statistics deliberately. Shorter retention reduces household browsing metadata stored on the server; longer retention makes false-positive diagnosis easier. Give administrators a clear explanation of what is logged and who can view it. Do not use this system as a covert activity-monitoring tool. If children or guests use the network, agree the policy openly and use device controls appropriate to the household rather than relying on a DNS filter as a complete safeguard.