DNS Challenge #

Tantangan DNS-01 (DNS-01 Challenge) adalah salah satu metode verifikasi kepemilikan domain paling andal yang didefinisikan dalam protokol ACME. Berbeda dengan tantangan HTTP-01 atau TLS-ALPN-01 yang membuktikan kendali domain melalui koneksi jaringan langsung ke server web pada port 80 atau 443, DNS challenge bekerja sepenuhnya pada lapisan infrastruktur nama domain (Domain Name System). Dengan menyajikan token verifikasi kriptografis berupa catatan teks (TXT record) di zona DNS domain kita, kita dapat membuktikan kepemilikan domain ke Certificate Authority (CA) tanpa perlu membuka port masuk apa pun dari internet luar.

Keunggulan arsitektural ini menjadikan DNS-01 sebagai metode favorit untuk berbagai skenario penyebaran (deployment) tingkat lanjut. Ini adalah satu-satunya metode yang disetujui CA untuk menerbitkan sertifikat wildcard (*.example.com). Selain itu, DNS challenge merupakan solusi mutlak bagi server web yang berjalan di dalam jaringan privat (seperti intranet perusahaan, klaster Kubernetes internal, atau server pengembangan di belakang NAT ketat) untuk tetap mendapatkan sertifikat SSL/TLS publik tepercaya secara otomatis.

Cara Kerja DNS-01 Challenge secara Detail #

Meskipun seluruh proses verifikasi berjalan secara otomatis di latar belakang oleh Caddy, memahami lini masa jabat tangan protokol ini sangat membantu saat kita perlu mendiagnosis masalah kegagalan verifikasi.

