Learning DNS - Production-Ready Stack & Deployment

#Introduction

Every capability from episodes 0 to 20 now comes together into one: a production-grade DNS stack. Episode 21 lays out the complete architecture, moves it into containers with Docker and Kubernetes, manages TLS certificates, and sets a safe upgrade strategy.

This is the episode closest to day-to-day work: no longer learning features, but making architectural and operational decisions that will determine your DNS service's reliability.

#The Complete Production Architecture

#Assembling Every Role

The reference architecture uses all the components you've learned:

klien (DoT/DoH/DoQ)
   -> dnsdist (rate limit + cache + TLS)
        -> recursor x2 (DNSSEC validation)
             -> internet
        -> authoritative pool (primary + secondary)
             -> database backend (gmysql/lmdb)

dnsdist is the single public entry point: it holds the TLS certificates, rate limiting, and packet cache. The Recursor handles resolution and validation. The Authoritative manages owned zones, with primary-secondary and DNSSEC signing, all on a database backend.

#Principles Supporting the Architecture

Three principles keep this architecture healthy:

• No single point of failure: every role runs at least two instances (episode 18).
• Validation and encryption on every path: DNSSEC (episodes 13-14) and DoT/DoH/DoQ (episode 15).
• Full automation: API and IaC (episode 20) for every change.

#Deployment with Docker

#Docker Compose Reference

For single-host deployment or architecture study, docker-compose.yml assembles every role:

services:
  dnsdist:
    image: powerdns/dnsdist:2.1
    ports:
      - "53:53"
      - "443:443"
    volumes:
      - ./dnsdist.yml:/etc/dnsdist/dnsdist.yml
  recursor:
    image: powerdns/pdns-recursor:5.4
    expose:
      - "53"
  auth:
    image: powerdns/pdns-auth-mysql:5.1
    environment:
      - PDNS_launch=gmysql
      - PDNS_gmysql_host=db

PDNS_launch=gmysql is an example of the PowerDNS env var convention: every pdns.conf option can be converted to an environment variable with the PDNS_ prefix. This makes configuration easy to map between environments.

#Container vs Native Systems

Containers simplify deployment and reproducibility, but you're still responsible for database data volumes, inter-container networking, and backups. For very high load, Authoritative with lmdb often performs better as a native service on a dedicated host.

#Kubernetes Deployment

#Deployments and Services

In Kubernetes, each daemon becomes a Deployment, and dnsdist is exposed through a LoadBalancer Service:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dnsdist
spec:
  replicas: 2
  selector:
    matchLabels:
      app: dnsdist
  template:
    metadata:
      labels:
        app: dnsdist
    spec:
      containers:
        - name: dnsdist
          image: powerdns/dnsdist:2.1
          ports:
            - containerPort: 53
              protocol: UDP
---
apiVersion: v1
kind: Service
metadata:
  name: dnsdist
spec:
  type: LoadBalancer
  selector:
    app: dnsdist
  ports:
    - port: 53
      targetPort: 53
      protocol: UDP

replicas: 2 gives you two dnsdist pods scheduled on different nodes. The LoadBalancer Service provides a single public address for clients. Kubernetes handles health checks and automatic restarts — the operational burden of DNS drops dramatically.

#TLS Certificates and Upgrades

#Certificate Management with ACME

DoT/DoH/DoQ endpoints need valid certificates. Automate this with ACME (Let's Encrypt) and auto-renewal:

sudo certbot certonly --standalone -d dns.example.com

Automatically renewed certificates must be rolled into dnsdist. In Kubernetes, use cert-manager with DNS-01 ingress; on bare metal, include a service reload in the renewal cron.

#Upgrade and EOL Policy

PowerDNS publishes an EOL (end of life) schedule per major version. A safe upgrade strategy:

• Always read release notes and verify the latest versions at downloads.powerdns.com.
• Upgrade one role at a time: dnsdist first, then recursor, then authoritative.
• Test in staging with production configuration before release.
• Make sure all role versions are still within support.

pdns_server --version && pdns_recursor --version && dnsdist --version

#Incident Runbook

#The Three Most Common Scenarios

Prepare a simple runbook for the most frequent scenarios:

1. Semua nama gagal resolusi
   -> periksa dnsdist, lalu recursor, lalu koneksi internet
2. Satu zone tidak sinkron
   -> bandingkan SOA, cek allow-axfr-ips dan also-notify
3. SERVFAIL untuk zone DNSSEC
   -> periksa signature zone dan trust anchor (episode 14)

A runbook makes recovery consistent and fast, especially while on-call. Practice these scenarios regularly so the steps become second nature.

#Conclusion

Episode 21 assembles the entire series into one production answer: a complete client-dnsdist-recursor-authoritative architecture on a database backend, Docker and Kubernetes deployment, ACME certificate management, upgrades following EOL policy, and a runbook for fast recovery.

Key takeaways:

• dnsdist is the only public entry: TLS, rate limits, and caching live there.
• The Recursor handles resolution and DNSSEC validation; the Authoritative manages zones via database.
• Docker uses the PDNS_* env var convention to convert pdns.conf options.
• Kubernetes Deployments with replicas: 2 and LoadBalancer Services make DNS failure-resistant.
• Certificates are managed automatically with ACME; upgrades follow PowerDNS EOL schedules.
• An incident runbook makes recovery fast and consistent.

In episode 22, we'll cover the alternative ecosystem and final reflection — comparing BIND 9, Unbound, CoreDNS, Knot DNS, Technitium, and managed DNS like Route 53 and Cloudflare against the PowerDNS stack, recapping the journey, a production-grade checklist, and the future of DNS with DoH3, DDR, and DNS as a security layer.