Building a Privacy-Aware Outbound DNS Architecture

DNS is often treated as a simple plumbing layer. Most folks just use whatever DNS provider they get with their ISP.

ISP DNS isn’t bad, its perfectly fine if you are happy with the ISP knowing every website / query you make and that some queiries may be blocked by the ISPs resolvers due to pressures to restrict the internet.

This article isn’t about breaking the law. It is about privacy, and what I am doing to ensure that my privacy, in an online world is balanced. I may not always get it right.

Done properly, DNS becomes far more than name just domain resolution. It becomes:

• A policy engine.
• A privacy boundary.
• A routing signal source.
• A security control layer.

My goal is to have reasonable DNS security and I’m using the following services to get to a goodish DNS position.

• AdGuard Home for “fail fast” and to control IPv6 behaviour for Unifi policy-based routing.
• UniFi DNS visibility for policy-based routing.
• ControlD for upstream security and filtering.

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

High-Level Architecture

#

flowchart BT
    Client["Client Devices"] --> AdGuard["AdGuard Home"]
    AdGuard --> UniFi["UniFi Gateway DNS Visibility"]
    UniFi --> ControlD["ControlD (DoH)"]
    ControlD --> Internet["Internet"]

Each layer has a defined responsibility and purpose.

Layer 1. AdGuard Home, IPv6 Control and Client Enforcement

#

The Problem

#

Blocking needs to happen fast. Why? Clients waiting for responses to DNS quiries is wasted time. If DNS is going to be blocked, I want it to be block quickly. That means closest to the client, inside my network.

Secondly, UniFi policy-based routing is reliably enforced on IPv4. It does not work on IPv6. I run dual IPv4 and IPv6 networks.

If clients receive IPv6 AAAA records, they may:

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

I don’t want any of that to happen, if I can prevent it (that’s an important bit).

The Solution

#

AdGuard Home sits closest to clients and:

• Filters AAAA records (IPv6 Records) that matches Unifi Policy Based Routing.
• Enforces Safe Search policies; so my family is protected.
• Blocks annoyances (adverts!)

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.

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

#

Purpose

#

Mentioned before, I have two WAN interfaces (EE and Starlink), and a couple of VPNs. Essentially that gives me four outbound ports I can send traffic out of.

Primary is EE, Starlink as a backup.

Running over that, I have two VPNs. Using policy based routing, I can purposefully send traffic to buildbreakunderstand.com via VPN1. For traffic to codeberg.org I can send the traffic via VPN2. For this to work, Unifi needs to know what IP address either domain belongs to.

UniFi does not need to be the filtering authority. It just needs visibility of queries. This layer ensures:

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

Unifi also provides DOH capability; so that communication to the next hop (ControlD) are encrypted.

Layer 3. ControlD, Outbound Security and Privacy Layer

#

Purpose

#

ControlD is my outbound resolver for the entire network. Its role:

• Block malicious domains such as phishing and malware.
• Filter tracking and ads.
• Enforce adult content restrictions.
• Block newly registered domains.
• Provide encrypted DNS-over-HTTPS.

Why ControlD

#

ControlD acts as the external security boundary.

• 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.

Why Layer Instead of Consolidate

#

Many setups collapse DNS into a single resolver. That works; but layering provides:

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

Each system has a defined job.

Privacy Properties of This Design

#

• ISP cannot see plaintext DNS queries.
• The external resolver cannot fingerprint internal devices.
• Clients IPv6 leakage reduced.
• Malicious domains are blocked upstream.