sequenceDiagram
    autonumber
    participant C as Server Caddy
    participant API as API Provider DNS (e.g. Cloudflare)
    participant CA as Server CA (Let's Encrypt)
    participant DNS as Nameserver DNS Publik

    C->>CA: POST /newOrder (Minta sertifikat *.example.com)
    CA-->>C: JWS Response (Ini token tantangan: H3t8xK_qP2...)
    C->>API: POST /dns_records (Buat TXT record _acme-challenge.example.com)
    API->>DNS: Tulis TXT record ke Nameserver
    Note over C, DNS: Caddy menunggu propagasi DNS (caching check)
    CA->>DNS: Query TXT _acme-challenge.example.com
    DNS-->>CA: Respons TXT record (H3t8xK_qP2...)
    Note over CA: CA memverifikasi kecocokan token kriptografis
    CA-->>C: Terbitkan Sertifikat TLS (Format DER)
    C->>API: DELETE /dns_records (Hapus TXT record sementara)

Rincian Lini Masa Proses: #

1. Permintaan Awal (T+0): Caddy menghubungi direktori ACME CA dan meminta pembuatan pesanan (order) sertifikat baru untuk domain, misalnya *.example.com.
2. Pengiriman Token (T+1): CA merespons dengan memberikan token verifikasi unik dan meminta Caddy untuk membuat TXT record dengan nama host _acme-challenge.example.com.
3. Pemberitahuan ke DNS API (T+2): Caddy memanggil API penyedia DNS kita (seperti Cloudflare atau AWS Route 53) untuk membuat TXT record tersebut dengan nilai token yang telah ditandatangani.
4. Penyebaran Record (T+3): Penyedia DNS mempublikasikan catatan baru tersebut pada jajaran authoritative nameservers mereka.
5. Pengecekan Propagasi Mandiri (T+4): Sebelum menyuruh CA melakukan verifikasi, Caddy secara cerdas melakukan kueri DNS lokal untuk memastikan record tersebut sudah dapat dibaca di internet.
6. Kueri Verifikasi oleh CA (T+n): Setelah record terdeteksi, Caddy memberi tahu CA bahwa tantangan siap diverifikasi. CA kemudian melakukan kueri DNS publik secara mandiri untuk membaca TXT record tersebut.
7. Penerbitan Sertifikat (T+n+1): Jika token cocok, status otorisasi domain berubah menjadi valid. CA menerbitkan sertifikat TLS dan mengirimkannya ke Caddy.
8. Pembersihan Zona DNS (T+n+2): Caddy memanggil kembali API DNS untuk menghapus TXT record sementara agar zona DNS kita tetap bersih dan rapi.

Memahami Hambatan Utama: Propagation Delay #

Tantangan terbesar dalam implementasi DNS challenge adalah Propagation Delay (penundaan penyebaran). Berbeda dengan HTTP-01 yang bersifat instan begitu token ditulis ke disk, perubahan catatan DNS membutuhkan waktu untuk menyebar ke seluruh infrastruktur internet.

Faktor-Faktor yang Mempengaruhi Waktu Penyebaran DNS:

1. Mekanisme Caching TTL:
   Setiap catatan DNS memiliki nilai Time-To-Live (TTL). Caching resolver publik
   (seperti Google DNS 8.8.8.8 or Cloudflare 1.1.1.1) akan menyimpan hasil kueri
   sebelumnya selama sisa waktu TTL. Jika CA melakukan kueri sebelum record menyebar,
   mereka akan menerima jawaban kosong dan menolak tantangan.
   
2. Kecepatan Replikasi Provider DNS:
   Provider global (seperti Cloudflare) menggunakan arsitektur Anycast yang mereplikasi
   perubahan catatan ke ratusan server nama mereka di seluruh dunia dalam waktu < 10 detik.
   Provider lain yang lebih lambat mungkin membutuhkan waktu 1 hingga 5 menit untuk
   mereplikasi data.
   
3. Multi-Perspective Validation (MPV):
   Karena Let's Encrypt memeriksa catatan DNS dari beberapa lokasi satelit global secara
   bersamaan, seluruh server nama otoritatif domain kita harus sudah selesai mereplikasi
   data record baru tersebut agar tantangan dinyatakan valid.

Konfigurasi Parameter Propagasi di Caddyfile #

Caddy menyediakan opsi konfigurasi di dalam direktif tls untuk mengontrol bagaimana Caddy menangani penundaan penyebaran DNS:

# Konfigurasi Caddyfile dengan parameter propagasi tingkat lanjut
*.example.com {
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        
        # Waktu tunggu maksimal bagi Caddy untuk mendeteksi record sebelum menyerah (default: 2m)
        # Naikkan nilainya jika provider DNS kita lambat mereplikasi data
        propagation_timeout 5m
        
        # Jeda statis sebelum Caddy mulai memanggil resolver DNS untuk pengecekan pertama
        propagation_delay 30s
        
        # Menentukan DNS resolver publik spesifik untuk memeriksa propagasi
        # Sangat direkomendasikan untuk menghindari cache lokal sistem operasi
        resolvers 1.1.1.1 8.8.8.8
    }
    
    reverse_proxy localhost:8080
}

Split-Horizon DNS dan Resolving Lokal #

Dalam arsitektur jaringan internal perusahaan, kita sering kali menerapkan Split-Horizon DNS (atau Split-Brain DNS). Ini adalah kondisi di mana suatu domain publik (misal app.company.com) diarahkan ke IP privat (seperti 10.0.0.5) saat diakses dari dalam kantor, namun diarahkan ke IP publik saat diakses dari internet luar.

Ketika Caddy melakukan verifikasi propagasi mandiri di dalam jaringan lokal perusahaan, ia akan kueri DNS server internal kita. Jika DNS server internal kita lambat mereplikasi atau memiliki aturan proteksi khusus, Caddy mungkin mengira TXT record belum ada dan menyebabkan kegagalan timeout.

Solusinya adalah mengonfigurasi opsi resolvers di Caddyfile untuk menggunakan IP server nama eksternal (nameservers asli domain kita, seperti nameserver Cloudflare atau 1.1.1.1) agar pengecekan Caddy lolos secara cepat dan akurat:

# Menggunakan resolver eksternal untuk melintasi Split-Horizon DNS
app.company.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
        # bypass DNS lokal perusahaan, cek langsung ke Cloudflare/Google DNS
        resolvers 1.1.1.1 8.8.8.8
    }
    reverse_proxy localhost:8080
}

Taktik Lanjutan: DNS Challenge Delegation (CNAME Redirection) #

Dalam lingkungan perusahaan yang ketat, zona DNS untuk domain produksi utama (misal company.com) biasanya dikunci rapat demi alasan keamanan. Memberikan kredensial API DNS dengan akses menulis (write access) ke zona utama ini pada server web produksi Caddy dapat menimbulkan risiko keamanan yang tidak dapat diterima oleh tim keamanan.

