↓ Skip to main content

Building a Privacy-Aware Outbound DNS Architecture

·763 words·4 mins
Rich
Author
Rich
Table of Contents

Building a Privacy-Aware Outbound DNS Architecture
#

DNS is often treated as a simple plumbing layer. Point clients at a resolver, block a few ads, and move on.

In a security-focused home / lab environemtn, DNS becomes far more than name resolution. It becomes:

  • A policy engine.
  • A privacy boundary.
  • A routing signal source.
  • A security control layer.
  • An IPv6 containment mechanism.

I want to protect myself, and family from dangers on the internet. This post walks through how I built a privacy-aware outbound DNS architecture using:

  • ControlD for upstream security and filtering.
  • UniFi DNS visibility for policy-based routing.
  • AdGuard Home to control IPv6 behaviour and enforce Safe Search.

The goal is not just blocking ads or annoyances. It is building layered DNS roles with clear responsibility boundaries and functions.

High-Level Architecture
# 

[ Client Devices ]
        |
        v
[ AdGuard Home ]
        |
        v
[ UniFi Gateway DNS Visibility ]
        |
        v
[ ControlD (DoH) ]
        |
        v
[ Internet ]

Each layer has a defined responsibility and purpose.

Layer 1. ControlD, Outbound Security and Privacy Layer
#

Purpose
#

ControlD is the authoritative outbound resolver for the entire network.

Its role:

  • Block malicious domains (This is top priority).
  • Filter tracking and ads.
  • Enforce adult content restrictions.
  • Block newly registered domains.
  • Prevent phishing and malware resolution.
  • Provide encrypted DNS-over-HTTPS.

Configuration Overview
#

  • AI Malware Filter: Aggressive.
  • Block TTL: 30 seconds.
  • Redirect TTL: 30 seconds.
  • Bypass TTL: 60 seconds.
  • Compatibility Mode: Enabled with IPv6 support.
  • Connection Method: DNS-over-HTTPS.

Why ControlD
#

ControlD acts as the external security boundary.

It ensures:

  • Privacy from ISP DNS, with encrypted transport using DoH.
  • Centralised filtering logic.
  • Uniform outbound DNS policy.

ControlD only sees the UniFi gateway as the querying client, not individual devices. This reduces external fingerprinting and protects internal device visibility.

Layer 2. UniFi DNS Visibility, Policy-Based Routing Engine
#

Purpose
#

UniFi DNS is not the primary filtering layer.

It exists for policy-based routing.

For example:

  • Send bing.com search traffic via WAN2.
  • Route certain SaaS applications via VPN.
  • Direct specific domains down specific egress paths.

UniFi can only create routing policies if it sees DNS queries and their answers.

If clients bypass UniFi for DNS, policy-based routing breaks.

Design Insight
#

UniFi does not need to be the filtering authority. It needs visibility.

This layer ensures:

  • DNS queries are visible to the gateway.
  • Routing decisions can be domain-aware.
  • Traffic engineering works predictably.

This is DNS as a routing signal, not just name resolution.

Layer 3. AdGuard Home, IPv6 Control and Client Enforcement
#

The Problem
#

UniFi policy-based routing is reliably enforced on IPv4.

If clients receive IPv6 AAAA records, they may:

  • Bypass IPv4 routing rules.
  • Exit via unintended WAN interfaces.
  • Avoid policy enforcement.

The Solution
#

AdGuard Home sits closest to clients and:

  • Filters AAAA records.
  • Prevents IPv6 bypass scenarios.
  • Enforces Safe Search policies.
  • Adds browsing security and parental controls.

Enabled Features
#

  • AdGuard browsing security web service.
  • AdGuard parental control web service.
  • Safe Search enabled for:
    • Bing.
    • DuckDuckGo.
    • Ecosia.
    • Google.
    • Pixabay.
    • Yandex.
  • Safe Search disabled for YouTube.

AdGuard ensures IPv6 does not undermine the IPv4 routing strategy.

Why Layer Instead of Consolidate
#

Many setups collapse DNS into a single resolver.

That works. Layering provides:

  1. Clear separation of concerns.
  2. Easier troubleshooting.
  3. Explicit trust boundaries.
  4. More predictable routing behaviour.
  5. Reduced information leakage.

Each system has a defined job.

Layer Responsibility

AdGuard Client control and IPv6 containment UniFi Routing visibility and policy-based routing ControlD External filtering and encrypted upstream

Privacy Properties of This Design
#

  • ISP cannot see plaintext DNS queries.
  • The external resolver cannot fingerprint internal devices.
  • Clients cannot bypass routing via IPv6.
  • Malicious domains are blocked upstream.
  • Newly registered domains are filtered aggressively.

This is DNS used intentionally as a security primitive.

Operational Lessons Learned
#

  • Keep TTL values low when testing routing behaviour.
  • Always validate AAAA suppression if enforcing IPv4 routing.
  • Confirm UniFi sees DNS answers before debugging policy-based routing.
  • Test Safe Search enforcement per search engine.

DNS misconfiguration often looks like routing issues. In reality, it is frequently resolver behaviour.

Future Improvements
#

  • DNS logging pipeline into a SIEM.
  • Split-horizon DNS for lab zones.
  • DNSSEC validation testing.
  • Conditional forwarding for internal domains.
  • Automated configuration backups.

Conclusion
#

DNS is no longer just name resolution.

In a homelab built with security in mind, it becomes:

  • A privacy boundary.
  • A routing intelligence feed.
  • An enforcement layer.
  • A threat mitigation control.

By layering AdGuard Home, UniFi, and ControlD, I built a DNS architecture that is:

  • Privacy-aware.
  • Routing-aware.
  • IPv6-conscious.
  • Security-focused.
  • Predictable.

If you are building a security-first homelab, start treating DNS as architecture, not plumbing.

Related