Kunci DNSSEC Root Sudah Berganti, Cek Resolver Server

Apakah server kamu menjalankan resolver DNS sendiri, misalnya unbound atau BIND, dengan validasi DNSSEC aktif? Kalau ya, ada satu hal yang perlu dicek sekarang. Sejak 11 Oktober 2026 pukul 14.00 UTC, root zone DNS ditandatangani kunci baru bernama KSK-2024 dengan key tag 38696. Resolver yang belum memercayai kunci ini bisa gagal memvalidasi jawaban DNS, dan akibatnya nama domain tidak bisa di-resolve sama sekali.

Kabar baiknya, pergantian ini berjalan sesuai rencana. ICANN melaporkan pada 15 Oktober 2026 bahwa rollover selesai, dengan catatan ada laporan masalah pada "a limited number of systems" yang masih mereka telusuri. Kalau server kamu hanya memakai resolver publik atau resolver bawaan penyedia, biasanya tidak ada yang perlu diubah.

Apa itu KSK dan kenapa diganti?

KSK (Key Signing Key) root zone adalah kunci paling atas dalam rantai kepercayaan DNSSEC. Resolver yang memvalidasi DNSSEC menyimpan kunci publiknya sebagai trust anchor, lalu memakai kunci itu untuk memeriksa bahwa jawaban DNS tidak diubah di tengah jalan. Kalau kamu belum akrab dengan DNSSEC, baca dulu apa itu DNSSEC dan perlukah diaktifkan.

Kunci ini diganti secara berkala sebagai bagian dari perawatan rutin. Pergantian pertama terjadi pada 2018. Kali ini KSK-2017 (key tag 20326) digantikan KSK-2024 (key tag 38696). Kunci baru sebenarnya sudah dipublikasikan di root zone sejak 11 Januari 2025, sehingga resolver yang memakai pembaruan trust anchor otomatis (RFC 5011) punya waktu panjang untuk mempelajarinya.

Siapa yang perlu mengecek?

Panduan ICANN untuk operator resolver cukup tegas: pastikan KSK-2024 ada di konfigurasi trust anchor dan jangan berasumsi pembaruan otomatis sudah berjalan.

Bagaimana cara mengecek resolver di server?

Langkah berikut berlaku umum. Lokasi file dan nama layanan bisa berbeda antar distro, jadi sesuaikan dengan sistemmu.

Langkah 1: Pastikan resolver memang memvalidasi DNSSEC

Kirim kueri ke resolver lokal dan lihat flag ad (authenticated data) di bagian header jawaban.

dig @127.0.0.1 iana.org A +dnssec

Bila flag ad muncul, resolver memvalidasi DNSSEC dan pengecekan berikutnya relevan. Bila resolver tidak memvalidasi sama sekali, pergantian KSK tidak memengaruhinya. Cara membaca keluaran dig dibahas di cara cek record DNS dengan dig dan nslookup.

Langkah 2: Uji dengan nama sentinel

Cloudflare menyediakan nama uji berbasis mekanisme root key sentinel. Arahkan ke resolver lokalmu:

dig @127.0.0.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @127.0.0.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

Bila resolver memercayai KSK-2024, perintah pertama memberi jawaban normal dan perintah kedua menghasilkan SERVFAIL. SERVFAIL di perintah kedua justru tanda baik. Bila resolver tidak mendukung sentinel, hasilnya tidak bisa disimpulkan, jadi lanjutkan ke langkah 3.

Langkah 3: Lihat isi trust anchor

Untuk unbound dengan auto-trust-anchor-file, buka file kunci root (di banyak distro letaknya /var/lib/unbound/root.key, cek nilai di unbound.conf untuk memastikan) lalu cari key tag-nya:

grep 38696 /var/lib/unbound/root.key

Unbound menulis komentar berisi id kunci pada setiap baris DNSKEY. Bila 38696 tidak ada, jalankan unbound-anchor sesuai lokasi file di konfigurasimu, lalu restart unbound.

Untuk BIND dengan dnssec-validation auto, lihat status kunci yang dikelola:

rndc managed-keys status

Pastikan keyid 38696 tercantum dan dipercaya. Bila konfigurasi memakai trust-anchors dengan static-key yang ditulis manual, tambahkan kunci KSK-2024 dari file trust anchor resmi IANA, atau beralih ke pembaruan otomatis sesuai dokumentasi versi BIND-mu.

Langkah 4: Perbarui paket resolver

Versi baru unbound dan BIND menyertakan KSK-2024 sebagai kunci bawaan. Memperbarui paket dari repositori resmi distro adalah cara paling aman, terutama untuk server yang dibangun ulang dari image lama.

Langkah 5: Pastikan validasi tetap bekerja

Setelah perubahan, uji lagi. Domain dengan DNSSEC yang sengaja dirusak, misalnya dnssec-failed.org, seharusnya menghasilkan SERVFAIL di resolver yang memvalidasi:

dig @127.0.0.1 dnssec-failed.org A

Bila hasilnya SERVFAIL sementara domain normal tetap ter-resolve dengan flag ad, validasimu sehat.

Apa yang terjadi berikutnya?

Menurut ICANN, KSK lama dijadwalkan dicabut (revoke) pada Januari 2027. Cloudflare menambahkan bahwa ICANN berencana menghapus KSK-2017 dari root zone dan memusnahkan kunci privatnya pada 2027. Untuk resolver yang sudah memercayai 38696, tahap ini seharusnya tidak berdampak. Jadwal tahap berikutnya bisa dipantau di halaman berkas DNSSEC IANA.

Checklist singkat untuk admin server:

• Cek apakah resolver lokal memvalidasi DNSSEC (flag ad).
• Uji nama sentinel 38696 ke resolver lokal.
• Pastikan key tag 38696 ada di trust anchor unbound atau BIND.
• Perbarui paket resolver, terutama di server dari image lama.
• Uji dnssec-failed.org untuk memastikan validasi tetap aktif.