Untuk mengatasi dilema keamanan ini, kita dapat memanfaatkan taktik DNS Challenge Delegation menggunakan catatan CNAME. Protokol ACME mendefinisikan bahwa ketika CA mencari TXT record di _acme-challenge.example.com dan menemukan catatan CNAME, CA akan mengikuti petunjuk CNAME tersebut ke target baru dan mencari TXT record di domain tujuan.

Alur Pendelegasian DNS Challenge via CNAME:

Zona DNS Utama (company.com) - Dikunci Rapat, Tanpa Akses API:
  - Buat CNAME permanen:
    _acme-challenge.production.company.com  CNAME  production.challenge.company-ops.com

Zona DNS Sekunder (company-ops.com) - Akses API Diizinkan untuk Caddy:
  - Caddy memanggil API DNS hanya untuk zona company-ops.com.
  - Caddy membuat TXT record di:
    production.challenge.company-ops.com  TXT  "token_verifikasi_kriptografis"

Hasil Validasi:
  - CA Let's Encrypt mencari TXT di _acme-challenge.production.company.com.
  - CA diarahkan ke production.challenge.company-ops.com.
  - CA membaca token verifikasi dengan sukses.
  - Sertifikat diterbitkan untuk production.company.com tanpa tereksposnya API key utama!

Konfigurasi Caddyfile Delegasi DNS: #

Di Caddyfile kita, kita cukup mendefinisikan plugin DNS kita yang diarahkan ke zona sekunder (misalnya Cloudflare token yang memegang izin zona company-ops.com):

# Caddyfile di server produksi
production.company.com {
    tls {
        # Token Cloudflare di bawah ini hanya memiliki izin mengedit zona company-ops.com
        dns cloudflare {env.CF_CHALLENGE_ZONE_TOKEN}
    }
    
    reverse_proxy localhost:8080
}

Panduan Konfigurasi Provider DNS Utama #

Berikut adalah contoh konfigurasi terperinci untuk beberapa penyedia layanan DNS terbesar yang didukung oleh Caddy:

1. AWS Route 53 #

Route 53 menggunakan arsitektur identitas AWS IAM. Kita disarankan menyuntikkan kredensial menggunakan variabel lingkungan standar AWS:

# Caddyfile AWS Route 53
*.example.com {
    tls {
        dns route53 {
            # Opsional: tentukan waktu percobaan ulang jika API AWS sibuk
            max_retries 10
        }
    }
    reverse_proxy localhost:3000
}

# Suntikkan variabel lingkungan ini sebelum menjalankan Caddy
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_REGION="us-east-1"

2. Google Cloud DNS #

GCP DNS memerlukan file kunci JSON dari Akun Layanan (Service Account) yang memiliki peran (role) Administrator DNS.

Langkah Pembuatan Service Account di GCP: #

1. Jalankan perintah di Cloud Shell atau komputer lokal:

# Membuat Service Account baru
gcloud iam service-accounts create caddy-dns-sa --display-name "Caddy DNS SA"

# Memberikan peran dns.admin ke Service Account
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:caddy-dns-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role "roles/dns.admin"

# Mengunduh kunci JSON Service Account ke file lokal
gcloud iam service-accounts keys create /etc/caddy/gcp-dns-key.json \
    --iam-account caddy-dns-sa@PROJECT_ID.iam.gserviceaccount.com

Caddyfile Google Cloud DNS: #

# Caddyfile Google Cloud DNS
*.example.com {
    tls {
        dns googleclouddns {
            gcp_project "nama-project-gcp-kita"
        }
    }
    reverse_proxy localhost:8000
}

# Mengarahkan Caddy ke lokasi berkas Service Account JSON
export GOOGLE_APPLICATION_CREDENTIALS="/etc/caddy/gcp-dns-key.json"

3. Azure DNS #

Azure memerlukan informasi lengkap mengenai Azure Active Directory Service Principal:

