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.

Jalur utamanya menggabungkan tiga tipe record:

key tepercaya
    |
    v
DNSKEY menandatangani DS di zone parent
    |
    v
DS mengidentifikasi DNSKEY child
    |
    v
DNSKEY child memverifikasi RRSIG
    |
    v
RRset terautentikasi

Rantai ini memungkinkan validasi melintasi batas administrasi tanpa menempatkan setiap zone key langsung ke konfigurasi trust setiap resolver.

RRSIG mengautentikasi RRset

DNSSEC menandatangani resource-record set, bukan teks presentasi secara sembarang. RRset mengelompokkan record dengan owner name, class, dan type yang sama. Record RRSIG terkait mengidentifikasi type yang dicakup, algoritma signing, key tag, signer name, interval validitas signature, dan signature itu sendiri.

Response bertanda tangan secara sederhana dapat digambarkan sebagai:

www.example.com.  300  IN  A      192.0.2.10
www.example.com.  300  IN  RRSIG  A 13 3 300 ...

Validator tidak sekadar memeriksa keberadaan RRSIG. Validator memilih DNSKEY yang cocok, memeriksa field inception dan expiration pada signature, membentuk canonical signed form sesuai definisi DNSSEC, lalu memverifikasi signature. Signature yang terlampir tetapi tidak dapat dihubungkan ke key terautentikasi tidak cukup.

Masa berlaku signature juga menjadikan waktu sebagai bagian dari validasi. Gangguan operasional seperti signature yang kedaluwarsa dapat membuat data zone yang tidak berubah gagal divalidasi. Operasi zone signing karena itu mencakup pengelolaan key dan pemeliharaan signature tepat waktu, bukan sekadar proses signing satu kali.

DNSKEY memublikasikan key verifikasi zone

Zone bertanda tangan memublikasikan public key dalam RRset DNSKEY di apex. Key tersebut digunakan dalam proses autentikasi signature pada zone itu.

example.com.  3600  IN  DNSKEY  257 3 13 <public-key-material>

Field numerik mengodekan flags, protocol, dan algorithm. Material public key aman untuk dipublikasikan; private signing key pasangannya tidak ditempatkan di DNS.

Validator tetap membutuhkan jalur tepercaya menuju RRset DNSKEY. Menerima key hanya karena key itu muncul pada response yang sama akan memungkinkan response palsu memasok data palsu sekaligus key palsu. DNSSEC menangani persoalan bootstrap tersebut dengan trust anchor dan delegasi bertanda tangan.

DS menghubungkan parent ke child zone

Pada delegasi bertanda tangan, zone parent memublikasikan RRset Delegation Signer (DS) untuk child. Record DS berisi digest yang terkait dengan DNSKEY milik child, bersama key tag, algorithm, dan digest type.

Secara konseptual:

zone parent

example. DNSKEY
    |
    | mengautentikasi data parent
    v
child.example. DS
    |
    | digest mengidentifikasi key child
    v
child.example. DNSKEY

Setelah mengautentikasi RRset DS milik parent, validator dapat mencocokkannya dengan DNSKEY di child zone. Key child kemudian dapat mengautentikasi RRset DNSKEY pada apex child dan signature atas RRset lain di zone tersebut.

Record DS berada pada sisi parent dari delegasi. Penempatan ini penting secara operasional karena mengaktifkan DNSSEC untuk child zone biasanya membutuhkan koordinasi antara konfigurasi signing child dan jalur parent atau registrar yang memublikasikan data DS yang cocok.

Trust anchor memulai validasi

Rantai kriptografis memerlukan titik awal yang sudah dipercaya. DNSSEC menyebut material awal itu trust anchor. Validator yang dikonfigurasi dengan key terautentikasi dapat memakainya untuk mengautentikasi link berikutnya dan meneruskan proses ke bawah hierarki DNS.

Untuk rantai yang berakar pada DNS root, alurnya secara umum:

root trust anchor
      |
      v
root DNSKEY
      |
      v
TLD DS -> TLD DNSKEY
      |
      v
child DS -> child DNSKEY
      |
      v
RRset aplikasi bertanda tangan

Setiap link yang berhasil mempersempit pilihan key berikutnya melalui data DNS terautentikasi. Signature beberapa tingkat di bawah trust anchor hanya berguna ketika validator dapat membangun authentication path yang dapat diterima menuju signature tersebut.

Zone bertanda tangan tanpa jalur semacam itu menjadi island of security kecuali validator memiliki trust anchor lain untuk zone tersebut. Menandatangani data dan membuat data itu dapat diverifikasi secara luas merupakan dua tahap deployment yang berkaitan tetapi berbeda.

Authenticated denial mencakup data yang tidak ada

DNS juga harus menjawab pertanyaan yang hasilnya berupa ketiadaan: sebuah nama tidak ada, atau nama ada tetapi tidak memiliki record dari type yang diminta. Negative response tanpa signature dapat dipalsukan dengan sekadar menyatakan bahwa data yang diminta tidak ada.

