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.

Mekanisme ini memisahkan delegasi dari kepemilikan key: parent memublikasikan komitmen ringkas terhadap key milik child, sedangkan child memublikasikan dan memakai key DNSSEC miliknya sendiri.

Record DS berada di sisi parent

Record DS memiliki empat field:

key tag | algorithm | digest type | digest

Key tag dan algorithm membantu mengidentifikasi DNSKEY yang dirujuk. Digest dihitung dari canonical owner name dan DNSKEY RDATA sesuai digest algorithm yang dipilih.

Untuk delegasi seperti example.com, RRset DS berada di sisi parent dari zone cut. Child memublikasikan RRset DNSKEY yang sesuai pada apex zonanya sendiri.

zona .com
   |
   +-- example.com DS  ----+
                           |
                           v
zona example.com       DNSKEY yang cocok
                           |
                           v
                    RRset bertanda tangan

Pemisahan ini merupakan bagian inti dari model trust. Jika child dapat membuat DS sisi parent yang terautentikasi sendiri, child key yang belum dipercaya dapat memberi otorisasi kepada dirinya sendiri. Sebaliknya, data parent yang ditandatangani membuat komitmen terhadap key yang diizinkan untuk meneruskan chain.

Validasi bergantian antara signature dan referensi key

Chain tipikal dimulai dari trust anchor yang telah dikonfigurasi. Resolver dapat memakai DNSKEY yang telah terautentikasi untuk memverifikasi RRSIG atas RRset DS delegasi child. Resolver kemudian membandingkan DS yang telah terautentikasi dengan kandidat record DNSKEY dari child.

Child key yang cocok dapat dipakai dalam jalur validasi untuk RRset DNSKEY milik child. Key yang terautentikasi melalui jalur tersebut kemudian dapat memverifikasi signature atas data biasa milik child.

Secara konseptual:

DNSKEY tepercaya
     |
verifikasi RRSIG parent
     |
DS terautentikasi
     |
cocokkan digest
     |
child DNSKEY
     |
verifikasi RRSIG child
     |
RRset terautentikasi

Ini bukan certificate chain. DNSSEC mendefinisikan resource record, canonical form, pemrosesan signature, dan semantik delegasinya sendiri. Perbandingan yang relevan lebih sempit: setiap link yang telah terautentikasi menyediakan dasar untuk memeriksa link berikutnya sampai RRset target tercapai.

Record DS mengidentifikasi key, bukan memuat key

Digest DS adalah komitmen terhadap DNSKEY, bukan pengganti public key. Validator tetap mengambil RRset DNSKEY milik child dan memeriksa apakah kandidat key menghasilkan digest yang diidentifikasi oleh DS terautentikasi.

Key tag merupakan bantuan efisiensi, bukan identifier keamanan yang unik. Key yang berbeda dapat memiliki key tag yang sama. Karena itu, validasi tidak dapat berhenti setelah membandingkan key tag; hubungan algorithm dan digest juga menjadi bagian pemeriksaan.

DNSKEY yang dirujuk oleh DS juga harus merupakan DNSSEC zone key. Validasi DNSSEC menerapkan semantik record selain perbandingan digest secara kriptografis.

DS yang tidak ada dapat menandai delegasi sebagai insecure

Parent yang ditandatangani tidak berarti setiap child di bawahnya ikut ditandatangani. DNSSEC harus membedakan delegasi yang memang tidak ditandatangani dari child bertanda tangan yang data autentikasinya hilang atau tidak valid.

Ketika validating resolver dapat mengautentikasi bukti bahwa DS tidak ada pada sebuah delegasi, cabang tersebut dapat diklasifikasikan sebagai insecure dalam pemrosesan DNSSEC. Data di bawah delegasi insecure itu tidak memperoleh autentisitas DNSSEC dari chain parent.

Status tersebut berbeda dari bogus. Jika secure delegation menyatakan bahwa child ditandatangani, tetapi signature atau key yang diperlukan gagal divalidasi, menerima response tersebut seolah hanya unsigned akan menghilangkan proteksi yang disediakan DNSSEC.

Secara operasional, publikasi DS merupakan transisi keamanan. Record itu memberi tahu validator bahwa child ikut dalam authenticated chain.

Mengganti DNSSEC key bukan hanya operasi di zona child ketika key terkait direpresentasikan oleh DS di parent. Parent dan child merupakan domain administrasi dan caching yang terpisah, sehingga urutan rollover berpengaruh.

Transisi yang aman mempertahankan setidaknya satu jalur autentikasi valid ketika material lama dan baru berpropagasi. Bergantung pada desain rollover, kondisi ini dapat memerlukan overlap DNSKEY dan DS selama suatu periode, bukan mengganti kedua sisi sebagai satu tindakan instan.

Failure mode pada kedua sisi tidak simetris. Memublikasikan DS sebelum child key terkait tersedia dapat menghasilkan secure delegation yang tidak dapat diselesaikan validator. Menghapus material child key lama sebelum referensi di sisi parent dan data cache kedaluwarsa dapat memutus chain yang sebelumnya valid.

DNS TTL, masa berlaku signature, waktu publikasi, serta latensi update registrar atau registry memengaruhi transisi. Protokol menyediakan record dan aturan validasi; prosedur deployment harus menjaga kontinuitas di antara timeline yang independen tersebut.

DNSSEC mengautentikasi data DNS, bukan channel transport

Signature DNSSEC diterapkan pada RRset DNS. Signature tersebut menyediakan origin authentication dan integrity untuk data DNS yang berhasil divalidasi. DNSSEC tidak mengenkripsi nama atau jawaban DNS, dan tidak mengubah koneksi ke authoritative DNS server menjadi channel rahasia.

Perbedaan ini juga memisahkan DNSSEC dari mekanisme yang mengautentikasi transaksi DNS individual. Resolver dapat memvalidasi data bertanda tangan walaupun data tiba melalui jalur jaringan yang tidak dipercaya, selama authentication chain dan signature lengkap berhasil diverifikasi sesuai policy.

Trust anchor tetap menjadi asumsi awal. Validator memerlukan setidaknya satu key atau digest tepercaya yang dikonfigurasi sebagai titik awal untuk membangun chain. DNSSEC tidak membentuk trust awal tersebut dari jawaban arbitrer yang diterima melalui DNS.

Batas delegasi adalah titik kontrol

Record DS membuat batas parent-child menjadi eksplisit. Parent tidak memerlukan private key milik child, dan child tidak perlu menyerahkan kontrol signing. Parent hanya memublikasikan data terautentikasi yang mengidentifikasi material child key yang dapat diterima.

Record kecil tersebut membawa konsekuensi operasional besar. Menambahkan, mengganti, atau menghapusnya mengubah kemampuan validator untuk meneruskan state DNS terautentikasi ke zona child. Karena itu, deployment DNSSEC perlu memperlakukan pengelolaan DS sebagai bagian dari lifecycle key, bukan sebagai metadata registrar yang boleh menyimpang dari zona child.

Chain yang valid bergantung pada kesesuaian kedua sisi pada saat yang sama: parent harus mengautentikasi DS yang dimaksud, sedangkan child harus memublikasikan material DNSKEY yang cocok dan mampu mendukung signature yang perlu diperiksa validator.

Referensi

Cybersecurity DNSSEC DNS PKI