Reference architecture

Separate responsibilities, trust boundaries and failure domains

A maintainable DNS platform gives each component a clear role. The diagram below is a generic model—not a prescription—and uses no real network identifiers.

Generic modern DNS architecture with clients, dnsdist, filtering, Unbound, NSD, offline signer and secondary authoritative server

Component roles

A layered design

Edge

DNS proxy or load balancer

A component such as dnsdist can expose UDP/TCP DNS and encrypted listeners, enforce client ACLs, distribute queries and collect protocol-level metrics.

Keep recursion closed to authorised clients.
Rate-limit abuse without blocking legitimate retries.
Terminate TLS only where certificate lifecycle is controlled.

Policy

Filtering layer

A policy engine or filtering service can block selected names and provide local overrides. Keep policy answers distinguishable from genuine authority failures.

Document block response modes.
Avoid silently breaking DNSSEC semantics.
Provide an auditable bypass for diagnostics.

Resolution

Validating recursive resolver

Unbound, BIND, Knot Resolver or another full resolver follows referrals, caches answers, minimises QNAMEs and validates DNSSEC.

Enable both UDP and TCP upstream.
Use sensible EDNS sizes and fallback behaviour.
Maintain the root trust anchor automatically and observably.

Authority

Authoritative-only servers

NSD, Knot Authoritative, BIND, PowerDNS Authoritative or equivalent servers publish zones without offering recursion.

Use at least two independently reachable servers.
Serve identical zone content and signatures.
Restrict transfer access.

Signing

DNSSEC signer

Signing may be inline, hidden-primary based or offline. The private-key boundary should match the organisation’s threat model and recovery capability.

Automate signature refresh.
Alert well before expiry.
Keep a tested DS rollover procedure.

Replication

Secondary authority

Secondaries receive complete AXFR or incremental IXFR updates. TSIG authenticates transfers; TLS can additionally provide confidentiality.

Notify secondaries after publication.
Monitor SOA serial convergence.
Test failure of the hidden primary.

The separation rule

Recursive and authoritative service should not be one public open interface

An authoritative server answers for configured zones; a recursive resolver performs work for clients. Combining both is possible in some software, but exposing recursion publicly creates amplification and abuse risk and blurs operational diagnosis.

Separate listeners, access controls or hosts make it clearer which component owns an answer, which logs to inspect and which failure domain is affected.

Local zones and split DNS

Private names need an explicit validation design

Internal zones can be served from a local authoritative source and exposed to a validating resolver through a stub zone, forward zone or local authority mechanism. The design must define whether the private namespace is signed, deliberately insecure or anchored with a private trust key.

Returning private answers for a public name creates split-horizon DNS. That can be legitimate, but it complicates certificate issuance, DNSSEC, troubleshooting and behaviour outside the managed network.

Questions to settle

Which resolver is authoritative for local names?
What happens when the local authority is unavailable?
How is negative caching handled?
Do VPN clients receive the same view?
Can applications bypass the intended resolver with built-in DoH?
How are private trust anchors distributed and rotated?

Generic configuration sketches

Illustrative boundaries—not copy-and-paste production files

Validating recursive core (Unbound-style)

server:
  interface: 127.0.0.1@5335
  access-control: 127.0.0.0/8 allow
  qname-minimisation: yes
  aggressive-nsec: yes
  harden-dnssec-stripped: yes
  hide-identity: yes
  hide-version: yes
  prefetch: yes
  edns-buffer-size: 1232

Authoritative-only zone (NSD-style)

server:
  ip-address: 192.0.2.53
  hide-version: yes
  minimal-responses: yes

zone:
  name: example.com
  zonefile: example.com.zone
  provide-xfr: 198.51.100.53 transfer-key
  notify: 198.51.100.53 transfer-key

Edge proxy concept (dnsdist-style)

setLocal("0.0.0.0:53")
setACL({"192.0.2.0/24", "2001:db8::/32"})
newServer({address="127.0.0.1:5335", name="validator"})

-- Add encrypted listeners, rate limits and metrics
-- according to the local threat and availability model.

Design principles

Prefer explicit contracts between layers

Least privilege

Only authorised clients receive recursion; only approved peers receive zone transfers.

Independent failure

Loss of a filtering UI should not silently remove all DNS resolution.

Observable state

Monitor serials, validation, cache health, transport errors and certificate expiry.

Safe defaults

No open recursion, no unrestricted AXFR, no secrets in public configuration repositories.

Protocol correctness

Support TCP, avoid oversized fragmented UDP and preserve DNSSEC data end to end.

Recoverability

Back up zone sources, signing metadata, trust-anchor state and deployment procedures.