DNS visibility starts on the LAN

Start with the questions leaving the network

DNS is one of the clearest ways to understand what is happening on a home network. Almost every device resolves a name before it reaches a website, cloud service, update server or telemetry endpoint. When every client uses a different external resolver, that behavior remains fragmented and difficult to explain.

My first objective is therefore simple: give LAN clients one local DNS entry point with Pi-hole. Centralizing resolution creates visibility before adding more advanced controls. It shows which clients are active, which domains they request, what is being blocked and where resolution fails.

A useful default before fine tuning

The starting point is a standard Pi-hole installation with its default filtering enabled. This provides an immediate baseline without turning the first deployment into a large policy project.

The initial operating loop is deliberately small:

1. Let the router or DHCP service advertise Pi-hole as the DNS server for LAN clients.
2. Confirm that clients actually use it and appear individually in the query log.
3. Use the default blocklists to remove common advertising and tracking domains.
4. Review allowed, blocked and failed queries before adding exceptions or extra lists.
5. Treat allowlisting as an explicit decision when a legitimate service is affected.

The query log is more valuable than a simple blocked-query counter. It helps reveal devices that communicate more often than expected, dependencies hidden inside smart devices, repeated failures and clients that bypass the intended resolver.

Visibility creates the baseline

Pi-hole gives the LAN a shared observation point for questions such as:

This baseline makes later filtering decisions more deliberate. A blocklist can reduce unwanted traffic, but the real value is being able to explain the effect and correct false positives without guesswork.

Encrypt the upstream path

Traditional DNS sends upstream queries in clear text. That now feels inconsistent with the expectation that normal web traffic uses HTTPS. Encrypted DNS should become the standard for the same reason: queries leaving the trusted network deserve confidentiality and integrity in transit.

In my target path, LAN clients continue to use Pi-hole as their local resolver. Pi-hole forwards permitted requests to Unbound, which uses DNS-over-TLS for external resolution. This keeps local filtering and visibility in Pi-hole while encrypting the connection from the controlled resolver to its upstream destination.

LAN client → Pi-hole → Unbound → encrypted upstream DNS

This boundary should be described accurately. The local client-to-Pi-hole connection still uses ordinary DNS on the LAN; encryption protects the upstream part of the route. The design can evolve further, but it already removes clear-text DNS from the internet-facing path.

Keep the path deliberate

Once encrypted upstream resolution works, plain internet-bound DNS should no longer be the unnoticed fallback. Resolver configuration and network controls should agree on the intended path, while monitoring should make upstream failures visible.

The result is a modest but meaningful control: LAN devices gain a consistent resolver, basic filtering starts from a known baseline, and external DNS requests follow an encrypted route. More advanced lists and policies can follow after the normal traffic pattern is understood.

Implementation reference

This lab note is based on the DNS design in my homelab repository. It focuses on the LAN use case and the path from initial Pi-hole visibility to encrypted upstream resolution.