Belajar DNS - Production-Ready Stack & Deployment

#Pendahuluan

Semua kemampuan dari episode 0 sampai 20 sekarang dirangkai menjadi satu: stack DNS production-grade. Episode 21 menyusun arsitektur lengkap, lalu memindahkannya ke container dengan Docker dan Kubernetes, mengelola sertifikat TLS, dan menetapkan strategi upgrade yang aman.

Ini episode yang paling dekat dengan pekerjaan sehari-hari: bukan lagi mempelajari fitur, melainkan mengambil keputusan arsitektur dan operasional yang akan menentukan keandalan layanan DNS kalian.

#Arsitektur Production Lengkap

#Merakit Semua Peran

Arsitektur referensi memakai semua komponen yang sudah dipelajari:

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

dnsdist menjadi satu-satunya pintu masuk publik: dia yang memegang sertifikat TLS, rate limiting, dan packet cache. Recursor menangani resolusi dan validasi. Authoritative mengelola zone yang dimiliki, dengan primary-secondary dan DNSSEC signing, semua di atas database backend.

#Prinsip yang Menopang Arsitektur

Tiga prinsip menjaga arsitektur ini tetap sehat:

• Tidak ada single point of failure: setiap peran minimal dua instance (episode 18).
• Validasi dan enkripsi di semua jalur: DNSSEC (episode 13-14) dan DoT/DoH/DoQ (episode 15).
• Otomasi penuh: API dan IaC (episode 20) untuk setiap perubahan.

#Deployment dengan Docker

#Docker Compose Reference

Untuk deployment di satu host atau studi arsitektur, docker-compose.yml merakit semua peran:

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 adalah contoh konvensi env var PowerDNS: setiap opsi pdns.conf bisa dikonversi menjadi variabel lingkungan berawalan PDNS_. Ini membuat konfigurasi mudah dipetakan antar lingkungan.

#Container vs Sistem Native

Container menyederhanakan deployment dan reproduksibilitas, tetapi kalian tetap bertanggung jawab atas volume data database, jaringan antar container, dan backup. Untuk beban sangat tinggi, Authoritative dengan lmdb sering berkinerja lebih baik sebagai native service di host khusus.

#Kubernetes Deployment

#Deployment dan Service

Di Kubernetes, setiap daemon menjadi Deployment, dan dnsdist terekspos lewat Service LoadBalancer:

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 memberi dua pod dnsdist yang dijadwalkan di node berbeda. Service LoadBalancer menyediakan alamat publik tunggal untuk klien. Kubernetes menangani health check dan restart otomatis — beban operasional DNS berkurang drastis.

#Sertifikat TLS dan Upgrade

#Manajemen Sertifikat dengan ACME

Endpoint DoT/DoH/DoQ membutuhkan sertifikat valid. Otomatiskan dengan ACME (Let's Encrypt) dan auto-renewal:

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

Sertifikat yang diperbarui otomatis harus di-roll ke dnsdist. Di Kubernetes, gunakan cert-manager dengan ingress DNS-01; di bare metal, sertakan reload service dalam cron renewal.

#Kebijakan Upgrade dan EOL

PowerDNS menerbitkan jadwal EOL (end of life) per major version. Strategi upgrade yang aman:

• Selalu baca catatan rilis dan verifikasi versi terkini di downloads.powerdns.com.
• Upgrade satu peran pada satu waktu: dnsdist dulu, lalu recursor, lalu authoritative.
• Uji di staging dengan konfigurasi production sebelum rilis.
• Pastikan versi semua peran masih dalam masa dukungan.

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

#Runbook Incident

#Tiga Skenario Paling Umum

Siapkan runbook sederhana untuk skenario yang paling sering terjadi:

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)

Runbook menjadikan pemulihan konsisten dan cepat, terutama saat on-call. Latih skenario ini secara berkala agar langkahnya hafal tanpa berpikir.

#Penutup

Episode 21 merakit seluruh series menjadi satu jawaban produksi: arsitektur lengkap klien-dnsdist-recursor-authoritative di atas database backend, deployment Docker dan Kubernetes, manajemen sertifikat ACME, upgrade yang mengikuti kebijakan EOL, dan runbook untuk pemulihan cepat.

Inti yang harus dibawa pulang:

• dnsdist adalah satu-satunya pintu publik: TLS, rate limit, dan cache ada di sana.
• Recursor menangani resolusi dan validasi DNSSEC; Authoritative mengelola zone via database.
• Docker memakai konvensi env var PDNS_* untuk mengkonversi opsi pdns.conf.
• Kubernetes Deployment dengan replicas: 2 dan Service LoadBalancer membuat DNS tahan gagal.
• Sertifikat dikelola otomatis dengan ACME; upgrade mengikuti jadwal EOL PowerDNS.
• Runbook incident membuat pemulihan cepat dan konsisten.

Di episode 22 selanjutnya kita akan membahas ekosistem alternatif dan refleksi akhir — perbandingan BIND 9, Unbound, CoreDNS, Knot DNS, Technitium, dan managed DNS seperti Route 53 dan Cloudflare terhadap stack PowerDNS, rekap perjalanan, checklist production-grade, dan masa depan DNS dengan DoH3, DDR, dan DNS sebagai lapisan keamanan.