Setiap kali Anda mengetik nama domain di browser, ada proses penerjemahan yang berlangsung di belakang layar. Nama yang mudah diingat itu diubah menjadi alamat IP yang sebenarnya dipakai komputer untuk saling terhubung. Proses ini ditangani oleh DNS, sistem yang dirancang pada awal 1980-an dengan satu prioritas utama: kecepatan. Setiap kueri harus dijawab secepat mungkin, dan karena itu DNS memakai protokol yang ringan namun tidak memverifikasi siapa pengirim jawabannya.
Konsekuensinya, resolver yang menerima jawaban DNS tidak punya cara membuktikan bahwa jawaban itu benar-benar berasal dari server yang berwenang. Selama format paketnya terlihat wajar, jawaban apa pun akan diterima dan disimpan di cache. Celah inilah yang ditutup oleh DNSSEC (Domain Name System Security Extensions, atau ekstensi keamanan untuk DNS). DNSSEC adalah lapisan verifikasi tambahan yang membuktikan bahwa jawaban DNS yang Anda terima memang berasal dari pemilik zona yang sah, dan tidak diubah di tengah jalan.
Artikel ini menjelaskan cara kerja DNSSEC dari dasar, apa yang benar-benar dilindunginya, dan yang lebih praktis: bagaimana Anda memastikan sendiri apakah sebuah domain sudah terlindungi dengan benar.
DNSSEC Adalah Lapisan Verifikasi di Atas DNS
DNSSEC adalah kumpulan spesifikasi tambahan pada DNS yang distandarkan lewat RFC 4033 pada Maret 2005. Tujuannya satu: memberi resolver cara memverifikasi bahwa jawaban DNS yang diterimanya asli dan utuh, memakai tanda tangan kriptografi, bukan tebakan atau kepercayaan buta terhadap jaringan yang dilaluinya.
Penting dipahami sejak awal, DNSSEC bukan produk atau layanan tunggal yang dinyalakan di satu tempat. Ia adalah protokol yang bekerja lewat empat jenis data baru yang ditambahkan ke DNS — akan dijelaskan lengkap di bagian cara kerja — dan baru berfungsi penuh kalau dua pihak sama-sama menjalankan perannya masing-masing.
Masalah yang Diperbaiki DNSSEC
Bayangkan skenario berikut. Anda mengetik alamat toko online langganan Anda, dan resolver DNS yang Anda pakai mengirim kueri ke server yang berwenang untuk mencari alamat IP-nya. Jawaban dikirim kembali lewat UDP, protokol yang cepat tapi tanpa mekanisme otentikasi bawaan. Selama penyerang bisa menebak nomor identifikasi kueri dan mengirim jawaban palsu lebih dulu sebelum jawaban asli tiba, resolver akan menerima dan menyimpan jawaban palsu itu di cache.
Serangan ini disebut cache poisoning (peracunan cache). Begitu berhasil, setiap pengunjung yang memakai resolver tersebut akan diarahkan ke server milik penyerang meski mereka mengetik alamat yang benar-benar sah. Ini bukan sekadar salah ketik atau website yang lambat — ini pemalsuan identitas di lapisan yang paling mendasar, sebanding dengan pemalsuan pengirim email yang mengelabui penerima seolah pesan datang dari pihak resmi.
DNSSEC memutus jalur serangan ini dengan cara sederhana tapi tegas: setiap jawaban DNS dari zona yang sudah menandatangani datanya bisa diverifikasi keasliannya. Kalau tanda tangannya tidak cocok, resolver menolak jawaban itu daripada menyimpannya di cache.
Cara Kerja DNSSEC: Tanda Tangan Digital dan Rantai Kepercayaan
Inti DNSSEC adalah tanda tangan digital — mekanisme kriptografi yang membuktikan sebuah data dibuat oleh pemegang kunci privat tertentu, dan tidak berubah sejak ditandatangani. Pemilik zona DNS menandatangani setiap kumpulan record miliknya, lalu menyimpan tanda tangan itu sebagai record baru bernama RRSIG. Kunci publik yang dipakai memverifikasi tanda tangan tersebut diumumkan lewat record DNSKEY, sehingga siapa pun bisa mengeceknya tanpa perlu mengenal pemilik zona secara langsung.
Pertanyaannya kemudian, bagaimana resolver tahu kunci publik itu sendiri bisa dipercaya? Di sinilah DS (Delegation Signer) berperan. Sidik jari dari kunci penandatangan sebuah zona dititipkan ke zona induknya, lalu zona induk ikut menandatangani DS tersebut sebagai bagian dari datanya sendiri. Rantai kepercayaan ini berlanjut naik tingkat demi tingkat sampai ke root zone — titik tertinggi DNS yang kuncinya, disebut trust anchor, sudah tertanam langsung di software resolver.
Dalam praktiknya, sebuah zona biasanya memakai dua jenis kunci dengan peran berbeda. Key Signing Key (KSK) menandatangani kunci-kunci lain di zona itu sendiri dan dititipkan ke zona induk lewat DS, sehingga sebaiknya jarang berganti. Zone Signing Key (ZSK) menandatangani record sehari-hari seperti A dan MX, dan boleh dirotasi lebih sering karena perubahannya tidak perlu diberitahukan ke zona induk. Pemisahan ini membuat rotasi kunci rutin tidak memaksa Anda memperbarui DS di registrar setiap kali.
Rantai ini bisa dilihat langsung untuk domain berakhiran .id:
$ dig @a.root-servers.net DS id.
id. 86400 IN DS 26887 8 2 28BE22003A1AFB1ED9A7BB82482274E2DB5F09A6C50702C731E040D2257347EA
$ dig DS co.id.
co.id. 13300 IN DS 50154 10 2 AF71E90EC51D8ED2B8C0AD3D3BFAE055090C812CED242572C9AB46BE44D93EABRoot zone menandatangani DS milik id., dan id. menandatangani DS milik co.id.. Setiap domain di bawah co.id. yang mengaktifkan DNSSEC menyambung rantai ini satu tingkat lagi.
Diagram rantai kepercayaan DNSSEC: root menandatangani DS id., id. menandatangani DS co.id., hingga ke domain Anda.
Yang Tidak Dilakukan DNSSEC
Nama "ekstensi keamanan" sering membuat orang salah sangka DNSSEC melakukan lebih dari yang sebenarnya. RFC 4033 sendiri menegaskan batasannya secara eksplisit:
- Bukan enkripsi: DNSSEC membuktikan keaslian jawaban, bukan menyembunyikan isinya. Siapa pun yang menyadap lalu lintas jaringan tetap bisa membaca kueri dan jawaban DNS Anda apa adanya. Kalau tujuan Anda menyembunyikan aktivitas browsing dari penyedia internet, itu ranah enkripsi lewat DNS over HTTPS (DoH) atau DNS over TLS (DoT). Keduanya teknologi berbeda yang menjawab pertanyaan berbeda dari DNSSEC, dan bisa dipakai berdampingan.
- Bukan pelindung isi website: DNSSEC memastikan Anda terhubung ke server yang benar. Setelah koneksi terbentuk, keamanan data yang dipertukarkan adalah tugas HTTPS dan sertifikat SSL yang dipasang di server tersebut. Domain yang sudah menandatangani DNSSEC tapi belum memasang SSL tetap mengirim data dalam bentuk polos begitu koneksi terjalin.
- Bukan pelindung dari serangan DoS: RFC 4033 menyatakan tegas bahwa DNSSEC tidak dirancang untuk melindungi dari serangan denial of service. Bahkan, seperti dijelaskan di bagian kekurangan, ukuran respons yang lebih besar berpotensi disalahgunakan sebagai bagian dari serangan amplifikasi.
- Tidak menyaring atau membedakan pengunjung: standar ini secara harfiah menyebutkan DNSSEC tidak menyediakan kontrol akses atau cara membedakan satu penanya dari penanya lain.
- Tidak memakai port atau protokol sendiri: DNSSEC menumpang penuh pada port 53 yang sudah dipakai DNS biasa. Yang berubah hanya satu bit bernama DO (DNSSEC OK) di header EDNS0 — resolver menyalakan bit ini untuk memberi tahu server bahwa ia siap menerima data DNSSEC tambahan seperti RRSIG.
Dua Pekerjaan yang Sering Tertukar: Menandatangani dan Memvalidasi
Bagian yang paling sering luput dari penjelasan DNSSEC: ada dua pekerjaan terpisah yang harus berjalan bersamaan agar perlindungan ini benar-benar terasa. Pemilik domain menandatangani zonanya di sisi server. Resolver yang dipakai pengunjung memvalidasi tanda tangan itu di sisi klien. Menandatangani domain tanpa ada yang memvalidasi sama saja dengan mengirim surat tersegel ke penerima yang tidak pernah memeriksa segelnya.
Kabar baiknya, sebagian besar resolver publik populer — termasuk yang biasa disebut pengguna sebagai "DNS 8.8.8.8" — sudah menjadi validating resolver secara bawaan. Artinya, begitu Anda menandatangani domain, pengunjung yang memakai resolver semacam itu otomatis terlindungi tanpa perlu melakukan apa pun di sisi mereka.
Berdasarkan data APNIC Labs untuk rentang 15 Juli hingga 13 Agustus 2026, dari sampel lebih dari 31 juta pengukuran, 41,99% pengguna internet Indonesia berada di belakang resolver yang memvalidasi DNSSEC secara penuh. Sebanyak 8,39% lagi memvalidasi sebagian. Angka ini sedikit di atas rata-rata dunia (39,71%), tapi jauh tertinggal dari tetangga seperti Malaysia (80,71%) dan Filipina (93,87%). Praktisnya, kalau Anda menandatangani domain hari ini, sekitar empat dari sepuluh pengunjung Indonesia langsung mendapat manfaatnya tanpa melakukan apa pun — dan angka itu terus bertambah seiring resolver publik makin banyak dipakai.
Cara Mengecek Status DNSSEC Sebuah Domain
Menandatangani zona hanyalah separuh pekerjaan. Anda perlu memastikan tanda tangan itu benar-benar valid dan bisa diverifikasi, bukan sekadar terpasang. Ada dua cara melakukannya.
Cara pertama, menguji langsung lewat terminal dengan dig +dnssec. Perintah ini meminta server mengembalikan data DNSSEC bersamaan dengan jawaban biasa. Berikut hasilnya untuk domain yang sudah bertanda tangan dengan benar:
Hasil pengecekan status DNSSEC: tanda centang hijau berarti tervalidasi, tanda seru merah berarti gagal divalidasi.
$ dig +dnssec cloudflare.com A
;; flags: qr rd ra ad;
cloudflare.com. 300 IN RRSIG A 13 2 300 20260816231836 20260814211836 34505 cloudflare.com. ...Dua penanda yang perlu Anda cari: flag ad (authenticated data) di baris flags, dan kemunculan record RRSIG di jawaban. Kalau kedua penanda itu ada, resolver Anda berhasil memvalidasi tanda tangan zona tersebut. Bandingkan dengan domain yang belum menandatangani zonanya — flag ad tidak muncul dan tidak ada satu pun RRSIG di jawabannya, karena memang tidak ada tanda tangan yang perlu diverifikasi.
Kalau Anda memakai Windows dan lebih terbiasa dengan nslookup, alat itu tetap bisa dipakai untuk melihat record dasar meski penjelasan lebih lengkap soal batasannya ada di artikel nslookup.
Cara kedua, lewat DNSSEC checker berbasis web — situs pemeriksa daring yang menjalankan pengujian yang sama tanpa Anda perlu membuka terminal sama sekali. DNSViz menampilkan seluruh rantai kepercayaan secara visual, cocok untuk melihat di mana tepatnya rantai terputus kalau ada masalah. Verisign DNSSEC Analyzer memberi laporan tekstual yang lebih ringkas untuk pengecekan cepat.
Catatan untuk pengguna macOS: perintah
delv, yang sering direkomendasikan sebagai penerusdiguntuk validasi DNSSEC, tidak berfungsi pada instalasi bawaan macOS karena kekurangan dukungan kriptografi. Pakaidig +dnssecatau pemeriksa web sebagai gantinya.
Membaca Hasilnya: Secure, Insecure, Bogus, dan Indeterminate
RFC 4033 mendefinisikan empat status yang bisa disimpulkan resolver setelah mencoba memvalidasi sebuah jawaban. Memahami keempatnya membantu Anda membedakan keadaan yang wajar dari keadaan darurat.
- Secure: resolver punya trust anchor, rantai kepercayaan lengkap, dan seluruh tanda tangan terverifikasi. Ini keadaan ideal — domain bertanda tangan dan semuanya cocok.
- Insecure: resolver punya rantai kepercayaan sampai ke titik tertentu, tapi menemukan bukti bertanda tangan bahwa zona di bawahnya memang sengaja tidak diamankan dengan DNSSEC. Ini bukan kegagalan — banyak domain memang belum menandatangani zonanya, dan itu keadaan normal untuk mereka.
- Bogus: resolver punya rantai kepercayaan sampai ke zona yang seharusnya bertanda tangan, tapi validasinya gagal. Inilah keadaan darurat sesungguhnya — ada yang tidak beres, baik karena kesalahan konfigurasi maupun karena ada pihak yang mencoba memalsukan jawaban.
- Indeterminate: resolver tidak punya trust anchor sama sekali untuk bagian pohon DNS tersebut, sehingga tidak bisa menyimpulkan apa-apa.
Saat status bogus terjadi, resolver yang memvalidasi akan menolak menjawab sama sekali dan mengembalikan SERVFAIL, lengkap dengan pesan Extended DNS Error yang menyebutkan alasannya secara harfiah:
$ dig dnssec-failed.org A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; OPT=15: 00 09 4e 6f 20 44 4e 53 4b 45 59 20 6d 61 74 63 68 65 73 ... ("No DNSKEY matches DS RRs of dnssec-failed.org")Masalahnya, dari sudut pandang pengunjung biasa, SERVFAIL terlihat sama persis dengan "domain tidak bisa diakses" karena sebab lain — server mati, salah konfigurasi nameserver, atau memang domainnya tidak terdaftar. Untuk memastikan penyebabnya benar-benar DNSSEC, tambahkan flag +cd (checking disabled) yang mematikan validasi di sisi resolver:
$ dig +cd dnssec-failed.org A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
dnssec-failed.org. 218 IN A 96.99.227.255Kalau jawaban muncul normal dengan +cd tapi berubah menjadi SERVFAIL begitu +cd dilepas, kesimpulannya pasti: penyebabnya DNSSEC yang gagal divalidasi, bukan server yang benar-benar mati. Diagnosa satu baris ini menghemat waktu Anda dibandingkan menebak-nebak lewat proses eliminasi.
Kelemahan dan Hal yang Perlu Anda Pertimbangkan
DNSSEC bukan tanpa konsekuensi. Empat hal berikut perlu Anda pertimbangkan sebelum mengaktifkannya.
- Ukuran respons membengkak: menambahkan RRSIG membuat setiap jawaban DNS jauh lebih besar. Pengukuran langsung menunjukkan kueri
cloudflare.com Anaik dari 75 byte menjadi 185 byte dengan DNSSEC (2,5 kali lipat), dan kuerikominfo.go.id Anaik dari 88 byte menjadi 354 byte (4 kali lipat). Respons yang lebih besar berarti beban jaringan lebih tinggi, dan dalam kasus terburuk bisa disalahgunakan sebagai bagian dari serangan amplifikasi DDoS. - Struktur zona berpotensi bisa dijelajahi: mekanisme pembuktian "record ini tidak ada" pada DNSSEC generasi awal (NSEC) secara tidak sengaja membocorkan daftar lengkap nama di zona Anda. Siapa pun bisa memintanya secara berurutan untuk memetakan seluruh isi zona — dikenal sebagai zone walking. Generasi berikutnya (NSEC3) menyamarkan nama dengan hash, tapi panduan terbaru dari RFC 9276 justru menyarankan tanpa iterasi hash tambahan dan tanpa salt. Iterasi ekstra terbukti tidak banyak menambah keamanan, sementara membebani server secara komputasi.
- Bisa berhenti berfungsi tanpa ada yang mengubah apa pun: tanda tangan RRSIG punya masa berlaku, dan kunci penandatangan perlu dirotasi secara berkala. Domain yang menandatangani zonanya lalu dibiarkan tanpa pemantauan berisiko mengalami tanda tangan kedaluwarsa, yang membuat domain tersebut mendadak tidak bisa diakses oleh seluruh pengunjung yang resolvernya memvalidasi.
- Beban operasional tambahan: mengelola rotasi kunci, memantau masa berlaku tanda tangan, dan memastikan DS di registrar selalu sinkron dengan kunci di penyedia DNS membutuhkan proses yang disiplin. Sebagian situs berskala besar sengaja belum mengaktifkannya karena mempertimbangkan beban ini terhadap manfaat yang didapat.
Apakah Anda Perlu Mengaktifkan DNSSEC?
Jawabannya bergantung pada apa yang dipertaruhkan kalau pengunjung Anda diarahkan ke server yang salah. Tiga kondisi berikut membantu Anda memutuskan.
Aktifkan kalau domain Anda menangani transaksi, login, atau identitas — toko daring, layanan perbankan, portal instansi pemerintah, atau email berbasis domain sendiri. Beberapa domain perbankan dan instansi .id di Indonesia memang sudah menandatangani zonanya, sejalan dengan rantai kepercayaan .id yang aktif dan panduan aktivasi resmi yang diterbitkan pemerintah untuk domain instansi.
Pertimbangkan lebih matang kalau Anda sering berganti penyedia DNS atau belum punya proses pemantauan rutin. Seperti dijelaskan di bagian kekurangan dan bagian berikutnya soal pindah nameserver, DNSSEC yang dikelola tanpa kehati-hatian justru bisa mematikan domain Anda sendiri.
Untuk domain informasional murni tanpa transaksi atau data sensitif, manfaatnya lebih tipis dibanding beban operasionalnya — meski tetap tidak merugikan untuk diaktifkan kalau Anda sudah nyaman dengan prosesnya.
Cara Mengaktifkan DNSSEC
Panel setiap registrar dan penyedia DNS berbeda tampilan, tapi alurnya selalu mengikuti pola yang sama. Berikut langkah generik yang berlaku di sebagian besar penyedia.
Langkah #1: Pastikan TLD dan Penyedia DNS Anda Mendukungnya
Tidak semua ekstensi domain mendukung DNSSEC, meski mayoritas TLD besar termasuk .id sudah mendukungnya penuh. Pastikan juga penyedia DNS Anda — tempat zona Anda benar-benar dikelola — punya fitur penandatanganan DNSSEC.
Langkah #2: Nyalakan Penandatanganan di Penyedia DNS
Aktifkan DNSSEC di panel penyedia DNS Anda. Setelah dinyalakan, penyedia akan menghasilkan data DS (atau DNSKEY, tergantung format yang diminta registrar Anda) yang perlu Anda catat untuk langkah berikutnya.
Langkah #3: Pasang DS di Registrar
Ini langkah yang paling sering terlewat karena penandatanganan dan pemasangan DS kerap dilakukan di dua tempat berbeda. Masuk ke panel pengelolaan domain tempat Anda mendaftarkan domain, cari menu DNSSEC atau DS record, lalu tempelkan data dari langkah sebelumnya.
Langkah #4: Verifikasi
Jangan anggap selesai sebelum benar-benar diverifikasi. Jalankan dig +dnssec seperti dijelaskan sebelumnya dan pastikan flag ad serta record RRSIG muncul. Untuk deployment baru, algoritma yang direkomendasikan saat ini adalah ECDSAP256SHA256 — kalau penyedia DNS Anda memberi pilihan algoritma, ini pilihan yang lebih ringkas dan tetap kuat dibanding algoritma RSA yang lebih tua.
Ranjau Saat Pindah Nameserver atau Mematikan DNSSEC
Ini kegagalan yang paling mahal sekaligus paling jarang diperingatkan: mengganti nameserver atau penyedia DNS pada domain yang DNSSEC-nya aktif, tanpa urutan yang benar.
Masalahnya berakar dari cara kerja rantai kepercayaan itu sendiri. DS yang tersimpan di zona induk menunjuk ke kunci penandatangan di penyedia DNS lama Anda. Begitu Anda memindahkan nameserver ke penyedia baru tanpa melepas DS lama terlebih dahulu, zona Anda kini ditandatangani kunci yang berbeda dari yang ditunjuk DS. Hasilnya status bogus, dan domain Anda mengembalikan SERVFAIL ke setiap pengunjung yang resolvernya memvalidasi.
Urutan yang aman:
- Hapus DS record di registrar terlebih dahulu, sebelum menyentuh nameserver.
- Tunggu hingga TTL DS lama benar-benar kedaluwarsa. Untuk domain
.id, TTL DS di root adalah 86.400 detik (24 jam) — angka ini terukur langsung dari server root. Sebagai patokan umum, tunggu 24–48 jam. - Baru pindahkan nameserver ke penyedia baru.
- Aktifkan ulang DNSSEC di penyedia baru dan pasang DS barunya di registrar.
TTL yang membuat perubahan DNS tidak langsung terlihat inilah yang membuat urutan di atas begitu penting — kalau Anda ingin memahami mekanismenya lebih dalam, ini dibahas lengkap di artikel propagasi DNS. Kalau Anda hanya ingin mematikan DNSSEC sepenuhnya tanpa berpindah penyedia, cukup lakukan langkah 1 dan 2 saja.
DNSSEC di Indonesia dan Pergantian Kunci Root Oktober 2026
Dua perkembangan berikut relevan bagi siapa pun yang mengelola domain Indonesia saat ini.
Pertama, rantai kepercayaan untuk domain .id sudah aktif sepenuhnya. Zona id. dan co.id. sudah bertanda tangan di root, PANDI selaku pengelola registri menyediakan aktivasi DNSSEC langsung dari panel pengelolaan domain, dan pemerintah menerbitkan panduan aktivasi resmi khusus untuk domain instansi. Penghalangnya bukan lagi ketersediaan infrastruktur — DNSSEC untuk .id sudah siap dipakai kapan saja.
Kedua, kunci penandatangan root DNS sedang berganti. Kunci yang aktif sejak Oktober 2018 (KSK-2017, dengan key tag 20326) akan digantikan oleh kunci baru (KSK-2024, key tag 38696) pada 11 Oktober 2026. ICANN sudah menerbitkan panduan persiapan resminya. Anda bisa melihat sendiri bahwa kedua kunci ini sudah terpublikasi berdampingan di root saat ini:
$ dig DNSKEY .
. IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbz...
. IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc4...Bagi mayoritas pemilik domain, pergantian ini berjalan otomatis di belakang layar tanpa perlu tindakan apa pun, selama resolver yang mereka pakai mengikuti mekanisme pembaruan kunci standar. Yang perlu bertindak adalah pengelola resolver atau server DNS internal yang trust anchor-nya dikonfigurasi manual — mereka perlu memastikan kunci baru sudah tertanam sebelum tanggal peralihan.
Pertanyaan yang Sering Muncul
DNSSEC itu singkatan dari apa? Domain Name System Security Extensions, ekstensi keamanan untuk sistem penerjemah nama domain ke alamat IP.
Apakah DNSSEC membuat website saya lebih cepat atau justru lebih lambat? DNSSEC tidak memengaruhi kecepatan pemuatan website Anda. Yang berubah hanya ukuran respons DNS itu sendiri, yang bertambah dua hingga empat kali lipat — dampaknya nyaris tidak terasa dibanding waktu muat halaman secara keseluruhan.
Apakah DNSSEC menggantikan SSL atau HTTPS? Tidak. DNSSEC memastikan Anda terhubung ke server yang benar; SSL dan HTTPS mengamankan data yang dipertukarkan setelah koneksi terbentuk. Keduanya saling melengkapi, bukan saling menggantikan.
Apakah DNSSEC melindungi email saya? Secara tidak langsung, ya — DNSSEC membantu memastikan record MX dan mekanisme autentikasi email seperti DKIM tidak dipalsukan di level DNS. Namun DNSSEC bukan pengganti SPF, DKIM, atau DMARC yang memang dirancang khusus untuk keamanan email.
Apakah DNSSEC gratis?
Sebagian besar registrar dan penyedia DNS menyediakan DNSSEC tanpa biaya tambahan, termasuk untuk domain .id. Biaya yang sebenarnya bukan uang, melainkan waktu untuk memastikan konfigurasinya benar dan terpantau.
Bagaimana cara mematikan DNSSEC dengan aman? Hapus DS record di registrar terlebih dahulu, tunggu TTL-nya kedaluwarsa, baru matikan penandatanganan di penyedia DNS. Melakukannya dengan urutan terbalik berisiko membuat domain tidak bisa diakses sementara.
Kesimpulan
DNSSEC adalah lapisan verifikasi yang membuktikan jawaban DNS benar-benar berasal dari pemilik zona yang sah, bukan enkripsi dan bukan pengganti SSL. Perlindungan ini baru terasa penuh kalau dua pekerjaan berjalan bersamaan: pemilik domain menandatangani zonanya, dan resolver pengunjung memvalidasi tanda tangan itu — sesuatu yang sudah dilakukan sekitar separuh pengguna internet Indonesia tanpa mereka sadari.
Aktifkan DNSSEC kalau domain Anda menangani transaksi, login, atau identitas, dan pastikan Anda memahami urutan yang aman saat berpindah penyedia DNS agar tidak berujung domain yang mendadak tidak bisa diakses. Semoga artikel ini membantu.
