--- title: "Kunci DNSSEC Root Sudah Berganti, Cek Resolver Server" description: "Root zone DNS kini ditandatangani KSK-2024 sejak 11 Oktober 2026. Ini cara memastikan resolver unbound atau BIND di servermu sudah memakai kunci baru." url: "https://nivelva.com/insight/rollover-ksk-root-dnssec-selesai" category: "Website \u0026 Domain" tags: ["dnssec","ksk","resolver","unbound","bind","dns"] author: "Aisyah Aris" published: "2026-11-12T16:05:00+07:00" updated: "2026-11-12T16:05:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Kunci DNSSEC Root Sudah Berganti, Cek Resolver Server > **Jawaban singkat:** Sejak 11 Oktober 2026 root zone DNS ditandatangani KSK-2024 dengan key tag 38696. Pengguna resolver publik umumnya tidak perlu berbuat apa-apa, tapi server yang menjalankan resolver validasi DNSSEC sendiri perlu memastikan kunci 38696 sudah ada di trust anchor-nya. 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](https://nivelva.com/insight/dnssec-perlu-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? | Kondisi server | Perlu tindakan? | |:--|:--| | Memakai resolver publik (misalnya 1.1.1.1) atau resolver penyedia | Umumnya tidak | | Menjalankan unbound atau BIND dengan trust anchor otomatis yang berjalan sejak 2025 | Cek saja, kemungkinan besar sudah aman | | Memakai trust anchor statis yang ditulis manual di konfigurasi | Ya, perbarui | | Server baru dari image atau cadangan lama dengan file trust anchor lama | Ya, perbarui | | Resolver yang lama mati lalu dinyalakan lagi | Ya, cek | 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. ```bash 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](https://nivelva.com/insight/cara-cek-record-dns-domain-dig-nslookup). ### Langkah 2: Uji dengan nama sentinel Cloudflare menyediakan nama uji berbasis mekanisme root key sentinel. Arahkan ke resolver lokalmu: ```bash 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: ```bash 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: ```bash 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: ```bash dig @127.0.0.1 dnssec-failed.org A ``` Bila hasilnya `SERVFAIL` sementara domain normal tetap ter-resolve dengan flag `ad`, validasimu sehat. > **Jangan matikan validasi sebagai jalan pintas:** > > Kalau resolver tiba-tiba gagal me-resolve semua domain, mematikan DNSSEC memang membuat layanan hidup lagi, tapi juga menghapus perlindungannya. Perbaiki trust anchor, lalu aktifkan validasi kembali. ## 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. ## Pertanyaan yang sering diajukan ### Apakah website saya terdampak pergantian KSK root? Untuk pemilik website, biasanya tidak. Yang terdampak adalah resolver yang memvalidasi DNSSEC dan belum memercayai kunci baru. Pengunjung yang memakai resolver seperti itu bisa gagal membuka domain apa pun, bukan hanya domainmu. ### Domain saya belum memakai DNSSEC, perlu cek? Status DNSSEC domainmu tidak berpengaruh. Yang perlu dicek adalah resolver di server bila resolver itu memvalidasi DNSSEC. ### Bagaimana tahu server saya memakai resolver lokal? Lihat isi `/etc/resolv.conf`. Bila tertulis `127.0.0.1` atau alamat lokal lain, cek layanan resolver yang berjalan di server, misalnya unbound, BIND, atau systemd-resolved. ### Apa key tag KSK yang baru? KSK-2024 memakai key tag 38696. Key tag KSK lama yang digantikan adalah 20326. ### Ke mana melaporkan masalah terkait rollover? Halaman pusat informasi KSK rollover ICANN menyediakan alamat email pelaporan dengan subjek "KSK Rollover". 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. ## Sumber - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/rollover-ksk-root-dnssec-selesai Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com