dns

DNS Architecture in a Homelab: Pi-hole and Unbound

Designing a local DNS architecture using Pi-hole and Unbound for filtering, recursive resolution, and reliable service discovery.

Waqas Mohammad

— 1 min read

This post focuses on the DNS layer of my homelab, built using Pi-hole and Unbound.

DNS turned out to be one of the most important components in the entire setup. It affects service discovery, connectivity, debugging, and overall reliability.

Rather than relying on external DNS providers, I chose to run a fully local DNS stack with recursive resolution.

DNS Architecture Overview

The DNS flow is structured as follows:

  • Client devices → Pi-hole
  • Pi-hole → Unbound
  • Unbound → root DNS servers

Pi-hole handles filtering and local overrides, while Unbound performs recursive resolution without forwarding queries to upstream providers.

Why Pi-hole with Unbound

I chose this combination for control and visibility.

Pi-hole provides:

  • DNS filtering
  • Local DNS records
  • Query visibility

Unbound provides:

  • Recursive DNS resolution
  • No dependency on upstream DNS providers
  • Improved privacy and control

This removes reliance on services like Google DNS or Cloudflare DNS.

Controlling DNS internally turned out to be one of the most valuable decisions, particularly when debugging connectivity and service routing issues.

Local DNS and Service Discovery

Local DNS records are used to map internal services to human-readable domains.

Examples:

  • pihole.local → Pi-hole
  • nas.local → OpenMediaVault
  • proxmox.local → hypervisor

This avoids using IP addresses directly and simplifies access to services.

Design Decisions

A few decisions made a significant difference:

  • Static IP assignment for DNS services
  • Avoiding DHCP dependency for core infrastructure
  • Keeping DNS resolution entirely internal where possible

These choices improved predictability and made troubleshooting far easier.

DNS issues often present as application failures, making a reliable DNS layer critical for accurate troubleshooting.

Issues Encountered

One issue encountered was DNS resolution from Docker containers.

Containers do not always inherit host DNS settings as expected, which required explicit configuration.

This highlighted the importance of understanding how Docker handles networking and DNS internally.

Key Learnings

  • DNS is a foundational service, not a secondary concern
  • Local resolution improves both reliability and control
  • Container networking adds complexity that must be understood
  • Observability of DNS queries is extremely valuable

What’s Next

The next component to explore is the reverse proxy layer, which handles routing and SSL for internal and external services.

Read more