Spesifikasi DNSSEC awal menggunakan record NSEC untuk menyediakan authenticated denial of existence. Data NSEC bertanda tangan dapat membuktikan gap dalam namespace yang terurut dan type record yang tersedia pada nama yang ada. Validator memeriksa proof yang relevan beserta signature-nya, bukan mempercayai response NXDOMAIN yang tidak terautentikasi.

NSEC3, yang didefinisikan terpisah dari kumpulan record DNSSEC awal, menyediakan mekanisme authenticated denial lain menggunakan owner name yang di-hash. Karakteristik operasional dan privasinya berbeda dari NSEC, tetapi peran keamanannya serupa: negative answer DNS memerlukan bukti kriptografis ketika zone diharapkan secure.

Hasil validasi dapat secure, insecure, atau bogus

Resolver validator tidak menyederhanakan semua jawaban menjadi signed atau unsigned. Jalur validasi menentukan klasifikasi data.

Data dengan authentication chain yang valid dapat diperlakukan sebagai secure. Delegasi yang terautentikasi sebagai unsigned dapat mengarah ke data insecure: DNSSEC tidak menyatakan autentisitas data child tersebut, tetapi tidak adanya child bertanda tangan telah dibuktikan melalui proof dari sisi parent. Data yang seharusnya tervalidasi tetapi gagal memenuhi pemeriksaan wajib menjadi bogus.

Perbedaan ini mencegah stripping sederhana mengubah zone bertanda tangan menjadi zone unsigned biasa. Jika parent terautentikasi menunjukkan child bertanda tangan melalui DS, menghapus record DNSSEC milik child tidak menghasilkan delegasi insecure yang valid. Hasilnya adalah kegagalan validasi.

Untuk layanan recursive, RFC 4035 menetapkan perilaku kegagalan ketika signature yang diwajibkan tidak dapat divalidasi. Aplikasi biasanya melihat kegagalan tersebut melalui recursive resolver alih-alih menjalankan seluruh proses DNSSEC sendiri.

Bit AD, CD, dan DO memiliki peran berbeda

DNSSEC juga mengubah penanganan message DNS. Bit EDNS DNSSEC OK (DO) menandakan bahwa record DNSSEC diinginkan dalam response. Recursive resolver yang melakukan validasi menggunakannya ketika mengambil material yang diperlukan untuk validasi.

Bit Authenticated Data (AD) pada header DNS dapat menunjukkan bahwa recursive resolver menganggap data response autentik sesuai policy validasinya. Stub tidak boleh memperlakukan bit AD dari jalur yang tidak tepercaya sebagai bukti kriptografis mandiri. RFC 4035 mensyaratkan secure channel atau konfigurasi eksplisit sebelum mengandalkan validasi yang diklaim resolver lain.

Bit Checking Disabled (CD) meminta perilaku berbeda: requester dapat meminta server recursive yang security-aware agar tidak menolak data hanya karena validasi server tersebut gagal, sehingga requester dapat melakukan pemrosesan sendiri. AD, CD, dan DO karena itu bukan indikator keamanan yang dapat saling dipertukarkan.

DNSSEC tidak menyediakan confidentiality

Signature DNSSEC merupakan material verifikasi publik. Query, nama, nilai record, key, dan signature tetap dapat terlihat di jaringan kecuali mekanisme transport lain menyediakan confidentiality.

Transport DNS terenkripsi seperti DNS over TLS atau DNS over HTTPS menangani boundary berbeda: koneksi antara client dan resolver. DNSSEC menangani autentisitas dan integritas data DNS sepanjang rantai resolusi. Sebuah deployment dapat menggunakan keduanya karena keduanya menyelesaikan persoalan berbeda.

DNSSEC juga tidak menggantikan TLS. Record DNS bertanda tangan dapat mengautentikasi data DNS, sedangkan TLS mengautentikasi dan melindungi koneksi aplikasi sesuai aturan certificate dan protocol-nya sendiri. Memperlakukan salah satunya sebagai pengganti yang lain meninggalkan gap pada boundary yang seharusnya dilindungi mekanisme yang dihilangkan.

Perubahan key dan delegasi memerlukan state yang terkoordinasi

Operasi DNSSEC menjadi sensitif selama key rotation, migrasi algorithm, perubahan registrar, dan update delegasi karena validator dapat menyimpan cache record dengan lifetime berbeda. Key child baru belum menjadi authentication path global yang berguna sampai record bertanda tangan dan state delegasi pada sisi parent tersusun dengan benar.

Demikian pula, menghapus material lama terlalu cepat dapat memutus chain bagi resolver yang masih menyimpan state lama di cache. Prosedur yang aman bergantung pada metode key management, TTL, signing software, workflow parent, dan algorithm policy yang digunakan. Invariant utamanya adalah validator harus tetap memiliki jalur valid sepanjang setiap transisi, bukan melihat kombinasi sementara yang tidak dapat diautentikasi.

DNSSEC paling tepat diperlakukan sebagai sistem pengelolaan chain, bukan checkbox signature. RRSIG mengautentikasi RRset, DNSKEY menyediakan key verifikasi, DS membawa trust melintasi delegasi, dan trust anchor memberi resolver titik awal yang kredibel. Properti keamanan berasal dari jalur lengkap beserta validasinya, bukan dari keberadaan satu record DNSSEC saja.