DNSSEC

Keamanan Siber / 24 Sep 2026 / 5 min read

SSHFP Mengikat Fingerprint Host Key SSH ke DNSSEC

Klien SSH harus menentukan apakah host key yang diberikan server memang milik host yang dituju. Key yang sudah tersimpan dapat menjadi referensi pada koneksi berikutnya, tetapi koneksi pertama memerlukan dasar autentikasi lain. SSHFP menempatkan fingerprint public host key SSH di DNS agar klien dapat membandingkan key dari server dengan data yang diperoleh melalui jalur terpisah. Record DNS itu sendiri bukan trust anchor. RFC 4255 mengaitkan verifikasi SSHFP tepercaya dengan data DNS yang terautentikasi. DNSSEC melindungi jalur lookup dan memungkinkan klien pemvalidasi membedakan data bertanda tangan dari jawaban DNS yang tidak terautentikasi. Properti keamanan yang berguna berasal dari kombinasi tersebut: SSH menyediakan host key, SSHFP membawa fingerprint-nya, dan DNSSEC mengautentikasi record DNS yang dipakai untuk perbandingan.

Keamanan Siber SSH

Keamanan Siber / 24 Sep 2026 / 5 min read

NSEC3 Menghash Record Penyangkalan DNSSEC Tanpa Menyembunyikan Nama yang Mudah Ditebak

Tanda tangan DNSSEC dapat mengautentikasi data yang ada, tetapi resolver juga memerlukan bukti kriptografis ketika nama atau tipe record yang diminta tidak ada. Respons NXDOMAIN tanpa tanda tangan tidak dapat memberikan properti tersebut: penyerang yang mampu mengubah lalu lintas DNS dapat membuat respons serupa. NSEC3 menyediakan record penyangkalan bertanda tangan sambil mengganti owner name teks biasa dalam rantai penyangkalan dengan hash. RFC 5155 mendefinisikan NSEC3 sebagai alternatif NSEC untuk authenticated denial of existence. Perbedaan utamanya terkait privasi cukup sempit tetapi berguna: penelusuran rantai NSEC secara langsung mengungkap owner name yang berdekatan, sedangkan NSEC3 mengekspos hash yang memerlukan pekerjaan tambahan untuk dipetakan kembali ke nama kandidat.

Keamanan Siber DNSSEC

Keamanan Siber / 24 Sep 2026 / 5 min read

DANE TLSA Mengikat Kunci TLS ke DNSSEC

TLS biasanya mengautentikasi server melalui rantai sertifikat yang berakhir pada trust anchor yang sudah diterima klien. DANE menambahkan jalur lain: domain dapat menerbitkan record TLSA di DNS dan melindunginya dengan DNSSEC. Klien yang mendukung DANE kemudian dapat mencocokkan material sertifikat dari TLS handshake dengan asosiasi yang diterbitkan domain. RFC 6698 mendefinisikan resource record TLSA. RFC 7671 memperbarui aturan operasional dan mempersempit beberapa pilihan deployment. Properti keamanannya spesifik: hanya data TLSA yang tervalidasi DNSSEC yang layak digunakan untuk autentikasi DANE. RRset TLSA berstatus insecure atau indeterminate tidak menyediakan binding DNS terautentikasi yang dibutuhkan DANE.

Cybersecurity DANE

Keamanan Siber / 24 Sep 2026 / 6 min read

DANE TLSA Mengikat Kredensial TLS ke DNSSEC

Sertifikat TLS biasanya sampai ke klien melalui TLS handshake, lalu klien memutuskan apakah sertifikat itu dapat dipercaya berdasarkan kebijakan autentikasi yang dikonfigurasi. DNS-Based Authentication of Named Entities, atau DANE, menambahkan input terautentikasi yang terpisah: record TLSA yang dilindungi DNSSEC dapat menyatakan material sertifikat atau public key yang dapat diterima untuk endpoint layanan tertentu. Mekanisme ini bukan nama pengganti untuk TLS. TLS tetap menyediakan handshake, key agreement, enkripsi, dan perlindungan record. DANE menyediakan data autentikasi yang dapat diterapkan klien saat mengevaluasi kredensial server.

Keamanan Siber DANE

Keamanan Siber / 24 Sep 2026 / 6 min read

CDS dan CDNSKEY Mengotomatiskan Pembaruan Trust Delegasi DNSSEC

Child zone yang ditandatangani DNSSEC dapat merotasi signing key tanpa langsung mengubah delegasi, tetapi validator pada akhirnya bergantung pada record set DS yang dipublikasikan parent. State di sisi parent ini menciptakan titik serah operasional: key baru di child tidak otomatis menjadi anchor delegasi aman hanya karena key tersebut sudah dipublikasikan oleh child. CDS dan CDNSKEY menyediakan mekanisme in-band untuk titik serah tersebut. RFC 7344 menetapkan record yang dapat dipublikasikan child pada apex zone untuk memberi sinyal parameter DS yang diusulkan. Parental agent dapat mengambil sinyal itu, memvalidasinya berdasarkan aturan yang berlaku, menerapkan kebijakan penerimaan lokal, lalu memperbarui set DS di sisi parent.

