Kenapa Domain SERVFAIL Setelah Pindah DNS Provider yang Pakai DNSSEC

Domain baru saja dipindah ke DNS provider lain dan semua record sudah disalin. Dari laptop sendiri website terbuka normal. Tapi sebagian pengunjung bilang domainnya tidak bisa diakses, dan saat dicek dengan dig di resolver tertentu, jawabannya SERVFAIL. Kalau domain itu sebelumnya pakai DNSSEC, penyebab yang paling sering bukan record yang hilang, melainkan DS record di registrar yang masih menunjuk ke key milik provider lama. Catatan ini aku tulis sebagai rangkuman belajar: apa yang sebenarnya terjadi, bagian mana yang gampang disalahpahami, dan cara melatihnya dengan aman sebelum menyentuh domain produksi.

Apa yang dicek resolver saat DNSSEC aktif

DNSSEC tidak mengenkripsi DNS. Yang ditambahkan adalah tanda tangan digital, supaya resolver bisa memastikan jawaban benar-benar berasal dari pemilik zona dan tidak diubah di tengah jalan. Ada tiga record yang perlu dipahami:

DNSKEY: public key zona, disajikan oleh nameserver authoritative domain kamu. Biasanya ada dua jenis. KSK (key signing key, flag 257) dipakai untuk menandatangani set DNSKEY itu sendiri. ZSK (zone signing key, flag 256) dipakai untuk menandatangani record lain.
RRSIG: tanda tangan untuk setiap set record, misalnya untuk semua A record di example.com.
DS (delegation signer): hash dari KSK. Record ini tidak disimpan di zona kamu, tapi di zona parent, yaitu zona TLD seperti .com atau .id. Kamu memasukkannya lewat registrar.

Resolver yang melakukan validasi berjalan dari root ke bawah. Root menjamin TLD, lalu TLD mempublikasikan DS untuk domain kamu. Resolver kemudian meminta DNSKEY ke nameserver domain, menghitung hash KSK-nya, dan mencocokkan hasilnya dengan DS dari parent. Kalau cocok, rantai kepercayaan tersambung dan RRSIG di bawahnya bisa diverifikasi. Kalau tidak cocok, atau parent bilang zona ini bertanda tangan tapi nameserver tidak menyajikan DNSKEY sama sekali, jawabannya dianggap bogus. Resolver lalu mengembalikan SERVFAIL, bukan jawaban yang mungkin palsu. Itu sebabnya masalah ini terjadi setelah migrasi. Provider baru membuat key baru, atau tidak menandatangani zona sama sekali. Sementara itu, DS di parent masih berisi hash key provider lama, dan private key lama itu tidak ikut pindah.

Kenapa hanya sebagian resolver yang gagal

Bagian ini yang paling sering membingungkan, baik bagi pemilik domain maupun teman support di L1. Tidak semua resolver melakukan validasi DNSSEC. Resolver yang tidak memvalidasi akan mengabaikan DS dan RRSIG, lalu langsung mengembalikan A record dari nameserver baru. Resolver yang memvalidasi akan menolaknya. Hasilnya, pengguna yang memakai resolver bawaan ISP tertentu bisa membuka website dengan lancar, sementara pengguna resolver lain mendapat error. Di sisi support, pola ini sering terbaca sebagai masalah propagasi, jadi sarannya tunggu saja. Masalahnya, menunggu tidak akan menyelesaikan apa pun selama DS lama masih ada di parent. Ini bukan soal cache yang belum kedaluwarsa. Ini rantai validasi yang memang putus. Cache tetap ikut berperan, tapi di arah yang berlawanan. DS record punya TTL sendiri di zona parent. Jadi setelah DS dihapus di registrar pun, resolver yang sudah menyimpan DS lama akan tetap memakainya sampai TTL itu habis.

Yang gampang disalahpahami saat migrasi

Ada beberapa asumsi yang kelihatannya masuk akal tapi justru memperparah situasi. Pertama, mematikan DNSSEC di provider lama lebih dulu. Banyak orang mengira urutannya: matikan signing, lalu pindah. Padahal kalau provider lama berhenti menyajikan DNSKEY dan RRSIG sementara DS masih ada di parent, domain langsung bogus, bahkan sebelum nameserver dipindah. Signing di sisi lama justru harus tetap jalan sampai DS benar-benar hilang dari cache resolver. Kedua, menyalin record DNSKEY lama ke zona baru. Record DNSKEY memang bisa disalin sebagai teks, tapi provider baru tidak punya private key-nya. Akibatnya, provider baru tidak bisa membuat RRSIG yang valid untuk key tersebut, dan validasi tetap gagal. Ketiga, menganggap menyalakan DNSSEC di provider baru sudah cukup. Provider baru memang menandatangani zona, tapi dengan key miliknya sendiri. Selama DS di registrar belum diganti dengan DS dari provider baru, hash-nya tidak akan cocok. Perlu diingat juga bahwa registrar dan DNS provider bisa berupa dua pihak yang berbeda. DS hanya bisa diubah di registrar, sedangkan key hanya ada di DNS provider. Kalau domain dan DNS ada di tempat berbeda, kedua sisi harus dikoordinasikan.

Urutan aman memindahkan domain yang sudah ditandatangani

Cara yang paling sederhana dan paling jarang meleset adalah melepas DNSSEC sementara, pindah dalam kondisi tanpa tanda tangan, lalu menandatangani ulang di provider baru. Urutannya:

Salin semua record ke provider baru sebelum nameserver diganti. Detail langkah ini ada di catatan Pre-populating DNS Records on New Nameservers Before Registrar Cutover.
Hapus DS record di registrar. Jangan matikan signing di provider lama dulu.
Cek TTL DS di zona parent, lalu tunggu minimal selama TTL itu ditambah sedikit margin. Pastikan dengan dig langsung ke nameserver TLD bahwa DS sudah tidak ada.
Setelah itu, signing di provider lama aman dimatikan. Domain sekarang berstatus insecure, artinya tidak divalidasi tapi tetap bisa di-resolve.
Ganti nameserver di registrar ke provider baru, lalu tunggu TTL NS lama habis.
Aktifkan DNSSEC di provider baru dan ambil nilai DS yang diberikan.
Masukkan DS baru di registrar, lalu verifikasi rantainya dengan dig dan delv.

Konsekuensinya, selama beberapa waktu domain tidak dilindungi DNSSEC. Untuk kebanyakan website, ini trade-off yang wajar dibanding risiko SERVFAIL. Alternatifnya adalah migrasi multi-signer, di mana kedua provider saling memasukkan DNSKEY satu sama lain sehingga rantai tidak pernah putus. Cara ini lebih rapi tapi jauh lebih rumit, dan hanya bisa dilakukan kalau kedua provider mendukung impor DNSKEY eksternal. Cek dokumentasi masing-masing, jangan berasumsi. Beberapa registrar dan TLD juga mendukung CDS/CDNSKEY untuk update DS otomatis. Itu pun perlu dicek per registrar.

Cara mengecek rantai validasi dengan dig

Intinya ada tiga pertanyaan: DS apa yang dipublikasikan parent, DNSKEY apa yang disajikan nameserver, dan apakah keduanya cocok. Perintah di bawah semuanya read-only.

BASH

# 1. Cari nameserver TLD, lalu tanya DS langsung ke sana (contoh untuk .com)
dig +short NS com.
dig +norec @a.gtld-servers.net example.com DS

# 2. DNSKEY yang disajikan nameserver baru; +multi menampilkan key id
dig @ns1.provider-baru.example example.com DNSKEY +multi

# 3. Bandingkan jawaban normal dan tanpa validasi (jalankan dari resolver yang memvalidasi)
dig example.com A
dig example.com A +cd

# 4. Minta penjelasan validasi (delv ada di paket tools BIND)
delv example.com A

Cara membacanya kira-kira seperti ini:

TEXT

; contoh format output, bukan dari kejadian nyata
example.com.  86400 IN DS 11111 13 2 (digest dipotong)

example.com.  3600 IN DNSKEY 257 3 13 (
              (key dipotong) ) ; KSK; alg = ECDSAP256SHA256 ; key id = 22222

Angka pertama setelah DS adalah key tag. Bandingkan dengan key id di DNSKEY yang ber-flag 257. Pada contoh di atas, DS menunjuk ke 11111 sementara nameserver hanya punya 22222, jadi rantainya putus. Angka algoritma, yaitu 13 di contoh, juga harus sama. Kalau DS ada tapi query DNSKEY tidak mengembalikan apa-apa, artinya provider baru belum menandatangani zona sama sekali. Perbandingan di langkah 3 adalah cara cepat untuk memastikan penyebabnya. Flag +cd (checking disabled) meminta resolver tidak melakukan validasi. Kalau tanpa +cd hasilnya SERVFAIL tapi dengan +cd jawabannya normal, hampir pasti masalahnya ada di DNSSEC, bukan di record atau nameserver. Sebaliknya, kalau dengan +cd pun gagal, cari penyebab lain. Kasus CNAME ke layanan luar yang DNSSEC-nya rusak juga menunjukkan gejala serupa, dan sudah dibahas di How to Test If a Broken CNAME Target Is Causing DNS SERVFAIL. Untuk TLD selain .com dan .net, ganti a.gtld-servers.net dengan salah satu nameserver hasil dig NS untuk TLD tersebut.

Latihan aman sebelum menyentuh domain produksi

Menurutku, DNSSEC paling cepat dipahami kalau pernah sengaja dirusak di lingkungan yang aman. Siapkan satu domain cadangan yang tidak dipakai siapa pun dan satu VPS uji. Di VPS itu, pasang resolver yang melakukan validasi, misalnya Unbound atau BIND. Pastikan validasinya benar-benar aktif, karena default-nya tergantung paket dan konfigurasi distro. Aktifkan DNSSEC di DNS provider untuk domain cadangan, pasang DS di registrar, lalu pastikan dig dari VPS menunjukkan flag ad (authenticated data) di header jawaban. Setelah itu, coba ulangi kesalahan yang umum: matikan signing tanpa menghapus DS, atau pindah nameserver dengan DS lama masih terpasang. Amati kapan SERVFAIL muncul, bagaimana +cd menjawab, dan apa yang dilaporkan delv. Lalu perbaiki dengan urutan yang benar dan catat berapa lama kamu harus menunggu TTL DS di TLD tersebut. Latihan seperti ini juga berguna untuk membuat checklist tim support. Saat ada keluhan domain hanya error di sebagian jaringan setelah pindah DNS, pertanyaan pertama yang perlu diajukan adalah apakah domain itu pakai DNSSEC dan di mana DS-nya dikelola. Pegangan praktisnya sederhana. Sebelum memindahkan nameserver, selalu cek dulu dengan dig apakah domain punya DS di parent. Kalau ada, hapus DS lebih dulu, tunggu TTL-nya habis, baru pindah, lalu pasang DS baru dari provider baru. Kalau sudah terlanjur SERVFAIL, perbaikan paling cepat biasanya adalah menghapus DS lama di registrar atau menggantinya dengan DS dari provider baru, lalu bersabar menunggu cache resolver kedaluwarsa.