Migrasi nameserver bisa terlihat berhasil di semua panel kontrol, tetapi situs web tetap tidak dapat diakses. Domain masih aktif, nameserver otoritatif yang baru mengembalikan alamat yang benar, dan tidak ada perubahan pada server web. Namun, resolver DNS yang melakukan validasi justru mengembalikan SERVFAIL. Penyebab yang sering terlewat adalah delegasi DNSSEC yang masih memercayai kunci penandatanganan milik penyedia DNS sebelumnya.
Dalam insiden yang menjadi dasar penyelidikan ini, kueri DNS biasa gagal, sedangkan kueri yang sama berhasil ketika validasi DNSSEC dilewati. Zona induk masih menerbitkan record DS lama, sementara zona otoritatif yang baru pada awalnya belum ditandatangani. Penerbitan kunci yang cocok dan penandatanganan zona baru memulihkan jawaban yang tervalidasi pada resolver yang diuji. Pelajaran utamanya bukan bahwa DNSSEC harus dimatikan, melainkan bahwa pemindahan nameserver dan pemindahan rantai kepercayaan DNSSEC merupakan dua proses yang berbeda.
Mengapa record A yang benar tetap bisa menghasilkan SERVFAIL
DNS menjawab dua pertanyaan yang berbeda. Record A memberi tahu resolver alamat IPv4 yang terkait dengan suatu nama domain. Sementara itu, DNSSEC memberi tahu resolver yang melakukan validasi apakah jawaban tersebut dapat dipercaya. Data alamat yang benar tidak otomatis berarti rantai kepercayaan DNSSEC juga valid.
Untuk domain yang ditandatangani, rantai kepercayaan dimulai dari zona induk tepercaya, kemudian melalui record DS (Delegation Signer) menuju DNSKEY di zona anak. Zona anak menerbitkan tanda tangan (RRSIG) untuk data DNS-nya. Record DS berisi digest yang mengidentifikasi DNSKEY yang diotorisasi. Record ini bukan record A, bukan salinan kunci privat, dan bukan pengaturan dalam editor file zona pada umumnya.
Setelah nameserver otoritatif diganti, zona induk mungkin masih menerbitkan record DS yang terkait dengan penanda tangan sebelumnya. Jika zona baru tidak memiliki DNSKEY dan tanda tangan yang sesuai, resolver yang melakukan validasi tidak dapat menyelesaikan rantai kepercayaan. Biasanya resolver akan menganggap jawaban tersebut tidak valid secara kriptografis dan mengembalikan SERVFAIL, bukan alamat yang belum terverifikasi.
Masalah ini berbeda dari gangguan HTTP. Permintaan mungkin bahkan tidak pernah mencapai server web. Masalah ini juga berbeda dari sertifikat TLS yang kedaluwarsa: DNSSEC memvalidasi data DNS, sedangkan HTTPS melindungi koneksi yang terjadi kemudian antara browser dan server.
Diagnosis untuk membedakan masalah DNSSEC dari record yang tidak ditemukan
Pengujian yang paling membantu adalah menjalankan dua kueri untuk nama domain yang sama melalui resolver yang sama. Pertama, jalankan kueri biasa dan periksa statusnya, bukan hanya jawabannya:
dig example.com A +noall +comments +answerKemudian ulangi kueri dengan mengaktifkan bit DNSSEC Checking Disabled (CD):
dig example.com A +cdflag +noall +comments +answerDalam kegagalan yang diamati, kueri biasa menghasilkan SERVFAIL, sedangkan kueri dengan CD mengembalikan record A yang diharapkan. Perbedaan ini sangat mengarah pada masalah validasi DNSSEC, bukan record DNS yang hilang atau aplikasi yang tidak merespons. Opsi +cdflag meminta resolver rekursif yang mendukungnya untuk tidak menjalankan validasi DNSSEC seperti biasa pada permintaan tersebut. Opsi ini merupakan alat diagnosis, bukan perbaikan di sisi browser atau cara menonaktifkan DNSSEC bagi pengunjung.
Jangan terlalu cepat mengambil kesimpulan dari keluaran +short yang kosong. Jawaban yang tidak ditemukan maupun kegagalan SERVFAIL sama-sama dapat terlihat kosong dalam format tersebut. Selama diagnosis, pertahankan +comments agar status: SERVFAIL dan status: NOERROR tetap terlihat.
Perbandingan menggunakan CD saja tidak menunjukkan bagian DNSSEC mana yang gagal. Perbandingan tersebut hanya menunjukkan area yang perlu diperiksa berikutnya. Resolver juga mungkin mengalami gangguan sementara pada server upstream, jadi ulangi pengujian bila diperlukan dan periksa delegasi di zona induk.
Periksa record DS di zona induk, bukan hanya editor DNS
Periksa apakah domain memiliki record DS:
dig example.com DS +noall +comments +answerUntuk melihat jalur delegasi secara lebih lengkap, telusuri hierarki DNS secara langsung:
dig +trace example.com DSNameserver otoritatif untuk zona induk bergantung pada top-level domain yang digunakan. Yang penting adalah kumpulan record DS (DS RRset) yang diterbitkan oleh zona induk, bukan sekadar ringkasan yang ditampilkan di dasbor penyedia DNS. Transfer domain ke registrar lain dapat dilakukan tanpa mengubah nameserver, dan pergantian nameserver dapat dilakukan tanpa mengganti registrar. Dalam kedua situasi tersebut, record DS di zona induk harus tetap sesuai dengan zona otoritatif yang aktif.
Record DS memiliki empat bagian penting: key tag, algoritma, jenis digest, dan digest. Key tag merupakan penanda yang memudahkan pemecahan masalah, tetapi nilai tersebut saja tidak membuktikan bahwa sebuah DNSKEY cocok. Informasi digest dan algoritmanya juga harus sesuai dengan kunci yang benar-benar disajikan oleh zona otoritatif.
Kondisi yang menentukan dalam kasus ini cukup sederhana: zona induk masih mengumumkan informasi kepercayaan DNSSEC sebelumnya, sedangkan zona otoritatif pengganti melaporkan bahwa penandatanganan tidak aktif. Record A tersedia dan dapat diambil ketika validasi dilewati. Mengubah konfigurasi aplikasi atau berulang kali mengedit record A yang sama tidak akan memperbaiki ketidaksesuaian tersebut.
Dua cara memulihkan delegasi DNSSEC yang bermasalah
Ada dua strategi pemulihan yang sah. Keduanya mengatasi ketidaksesuaian rantai kepercayaan yang sama, tetapi konsekuensi operasionalnya berbeda. Pilih salah satunya dengan sengaja dan hindari berganti-ganti strategi secara acak.
Opsi 1: Hapus DS lama dan gunakan zona tanpa tanda tangan untuk sementara
Minta registrar saat ini, atau gunakan antarmuka pengelolaan DNSSEC yang didukungnya, untuk menghapus record DS lama dari zona induk. Setelah zona induk tidak lagi menyatakan bahwa delegasi tersebut aman secara DNSSEC, resolver yang melakukan validasi dapat memperlakukan zona anak yang tidak ditandatangani sebagai tidak diamankan oleh DNSSEC, bukan sebagai data yang tidak valid. DNS tetap berfungsi, tetapi autentikasi DNSSEC untuk domain tersebut untuk sementara tidak tersedia.
Ini sering menjadi pilihan darurat yang lebih sederhana, asalkan tersedia cara yang andal untuk mengubah DS RRset di zona induk. Pertahankan konfigurasi penandatanganan yang sudah ada hingga record DS lama kedaluwarsa dari cache resolver rekursif. Menghapus DS melalui panel kontrol saja belum cukup sebagai bukti: verifikasi record di zona induk melalui layanan eksternal dan perhitungkan TTL-nya. HTTPS tetap bekerja secara independen dari pengaturan DNSSEC. Transisi sementara ke zona tanpa tanda tangan juga dijelaskan dalam RFC 8078.
Opsi 2: Tandatangani zona baru dan terbitkan DS yang cocok
Alternatifnya adalah mengaktifkan DNSSEC pada penyedia DNS otoritatif yang baru, membuat materi kunci DNSKEY, menandatangani zona, lalu menerbitkan record DS yang sesuai di zona induk. Dengan demikian, resolver yang melakukan validasi dapat membangun jalur kepercayaan menuju DNSKEY baru dan memvalidasi record A.
Inilah jalur pemulihan yang benar-benar diamati dalam kasus tersebut. Antarmuka pengelolaan DNS melaporkan bahwa kunci telah dibuat, zona telah ditandatangani, dan record DS baru telah diterbitkan. Kueri berikutnya ke zona induk menunjukkan record DS baru bersama record sebelumnya. Kueri rekursif yang menggunakan validasi mulai mengembalikan record A yang diharapkan. Pengujian berikutnya juga menghasilkan NOERROR dengan flag ad, yang menandakan bahwa resolver tersebut telah mengautentikasi data.
Urutannya penting: record DS yang diterbitkan hanya berguna jika DNSKEY yang sesuai dan tanda tangan yang valid sudah tersedia dari layanan DNS otoritatif. Status “published” pada panel kontrol tidak dapat menggantikan verifikasi eksternal. Record DS, DNSKEY, RRSIG, dan NS yang tersimpan dalam cache dapat menyebabkan resolver yang berbeda pulih pada waktu yang berbeda pula.
Mengapa dua record DS tidak selalu membuat situs tetap bermasalah
Salah satu hasil yang mengejutkan adalah zona induk untuk sementara berisi dua record DS sekaligus, yakni satu record lama yang sudah tidak berlaku dan satu record baru yang valid, tetapi validasi DNSSEC tetap berhasil. Hal ini tidak bertentangan dengan cara kerja DNSSEC. Sebuah DS RRset dapat berisi beberapa record, seperti yang sering terjadi saat pergantian kunci. Validator tidak mengharuskan setiap record DS menunjuk ke kunci yang masih dapat digunakan. Validator hanya memerlukan satu jalur autentikasi yang valid melalui record DS yang sesuai menuju DNSKEY dan tanda tangan yang valid. RFC 6840 menjelaskan bahwa validator seharusnya menerima satu jalur yang valid.
Namun, bukan berarti record DS lama sebaiknya dibiarkan selamanya. Record DS yang sudah tidak berlaku menambah ketidakjelasan operasional dan pada akhirnya perlu dibersihkan setelah rantai kepercayaan baru terverifikasi. Meski demikian, penghapusannya merupakan pekerjaan pemeliharaan, bukan alasan untuk melakukan reset DNSSEC yang berisiko ketika kueri yang tervalidasi sudah kembali berhasil.
Ada jebakan yang sangat berbahaya pada panel kontrol: tindakan bernama “emergency unpublish DS” mungkin berarti menghapus semua record DS, termasuk record baru yang berfungsi. Demikian pula, menonaktifkan penandatanganan zona saat record DS masih diterbitkan dapat langsung menyebabkan gangguan yang sama terulang. Kedua tindakan tersebut tidak sama dengan menghapus satu record DS lama tertentu. Jika antarmuka tidak memungkinkan penghapusan record secara individual, gunakan perubahan selektif yang didukung registrar, bukan reset menyeluruh.
Cara mengganti nameserver otoritatif dengan aman
Urutan paling aman bergantung pada kemampuan penyedia DNS lama dan baru untuk mengoordinasikan kunci. Untuk migrasi biasa yang menggunakan periode sementara tanpa DNSSEC, urutan berikut menghindari ketidaksesuaian yang terjadi dalam insiden ini:
- Siapkan zona tujuan terlebih dahulu. Salin record A, AAAA, CNAME, MX, TXT, dan record lain yang diperlukan. Uji nameserver otoritatif baru secara langsung sebelum mengubah delegasi.
- Periksa DNSSEC di zona induk. Pastikan apakah ada record DS dan identifikasi pihak yang dapat memperbaruinya. Lakukan pemeriksaan ini meskipun Anda tidak pernah mengaktifkan DNSSEC secara manual karena beberapa layanan DNS mengotomatiskan penandatanganan.
- Hapus DS lama ketika zona lama yang ditandatangani masih beroperasi. Konfirmasikan perubahan pada zona induk otoritatif, lalu tunggu hingga data DS yang sebelumnya tersimpan dalam cache kedaluwarsa. Lama penantian ditentukan oleh TTL yang diamati, bukan jumlah menit tetap yang berlaku secara universal.
- Ubah delegasi nameserver. Pertahankan layanan otoritatif sebelumnya selama delegasi NS yang tersimpan dalam cache masih mungkin mengarah ke layanan tersebut. Perhitungkan TTL record NS di zona induk dan periksa server mana yang benar-benar digunakan oleh berbagai resolver.
- Tentukan apakah DNSSEC akan diaktifkan kembali. Jika layanan baru akan tetap tanpa tanda tangan, jangan terbitkan DS. Jika zona baru akan ditandatangani, pastikan DNSKEY dan tanda tangannya sudah disajikan dengan benar sebelum menerbitkan DS yang sesuai. Koordinasikan langkah ini dengan cache NS lama yang mungkin masih tersisa agar tidak menimbulkan ketidaksesuaian validasi baru.
- Lakukan validasi secara independen. Periksa DS pada zona induk, DNSKEY pada layanan otoritatif, resolusi rekursif biasa, dan hasil autentikasi data dari resolver yang melakukan validasi.
Jika perlindungan DNSSEC harus tetap tersedia tanpa jeda, pergantian kunci yang dikoordinasikan secara khusus atau transisi dengan beberapa penanda tangan lebih baik daripada periode tanpa tanda tangan. Namun, kedua penyedia DNS harus mendukung pengaturan kunci dan penandatanganan yang diperlukan. Sekadar menyalin digest DS lama ke penyedia baru bukanlah proses pergantian kunci.
Daftar pemeriksaan singkat setelah migrasi
Setelah melakukan perubahan terkait DNSSEC, periksa record DNS sekaligus bukti bahwa resolver menerimanya:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerGunakan resolver rekursif yang melakukan validasi untuk memeriksa jawaban yang telah diautentikasi. Dalam responsnya, NOERROR disertai record A yang diharapkan berarti resolusi berhasil. Jika flag ad juga muncul, resolver tersebut menyatakan bahwa jawabannya telah diautentikasi sesuai kebijakan DNSSEC yang digunakannya. Tidak adanya flag ad saja tidak membuktikan kegagalan, karena kemampuan resolver, kebijakan, dan flag kueri dapat berbeda. Jika kueri DNSKEY melalui resolver yang melakukan validasi gagal selama gangguan berlangsung, sertakan kueri langsung ke layanan DNS otoritatif yang aktif dalam penyelidikan.
Jangan berhenti hanya karena satu resolver berhasil menjawab. Cache yang berbeda mungkin untuk sementara menyimpan delegasi dan kunci yang berbeda. Perbarui juga permintaan dukungan operasional yang masih terbuka: instruksi sebelumnya untuk menghapus semua record DS menjadi berbahaya setelah record DS baru yang berfungsi diterbitkan. Tindak lanjut harus secara tegas mempertahankan kunci yang aktif dan, jika diperlukan, meminta penghapusan hanya record lama yang sudah tidak berlaku.
Kegagalan ini bukan disebabkan oleh alamat server web yang salah. Penyebabnya adalah perubahan lokasi layanan yang memberikan jawaban DNS tanpa terlebih dahulu menyelaraskan informasi kepercayaan yang digunakan resolver untuk menentukan jawaban mana yang dapat dipercaya. Karena itu, pertanyaan penting yang perlu dijawab sebelum setiap perpindahan nameserver adalah: Record DS apa saja yang diterbitkan oleh zona induk, dan apakah DNSKEY serta tanda tangan di layanan tujuan dapat memenuhi persyaratan record tersebut?