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.

Signature diterapkan pada kumpulan record

DNSSEC menandatangani RRset: record dengan owner name, class, dan type yang sama. Record RRSIG terkait membawa digital signature beserta metadata yang diperlukan untuk validasi.

Jawaban bertanda tangan secara sederhana dapat digambarkan sebagai:

example.com.  A      192.0.2.10
example.com.  RRSIG  A ... signature ...

Resolver tidak menerima signature hanya karena record itu berada di samping jawaban. Resolver memperoleh DNSKEY yang relevan, memeriksa validitas signature untuk RRset, memeriksa waktu signature dan kondisi validasi terkait, lalu menetapkan apakah kunci tersebut berada dalam rantai tepercaya.

Signature yang valid membuktikan bahwa RRset sesuai dengan data yang ditandatangani private key terkait. Masalah berikutnya adalah menetapkan apakah public key tersebut memang berwenang untuk zone itu.

DNSKEY memublikasikan public key milik zone

Zone yang mengaktifkan DNSSEC mengekspos material public key melalui record DNSKEY. Pasangan private key tetap berada dalam kendali operator dan dipakai untuk membuat signature.

Secara konseptual:

private signing key -> menandatangani RRset
public DNSKEY        -> memverifikasi record RRSIG

Memiliki key pair yang valid secara matematis belum cukup untuk menetapkan kewenangan DNS. Penyerang juga dapat membuat kunci lain dan menandatangani record palsu. Karena itu, validasi memerlukan jalur tepercaya dari anchor yang sudah dikenal menuju kunci zone.

DS menghubungkan child zone dengan parent

Parent zone dapat memublikasikan record Delegation Signer (DS) untuk child yang didelegasikan. DS berisi digest yang diturunkan dari sebuah DNSKEY milik child, bersama identifier algoritma kunci dan digest.

Relasi tersebut membentuk tautan delegasi:

parent zone
  DS untuk child
      |
      v
child DNSKEY
  memverifikasi child RRSIG

Resolver pemvalidasi mengautentikasi RRset DS milik parent yang telah ditandatangani, mencocokkannya dengan DNSKEY child yang sesuai, lalu memakai material kunci child yang telah terautentikasi untuk memvalidasi data bertanda tangan dalam child zone.

Rantai ini dapat berulang pada beberapa tingkat delegasi. Setiap tahap bergantung pada zone sebelumnya yang sudah terautentikasi, bukan pada klaim terpisah yang dibuat child.

Root trust anchor memulai validasi

Rantai memerlukan titik awal yang dipercaya tanpa harus diautentikasi oleh delegasi DNS lain. Resolver pemvalidasi dikonfigurasi dengan DNS root trust anchor, yang umumnya direpresentasikan oleh material DNSKEY tertentu dari root zone.

Dari anchor tersebut, validasi dapat bergerak menuruni hierarki:

root trust anchor
  -> signed root data
  -> DS untuk TLD
  -> TLD DNSKEY
  -> DS untuk domain
  -> domain DNSKEY
  -> signed domain RRset

Pertukaran record secara tepat dapat berbeda akibat caching dan perilaku resolver, tetapi properti keamanannya tetap hierarkis: delegasi parent yang terautentikasi menetapkan relasi kunci yang diperlukan untuk zone berikutnya.

Pemeliharaan trust anchor karena itu penting secara operasional. Resolver dengan state anchor yang usang atau salah dapat gagal melakukan validasi walaupun authoritative zone sudah ditandatangani dengan benar.

Penolakan terautentikasi mencakup record yang tidak ada

Jawaban positif palsu bukan satu-satunya manipulasi DNS yang perlu dideteksi. Penyerang juga dapat mengklaim bahwa nama atau record type yang sebenarnya ada tidak tersedia.

DNSSEC menyediakan authenticated denial of existence melalui record NSEC atau NSEC3. Record ini ditandatangani sehingga resolver dapat memvalidasi response negatif, bukan memperlakukan ketiadaan tanpa signature sebagai bukti kriptografis.

NSEC mendeskripsikan interval dalam namespace yang terurut dan menunjukkan record type yang ada pada sebuah owner name. NSEC3 memakai owner name yang di-hash dan mengubah representasi authenticated denial. Keduanya tidak mengubah DNS menjadi direktori rahasia; fungsinya adalah membuat pernyataan negatif dapat diverifikasi.

