Self-Hosted DNS with Pi-hole and AdGuard Home

Self-hosted DNS gives a home lab or small office one local resolver that can cache lookups, answer private names, and apply network-wide filtering before devices reach the public internet. This guide explains how Pi-hole and AdGuard Home fit into the DNS path, how to choose between them, and how to deploy either without making the whole network dependent on one fragile server.

What Is Self-Hosted DNS?

Self-hosted DNS means operating a recursive, forwarding, or filtering DNS service under your own control instead of sending every client directly to a public resolver. A local resolver accepts queries from trusted devices, applies local policy, and then obtains permitted answers from an upstream recursive service.

Pi-hole is a DNS sinkhole and network-management interface built around a DNS service such as FTL/dnsmasq. It compares requested domains with blocklists and returns a non-routable response for domains that match. The Pi-hole documentation describes its DNS behavior, lists, configuration, and command-line tools.

AdGuard Home is a network-wide DNS server with filtering, privacy controls, encrypted upstream support, and a web interface. Its official project repository documents installation, configuration, and supported operating modes. Both products can forward allowed queries to an upstream resolver; neither replaces the authoritative DNS servers that publish public domains.

The distinction matters: the local service is normally a forwarding or recursive client, not the authoritative owner of example.com. For the underlying DNS message and resolver model, the DNS concepts in RFC 1034 provide the standards background.

Why Run DNS at Home?

Clients need DNS for almost every normal connection, but a default network often distributes a router address or an ISP resolver through DHCP. That arrangement can be adequate, yet it gives the administrator limited visibility and makes policy inconsistent across devices. A phone using cellular data, a laptop with a manually configured resolver, and a guest device may all bypass the router’s intended controls.

A self-hosted resolver can solve several practical problems:

• Consistent policy: phones, laptops, servers, and IoT devices can use the same allow and block rules when they are on the local network.
• Reduced unwanted traffic: advertising, tracking, and known malicious domains can be blocked before a connection is established.
• Local names: nas.home.arpa, printer.home.arpa, or service names can resolve without exposing them to a public DNS provider.
• Caching: repeated queries can be answered locally, reducing latency and upstream traffic.
• Troubleshooting: query logs show whether a failure is caused by a blocked domain, an NXDOMAIN response, an unreachable upstream, or an application issue.

Filtering is not a complete security boundary. DNS controls names, not arbitrary IP connections, and a determined client can use another resolver, a hard-coded address, encrypted application traffic, or a VPN. Treat DNS filtering as one policy layer alongside firewall rules, endpoint controls, updates, and authentication.

How the DNS Path Works

A common home-network path looks like this:

client application
  -> operating-system resolver
  -> router DHCP configuration
  -> local Pi-hole or AdGuard Home
  -> cache and filtering rules
  -> encrypted or plain upstream resolver
  -> authoritative DNS infrastructure
  -> response cached and returned to the client

The client must actually use the local resolver for this path to work. DHCP is usually the cleanest way to advertise its address. If the router continues advertising itself while merely forwarding to the new server, the local service may still see queries, but client identity and failover behavior can be less clear. IPv6 router advertisements can also publish DNS settings independently of IPv4 DHCP, so an IPv6-capable network must be configured and tested deliberately.

DNS normally uses UDP port 53, with TCP 53 available for larger responses or fallback. Encrypted upstream protocols such as DNS over TLS or DNS over HTTPS protect the connection between the local server and its upstream; they do not hide DNS queries from the local administrator or make blocked domains unreachable by every possible method.

Forwarding, recursion, and authoritative DNS

Pi-hole and AdGuard Home are primarily filtering resolvers. They can forward to a public provider, a local recursive resolver such as Unbound, or another controlled upstream. Running a full recursive resolver adds privacy and control, but also adds another service to monitor and troubleshoot.

Pi-hole vs AdGuard Home

Both products can provide network-wide blocking, local DNS records, query statistics, and client-based policy. The important differences are operational rather than whether one can block a particular list.

There is no universal winner. Choose Pi-hole when its group model, existing integrations, or community workflow matches the lab. Choose AdGuard Home when its unified configuration and built-in encrypted-upstream options reduce operational complexity. Do not run both as active DHCP-provided resolvers on the same network unless their roles and forwarding paths are intentionally separated; duplicate filtering makes failures harder to explain.

Key Components and Design Choices

The DNS service host

Use a device that boots reliably and has a stable address. A small Linux host, virtual machine, container host, or low-power single-board computer can work. Keep the resolver off a machine that is frequently shut down, such as a personal laptop. If the service runs in a container, publish port 53 for both UDP and TCP and make its persistent configuration part of the backup plan.

Reserve the address in DHCP or configure a static address outside the dynamic pool. Avoid changing the resolver’s address after clients are configured; a stale DHCP lease can make a healthy DNS service appear unavailable.

Upstream selection

