Pergantian kunci di root DNS jarang terjadi, tetapi dampaknya berada di titik paling awal rantai kepercayaan DNSSEC. Pada 11 Oktober 2026, KSK-2024 dijadwalkan mengambil alih penandatanganan DNSKEY root dari KSK-2017. Bagi kebanyakan pemilik website tidak ada perubahan yang perlu dilakukan. Fokus operasional ada pada operator recursive resolver yang melakukan DNSSEC validation: mereka perlu memastikan trust anchor baru sudah diterima sebelum switch. Analisis ini membahas apa yang berubah, cara membedakan masalah resolver dari authoritative DNS, dan verifikasi yang layak dilakukan tanpa membuat perubahan DNS yang tidak perlu.
ICANN dan IANA menjadwalkan KSK-2024 menjadi key yang menandatangani DNSKEY RRset root pada 11 Oktober 2026. Key baru memiliki key tag 38696 dan menggantikan KSK-2017 dengan key tag 20326 untuk tugas penandatanganan tersebut. Ini adalah root KSK rollover kedua setelah 2018. Keduanya menggunakan RSA/SHA-256, sehingga perubahan ini adalah pergantian key pair dan trust anchor, bukan migrasi algoritma.
DNSSEC membangun chain of trust dari root menuju TLD lalu domain. Root tidak memiliki parent, sehingga validating resolver memulai verifikasi dari root trust anchor yang sudah dipercaya. Jika resolver belum mempercayai KSK-2024 saat key baru mulai menandatangani DNSKEY root, validasi dapat gagal dan terlihat sebagai SERVFAIL walaupun authoritative server domain tetap menjawab normal. Jangan langsung mengubah NS, DS, atau record aplikasi hanya karena satu resolver kehilangan akses.
IANA menerbitkan successor key di root DNSKEY set sejak 11 Januari 2025. Resolver yang mengikuti RFC 5011 dapat mempelajari trust anchor baru secara otomatis melalui key lama yang sudah dipercaya dan hold-down period. Waktu persiapan panjang mengurangi risiko, tetapi operator tetap perlu memverifikasi hasilnya karena upgrade, pemindahan resolver, restore image lama, atau trust anchor manual dapat membuat state aktual berbeda dari asumsi.
Prioritas pemeriksaan adalah operator recursive resolver dengan DNSSEC validation, vendor resolver, dan lingkungan yang mengelola root trust anchor manual. ICANN meminta operator memastikan KSK-2024 key tag 38696 tersedia. Pemilik website yang hanya menggunakan authoritative DNS tidak otomatis perlu mengubah DNSSEC domain. Cloudflare menyatakan pengguna 1.1.1.1 dan Gateway DNS tidak perlu tindakan khusus karena resolver mereka sudah mempercayai KSK-2024.
RFC 8509 mendefinisikan trust-anchor sentinel untuk menanyakan apakah validating resolver mempercayai root key tertentu. Untuk KSK-2024 digunakan pasangan is-ta-38696 dan not-ta-38696. Pada resolver yang mendukung sentinel dan mempercayai key baru, is-ta diharapkan mendapat jawaban valid sedangkan not-ta sengaja menghasilkan SERVFAIL. Karena itu satu SERVFAIL tanpa kontrol pembanding dapat menghasilkan diagnosis terbalik.
Cloudflare mendokumentasikan pengujian sentinel terhadap 1.1.1.1. Contoh ini memeriksa resolver publik tersebut, bukan otomatis resolver kantor atau ISP. Untuk resolver internal, arahkan query ke resolver yang memang ingin diverifikasi dan ikuti dokumentasi vendor. Jika sentinel tidak didukung, hasilnya bisa inconclusive dan bukan bukti key hilang.
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answerTentukan scope terlebih dahulu. Bandingkan domain yang sama melalui resolver terdampak dan resolver validating lain. Periksa apakah kegagalan luas pada domain DNSSEC atau hanya satu zone. Lalu cek trust-anchor state dan log validator sesuai software. Jika KSK-2024 tidak ada, ikuti prosedur vendor untuk memperbarui trust anchor atau memperbaiki automatic update. Jika hanya satu domain gagal sementara domain signed lain normal, investigasi DS, DNSKEY, dan RRSIG domain lebih relevan daripada root KSK.
Pantau kenaikan SERVFAIL, DNSSEC validation errors, query latency, dan perbedaan hasil antar resolver. Catat resolver IP, timestamp, qname, qtype, response code, dan status DNSSEC chain. Untuk organisasi multisite, bandingkan resolver per lokasi karena trust-anchor state dapat berbeda. Kombinasikan telemetry resolver dengan query pembanding dan status authoritative DNS.
Browser dapat menggunakan Secure DNS, VPN, atau resolver berbeda dari sistem operasi. Readiness test browser menggambarkan resolver path browser saat itu, bukan seluruh infrastruktur organisasi. Sentinel juga memerlukan dukungan resolver; hasil inconclusive tidak sama dengan key hilang. Cache dan konfigurasi berbeda antar node dapat membuat hasil sementara tidak seragam.
Menonaktifkan validation dapat menghilangkan SERVFAIL tetapi juga menghapus autentikasi DNS. Jika masalah berasal dari trust anchor tertinggal, perbaiki state resolver mengikuti panduan vendor dan ICANN. Perubahan darurat harus punya owner, scope, batas waktu, dan rollback. Jangan mengubah DS domain, registrar, atau authoritative provider bila bukti menunjuk ke recursive resolver.
Rollover tidak selesai pada hari switch. ICANN merencanakan fase lanjutan pada 2027 untuk merevoke dan kemudian menghapus KSK-2017. Berhenti menggunakan key lama untuk signing dan menghapus trust terhadap key lama adalah tahap berbeda. Pertahankan monitoring dan ikuti timeline resmi.
Sebelum 11 Oktober, identifikasi recursive resolver yang melakukan DNSSEC validation, pastikan KSK-2024 key tag 38696 dipercaya, dan siapkan telemetry untuk membedakan kegagalan trust anchor dari masalah zone biasa. Rollover ini tidak meminta perubahan massal pada domain. Fokus pada verifikasi state, resolver yang tepat, interpretasi sentinel, dan diagnosis berbasis bukti.