Cybersecurity DNSSEC

Keamanan Siber / 23 Sep 2026 / 4 min read

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC

SSHFP Mempublikasikan Fingerprint Host Key SSH melalui DNSSEC Client SSH memerlukan dasar tepercaya untuk menentukan apakah host key server benar-benar milik host yang dituju. Entri lokal known_hosts menyediakan dasar tersebut setelah sebuah key diterima, tetapi koneksi pertama tetap memerlukan jalur verifikasi jika key belum diprovisikan sebelumnya. SSHFP menempatkan fingerprint host key di DNS. RFC 4255 mendefinisikan resource record SSHFP agar client dapat membandingkan public key yang disajikan server SSH dengan fingerprint yang dipublikasikan untuk hostname tersebut. Properti keamanannya bergantung pada data DNS yang terautentikasi: fingerprint yang cocok dari jawaban DNS tanpa autentikasi tidak memenuhi kondisi trust yang ditetapkan untuk verifikasi SSHFP yang aman.

Cybersecurity SSH

Keamanan Siber / 23 Sep 2026 / 6 min read

NSEC3 Opt-Out Menukar Cakupan Bukti demi Skala Delegasi

DNSSEC memerlukan jawaban kriptografis bukan hanya saat data tersedia, tetapi juga saat nama atau record yang diminta tidak ada. NSEC3 menyediakan negative proof tersebut melalui rantai hashed owner name. Pada zona yang didominasi delegasi menuju child zone tanpa tanda tangan, merepresentasikan setiap delegasi tidak aman di dalam rantai dapat menambah pekerjaan pemeliharaan secara signifikan. NSEC3 Opt-Out mengubah kompromi tersebut. Sebuah Opt-Out span dapat mencakup delegasi tidak aman tanpa memberikan NSEC3 record tersendiri kepada setiap delegasi. Hasilnya dapat mengurangi pembaruan NSEC3 chain pada zona besar yang sarat delegasi, tetapi nama yang dihilangkan tidak lagi memperoleh pernyataan terautentikasi yang sama mengenai keberadaan atau ketidakberadaannya.

Cybersecurity DNSSEC

Keamanan Siber / 23 Sep 2026 / 4 min read

DANE untuk SMTP Mengikat Autentikasi TLS ke DNSSEC

SMTP umumnya memulai koneksi dalam plaintext lalu meningkatkannya dengan STARTTLS. Opportunistic TLS meningkatkan kerahasiaan ketika kedua sisi mendukungnya, tetapi upgrade tanpa autentikasi dapat ditekan atau dialihkan oleh penyerang aktif di jaringan. DANE untuk SMTP, yang ditetapkan dalam RFC 7672, menambahkan jalur autentikasi yang berakar pada DNSSEC. MTA pengirim tidak menganggap setiap respons TLSA sebagai otoritatif. Pengirim terlebih dahulu memerlukan hasil DNSSEC-secure untuk data tujuan yang mengarahkan pengiriman. Ketika record TLSA yang dapat digunakan diperoleh secara aman untuk host MX terpilih, record tersebut membatasi kredensial server TLS yang dapat diterima pengirim.

Cybersecurity DANE

Keamanan Siber / 23 Sep 2026 / 4 min read

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC

DANE TLSA Mengikat Key Layanan TLS melalui DNSSEC TLS biasanya mengautentikasi server melalui aturan validasi sertifikat yang ditetapkan aplikasi dan trust model-nya. DANE menambahkan binding berbasis DNS: resource record TLSA mengasosiasikan endpoint layanan dengan material sertifikat atau public key, sedangkan DNSSEC menyediakan data DNS terautentikasi untuk asosiasi tersebut. Batasnya tegas. RRset TLSA yang berstatus insecure atau memiliki status DNSSEC indeterminate tidak dapat menjadi asosiasi DANE terautentikasi. Karena itu, DANE bergantung pada validasi DNSSEC dan tidak menganggap transport DNS biasa sebagai bukti yang memadai.

Cybersecurity DANE

Keamanan Siber / 23 Sep 2026 / 5 min read

Caching DNSSEC Agresif Memakai Ulang Bukti Penyangkalan Terautentikasi

Negative cache DNS konvensional mengingat hasil negatif untuk query tertentu. DNSSEC menambahkan materi yang lebih kaya pada response tersebut: record NSEC dan NSEC3 dapat membuktikan secara kriptografis bahwa nama atau tipe record tidak ada. RFC 8198 mengizinkan resolver yang melakukan validasi untuk memakai ulang bukti tersebut bagi query berikutnya yang berada di dalam ruang yang telah dibuktikan. Perilaku ini disebut aggressive use of the DNSSEC-validated cache. Resolver dapat menahan lookup authoritative berulang untuk nama yang ketiadaannya sudah ditetapkan oleh data tervalidasi. Mekanisme ini bukan sekadar optimasi performa: berkurangnya query yang tidak perlu juga mengurangi penyebaran nama salah ketik atau nama acak melewati recursive resolver dan dapat menyerap sebagian beban dari traffic random-QNAME.