Validasi memiliki hasil yang berbeda

Resolver pemvalidasi dapat mengklasifikasikan data DNSSEC ke dalam state yang lazim disebut secure, insecure, bogus, atau indeterminate, bergantung pada rantai yang tersedia dan hasil validasi.

Rantai bertanda tangan yang berhasil divalidasi mencapai hasil secure. Zone unsigned yang didelegasikan dengan benar dapat berstatus insecure, bukan bogus: parent yang terautentikasi menunjukkan bahwa rantai DNSSEC tidak berlanjut ke child tersebut. Data bogus menunjukkan bahwa validasi seharusnya terjadi tetapi gagal, misalnya saat signature yang diperlukan tidak dapat diverifikasi atau relasi delegasi tidak konsisten.

Perbedaan ini mencegah resolver memperlakukan setiap jawaban unsigned sebagai serangan, sambil tetap menolak data yang gagal melewati rantai bertanda tangan yang sudah terbentuk.

Key rollover harus mempertahankan jalur valid

Kunci DNSSEC memiliki siklus operasional. Operator dapat mengganti kunci karena kebijakan, transisi algoritma, atau pengelolaan rutin. Rollover tidak dapat diperlakukan sebagai penggantian file seketika karena data DNS di-cache dan state DS pada parent dapat berubah terpisah dari data child zone.

Selama rollover, record yang dipublikasikan dan timing-nya harus mempertahankan jalur validasi saat cache masih mungkin menyimpan material lama. Perubahan parent dan child memerlukan perhatian khusus ketika kunci yang dirujuk DS sedang diganti.

Otomatisasi DNSSEC dapat mengurangi penanganan manual, tetapi tidak menghapus ketergantungan antara state publikasi, TTL, signature, record delegasi, dan cache resolver.

DNSSEC tidak mengenkripsi DNS

Response yang berhasil divalidasi tetap dapat terlihat oleh sistem pada jalur jaringan. DNSSEC menandatangani data; mekanisme ini tidak menyediakan kerahasiaan transport.

Transport DNS terenkripsi seperti DNS over TLS dan DNS over HTTPS menangani batas berbeda dengan melindungi traffic DNS antara endpoint yang berpartisipasi. Keduanya tidak menggantikan rantai autentikasi asal milik DNSSEC. Demikian pula, DNSSEC tidak mengautentikasi application server setelah resolusi nama; protokol seperti TLS tetap memegang tanggung jawab tersebut.

Mekanisme ini dapat dipakai bersama karena melindungi tahap yang berbeda:

DNSSEC -> autentisitas dan integritas data DNS
DoT/DoH -> kerahasiaan dan integritas pada satu hop transport DNS
TLS     -> transport aplikasi terenkripsi dan terautentikasi

Kegagalan validasi adalah sinyal keamanan, bukan ketiadaan biasa

Ketika resolver memiliki chain of trust yang valid dan validasi DNSSEC gagal, mengembalikan data yang tidak tervalidasi secara diam-diam akan membuang perlindungan yang diberikan DNSSEC. Resolver pemvalidasi biasanya menampilkan kegagalan tersebut sebagai error resolusi alih-alih mengubah data bogus menjadi jawaban yang diterima.

Monitoring operasional perlu membedakan kegagalan validasi DNSSEC dari NXDOMAIN biasa, transport timeout, dan kegagalan authoritative server. Jalur perbaikannya berbeda: signature kedaluwarsa, record DS yang tidak cocok, state rollover yang salah, dan masalah clock dapat mengganggu signed zone tanpa menunjukkan bahwa nama yang diminta tidak ada.

Batas DNSSEC bersifat spesifik. Mekanisme ini memungkinkan resolver pemvalidasi memeriksa bahwa data DNS konsisten dengan rantai kriptografis yang berakar pada trust terkonfigurasi. DNSSEC tidak membuat DNS menjadi privat, tidak membuat setiap delegated zone otomatis bertanda tangan, dan tidak memindahkan autentikasi aplikasi ke dalam sistem penamaan.