# Caddyfile Azure DNS
*.example.com {
    tls {
        dns azure {
            tenant_id       {env.AZURE_TENANT_ID}
            client_id       {env.AZURE_CLIENT_ID}
            client_secret   {env.AZURE_CLIENT_SECRET}
            subscription_id {env.AZURE_SUBSCRIPTION_ID}
            resource_group  "resource-group-dns-kita"
        }
    }
    reverse_proxy localhost:5000
}

Tabel Komparatif Performa Provider DNS #

Pilihan penyedia DNS sangat memengaruhi kecepatan penerbitan sertifikat awal pada server kita. Berikut tabel perbandingan beberapa provider populer:

Praktik Keamanan Kredensial API #

Kredensial API DNS adalah kunci gerbang ke seluruh domain kita. Jika kredensial ini bocor, pihak luar dapat mengubah lalu lintas email kita (MX record), mengarahkan situs kita ke server phising, atau mematikan layanan kita sepenuhnya.

Kebijakan Pengamanan Kredensial: #

• Hak Akses File Sangat Ketat: Simpan semua variabel lingkungan kredensial pada berkas konfigurasi terpisah (misalnya /etc/caddy/caddy.env) dan set izin file tersebut hanya dapat dibaca oleh root dan user caddy:

# Membuat berkas kredensial terproteksi
sudo touch /etc/caddy/caddy.env
sudo chown caddy:caddy /etc/caddy/caddy.env
sudo chmod 600 /etc/caddy/caddy.env

• Gunakan Docker Secrets atau Kubernetes Secrets: Di lingkungan orkestrasi kontainer, jangan tulis kunci API di berkas manifest YAML mentah. Gunakan fitur manajemen rahasia bawaan platform untuk menyuntikkan nilai secara aman ke dalam kontainer Caddy pada saat runtime.

Pemecahan Masalah (Troubleshooting) DNS Challenge #

1. Caddy Gagal Membuat TXT Record di DNS #

• Gejala di Log: Pesan kesalahan failed to create TXT record atau Authentication Error.
• Penyebab: Izin token API yang diberikan pada dasbor provider kurang (misalnya lupa memberikan hak akses Edit atau salah memilih zona domain).
• Solusi: Periksa kembali konfigurasi token di dasbor DNS provider. Untuk Cloudflare, verifikasi menggunakan perintah kueri curl manual untuk memastikan token kita memiliki hak akses menulis ke zona terkait.

2. Tantangan ACME Mengalami Timeout #

• Gejala di Log: Caddy terus-menerus menampilkan log waiting for propagation... hingga akhirnya melahirkan pesan error timeout.
• Penyebab: Server nama DNS (Nameservers) provider lambat melakukan replikasi, atau Caddy menggunakan DNS resolver lokal sistem operasi yang menyimpan cache kueri lama yang kosong.
• Solusi: Tambahkan konfigurasi resolvers 1.1.1.1 8.8.8.8 pada blok tls Caddyfile agar Caddy memeriksa propagasi langsung ke resolver publik yang memperbarui datanya secara cepat, dan naikkan parameter propagation_timeout ke 10m.

Ringkasan #

• DNS-01 Challenge — Metode verifikasi ACME menggunakan catatan TXT record di zona DNS domain untuk membuktikan kontrol administratif.
• Tanpa Port Terbuka — DNS-01 tidak membutuhkan port masuk HTTP (80) atau HTTPS (443) terbuka ke server, menjadikannya solusi ideal untuk server di jaringan privat/internal.
• Satu-satunya untuk Wildcard — DNS challenge adalah satu-satunya metode yang diperbolehkan oleh Certificate Authority untuk menerbitkan sertifikat wildcard (*.domain.com).
• Propagation Delay — Waktu tunggu replikasi data DNS ke seluruh server nama global. Konfigurasikan parameter propagation_timeout dan resolvers khusus di Caddyfile untuk mencegah timeout.
• DNS Delegation — Taktik mengarahkan verifikasi ACME ke zona DNS sekunder menggunakan CNAME untuk menjaga keamanan kredensial API domain utama.
• Keamanan Kredensial — Lindungi berkas variabel lingkungan yang berisi token API DNS menggunakan permission berkas 600 dan batasi scope izin token hanya pada tingkat edit zona DNS terkait.

← Sebelumnya: Wildcard Certificate   Berikutnya: Static Files →