Cybersecurity DNS

Keamanan Siber / 22 Sep 2026 / 6 min read

DNSSEC Mengautentikasi Data DNS dengan Rantai Bertanda Tangan

DNSSEC Mengautentikasi Data DNS dengan Rantai Bertanda Tangan DNS pada dasarnya menjawab pertanyaan penamaan: record apa yang terkait dengan sebuah domain? Jalur respons dasar protokol tidak dengan sendirinya memberi resolver pemvalidasi bukti kriptografis bahwa kumpulan record yang diterima merupakan data yang diotorisasi pemilik zone. DNS Security Extensions, atau DNSSEC, menambahkan bukti tersebut. Zone yang ditandatangani memublikasikan public key dan signature yang memungkinkan resolver pemvalidasi mengautentikasi data DNS melalui rantai yang berakar pada trust anchor terkonfigurasi. DNSSEC melindungi autentisitas dan integritas data DNS. Mekanisme ini tidak mengenkripsi query atau response, serta tidak menyembunyikan nama yang diminta.

Keamanan Siber DNS

Keamanan Siber / 21 Sep 2026 / 5 min read

Record DS DNSSEC Menghubungkan Trust Parent dan Child

Record DS DNSSEC Menghubungkan Trust Parent dan Child DNSSEC menandatangani data DNS, tetapi signature hanya berguna bagi validator ketika signing key dapat dihubungkan ke titik awal yang dipercaya. Hubungan itu harus melintasi batas zona. Resolver yang memvalidasi data di bawah sebuah delegasi tidak dapat menganggap DNSKEY milik zona child autentik hanya karena key tersebut dipublikasikan oleh child. Resource record DS menyediakan penghubung tersebut. Record ini merupakan data otoritatif di zona parent dan mengidentifikasi material DNSKEY di child yang didelegasikan. Setelah sisi parent terautentikasi, DS yang cocok dapat mengautentikasi child key terkait sehingga validasi dapat berlanjut ke zona child.

Cybersecurity DNSSEC

Keamanan Siber / 21 Sep 2026 / 7 min read

DNSSEC Memvalidasi Data DNS melalui Delegasi Bertanda Tangan

DNSSEC Memvalidasi Data DNS melalui Delegasi Bertanda Tangan DNS pada dasarnya menjawab pertanyaan tentang nama dan resource record tanpa bukti kriptografis bahwa data yang dikembalikan benar-benar berasal dari operator zone. DNS Security Extensions (DNSSEC) menambahkan signature dan rantai delegasi yang dapat diperiksa resolver validator sebelum data DNS bertanda tangan diperlakukan sebagai autentik. Proteksinya memiliki batas yang jelas. DNSSEC menyediakan autentikasi asal data dan integritas untuk data DNS. Mekanisme ini tidak mengenkripsi query atau response, menyembunyikan nama yang ditanyakan, atau mengautentikasi aplikasi yang dicapai setelah resolusi. Record A bertanda tangan yang valid dapat membuktikan bahwa record tersebut autentik dalam rantai DNSSEC; hal itu tidak membuktikan bahwa server pada alamat tersebut aman.

Keamanan Siber DNS

Keamanan Siber / 16 Sep 2026 / 7 min read

Proof Penyangkalan DNSSEC Memungkinkan Resolver Mensintesis Jawaban Negatif

Proof Penyangkalan DNSSEC Memungkinkan Resolver Mensintesis Jawaban Negatif Recursive resolver menerima query untuk random subdomain di bawah signed zone dan sudah memiliki validated denial record dari lookup sebelumnya. Label yang ditanyakan tidak pernah dikirim ke authoritative server, tetapi resolver tetap dapat mengembalikan authenticated negative result. Jawaban itu bukan tebakan dan bukan exact-match negative caching biasa. Jawaban tersebut diturunkan dari cryptographic evidence yang mencakup sebagian DNS namespace. Perilaku ini merupakan efek operasional aggressive use of DNSSEC-validated cache, yang distandardisasi dalam RFC 8198 dan disempurnakan oleh RFC 9077. Record NSEC dan NSEC3 tidak hanya membuktikan satu queried name tidak ada. Dalam aturan validasi DNSSEC yang berlaku, record tersebut dapat membuktikan ketiadaan di sepanjang sebuah rentang. Validating resolver dapat menyimpan evidence itu dan menerapkannya pada query berikutnya selama proof tersebut masih dapat digunakan.

Keamanan Siber DNS