An upstream resolver affects privacy, availability, filtering overlap, and DNSSEC behavior. A public resolver is simple to operate. A local recursive resolver provides more control but requires patching, cache management, and clear forwarding policy. Encrypted upstream transport can protect queries across an untrusted access network, but it does not provide anonymity from the upstream operator.

Use at least two upstream endpoints where practical, but understand that automatic fallback can bypass a preferred policy if one endpoint fails. If filtering must remain mandatory, keep all upstream paths inside the controlled resolver and block direct outbound DNS from client networks at the firewall.

Local names and split DNS

Local DNS records are useful for services that should remain private:

nas.home.arpa       -> 192.168.20.10
router.home.arpa    -> 192.168.10.1
git.home.arpa       -> 192.168.20.20

The home.arpa namespace is reserved for residential networks. Do not invent names below a domain that you do not control. For a company or homelab domain, split DNS can return internal addresses to internal clients while public resolvers receive public addresses. Keep private records out of public authoritative zones.

Availability and bypass control

One resolver creates a single point of failure. A second instance on another host or network segment is safer than relying on a public fallback that silently bypasses local policy. Configure DHCP with both local resolver addresses, monitor each independently, and test behavior when either one is stopped.

If policy enforcement matters, firewall clients so that only the approved resolvers can receive outbound DNS. Also account for IPv6, DNS over HTTPS applications, VPN tunnels, and devices with hard-coded resolver behavior. Blocking every bypass can break legitimate software, so document exceptions and test them rather than applying a broad rule blindly.

Practical Setup

The following workflow applies to either product. Use the vendor’s installer for the current release rather than copying an old package URL.

1. Prepare a stable Linux host

sudo apt update
sudo apt full-upgrade
hostnamectl
ip address
ip route

Assign a DHCP reservation such as 192.168.20.53 to the host. Confirm that no other service owns port 53:

sudo ss -lntup | grep ':53'

Stop or reconfigure a conflicting local stub only after identifying which service manages it. A successful install that cannot bind both UDP and TCP port 53 is not a working resolver.

2. Install and configure one resolver

For Pi-hole, follow the documented installation path and select the stable interface and upstream settings during setup. For AdGuard Home, download the release for the host architecture using the project’s installation instructions, then complete its web setup.

In either interface:

1. Set the listening address to the intended LAN interfaces, not an exposed public interface.
2. Choose upstream resolvers and enable encrypted transport if it fits the threat model.
3. Start with a conservative blocklist set; add lists only when their maintenance and false positives are understood.
4. Add local records and client groups after basic resolution works.
5. Protect the administration interface with a strong password and restrict its network access.

3. Advertise the resolver through DHCP

Set the local resolver address as the DNS server in the router or DHCP service. Renew a client lease and inspect the result:

sudo dhclient -r && sudo dhclient
resolvectl status
cat /etc/resolv.conf

On Windows, use:

ipconfig /release
ipconfig /renew
ipconfig /all

The displayed DNS server should be the self-hosted address. Test both an allowed and a deliberately blocked domain:

dig example.com
dig @192.168.20.53 example.com
dig nas.home.arpa

For a local record, the answer should contain the intended private address. A blocked name should return the response selected by the configured blocking mode. Query logs should show the client and decision.

4. Back up and monitor the service

Back up the resolver’s configuration, custom rules, local records, certificates, and any client-group definitions. A backup of the container image alone is not enough. Restore the configuration on a second host at least once so the procedure is known to work.

Monitor DNS availability from a client network, not only from the resolver host. Alert on process health, port 53 reachability, upstream failures, disk usage, and configuration changes. If query logs contain sensitive hostnames, restrict access and define a retention period.

Common Misconceptions

“DNS blocking is antivirus”

It is not. A blocked hostname may prevent one connection, but malware can use an IP address, a new domain, a VPN, or an application-specific resolver. DNS filtering reduces exposure and improves visibility; endpoint protection and patching remain necessary.

“A second public DNS server is always safe failover”

It improves availability only if bypassing local policy is acceptable. A client that fails over directly to a public resolver may resolve domains that the local policy would block. Prefer two controlled local instances when enforcement is a requirement.

“Local DNS makes services secure”

An internal name is not an authorization mechanism. Anyone who can reach the service may still attempt to connect, and a compromised client may query or bypass the resolver. Use firewall policy, service authentication, TLS, and network segmentation as separate controls. Home lab network segmentation is a useful companion design.

Related Articles

• DNS Configuration on Linux: Resolvers, BIND, DNSSEC, and Troubleshooting
• The DNS Lookup Process Step by Step
• Fastest Public DNS Servers: How Resolver Choices Affect Performance
• Home Lab Network Segmentation with VLANs Explained

For a self-hosted resolver, the durable design is more important than the brand: give the service a stable address, advertise it consistently, secure its management plane, test failures, and maintain a second controlled instance when DNS availability is critical.