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.
Mekanisme ini mengurangi koordinasi manual, tetapi tidak membuat setiap perubahan delegasi otomatis dapat dipercaya. Trust yang sudah ada, kebijakan bootstrap, konsistensi antar-authoritative server, dan penanganan eksplisit untuk penghapusan tetap menjadi bagian dari batas keamanan.
CDS membawa data berbentuk DS; CDNSKEY membawa material key
Kedua tipe record menyatakan tujuan yang berdekatan dalam bentuk berbeda.
Record CDS memiliki format presentasi yang sama dengan record DS. Record ini dapat menyatakan key tag, algoritma DNSSEC, algoritma digest, dan digest yang ingin direpresentasikan child di parent:
example.com. CDS 12345 13 2 49FD46E6C4B45C55D4AC...Record CDNSKEY memakai format presentasi yang sama dengan DNSKEY. Record ini memublikasikan material key yang dapat dipakai parent untuk menghitung record DS sesuai kebijakan algoritma digest yang didukungnya:
example.com. CDNSKEY 257 3 13 <base64-public-key>RFC 7344 mengizinkan parent mengonsumsi CDS, CDNSKEY, atau keduanya sesuai kebijakan implementasinya. Ketika child memublikasikan keduanya, kontennya harus menggambarkan prospective delegation state yang cocok menurut aturan protokol.
Perbedaan ini memberi pilihan kepada parent. CDS memungkinkan child memasok data berbentuk DS secara langsung. CDNSKEY memungkinkan parent menurunkan record DS dari key yang diumumkan, termasuk memakai algoritma digest yang dipilih parent.
Record ditempatkan pada apex child zone
CDS dan CDNSKEY bukan hint bebas yang dapat ditempatkan di sembarang bagian zone. Aturan pemrosesannya menempatkan record tersebut pada apex child zone, tempat keduanya mewakili permintaan perubahan terhadap delegasi di atas zone itu.
Untuk delegasi yang sudah aman, RFC 7344 mengaitkan penerimaan dengan chain of trust yang telah ada. RRset CDS atau CDNSKEY harus ditandatangani secara tepat, dan penerapan state yang diusulkan tidak boleh memutus delegasi aman yang sedang berlaku selama proses rollover.
Kontinuitas tersebut menjadi perlindungan utama untuk key rollover rutin. Parent tidak memperlakukan jawaban DNS tanpa tanda tangan sebagai otoritas untuk mengganti trust anchor. Parent memproses sinyal yang diautentikasi melalui state delegasi yang sudah berlaku.
Parent juga dapat menerapkan pemeriksaan tambahan atau penundaan. Otomatisasi menetapkan jalur transport dan pemrosesan permintaan; tanggung jawab parent untuk menentukan permintaan yang memenuhi kebijakan penerimaannya tetap ada.
Enrollment awal memerlukan keputusan trust terpisah
Set DS yang sudah ada hanya dapat mengautentikasi rollover ketika delegasi aman memang telah terbentuk. Enrollment DNSSEC pertama belum memiliki anchor DS sebelumnya di parent, sehingga argumen kontinuitas yang sama tidak dapat membentuk hubungan trust pertama.
RFC 8078 memperluas model dengan metode untuk pembentukan trust awal dan menegaskan bahwa parent memerlukan kebijakan penerimaan untuk transisi ini. Desain dapat memakai channel terautentikasi, pemeriksaan tambahan, masa tunggu, atau mekanisme lain yang ditetapkan parent.
Pekerjaan DNSSEC automation yang lebih baru juga menetapkan authenticated bootstrap signal untuk deployment yang mendukungnya. Mekanisme tersebut terpisah dari tindakan sekadar menerima RRset CDS atau CDNSKEY yang tidak terautentikasi.
Batas ini penting secara operasional: key rollover di dalam delegasi aman yang sudah terbentuk dan pembuatan delegasi aman pertama adalah dua peristiwa keamanan yang berbeda. Sistem tidak semestinya memperlakukan keduanya sebagai proses yang identik.
Sinyal penghapusan bersifat eksplisit
RRset CDS atau CDNSKEY kosong tidak berarti “hapus DNSSEC.” RFC 7344 memperlakukan ketiadaan record tersebut sebagai tidak adanya permintaan perubahan setelah parent dan child tersinkronisasi.
RFC 8078 menetapkan sinyal penghapusan khusus. Untuk CDS, bentuk standarnya adalah:
example.com. CDS 0 0 0 0Untuk CDNSKEY, bentuk yang sesuai adalah:
example.com. CDNSKEY 0 3 0 0Parent harus memvalidasi sinyal dan kondisi penerimaannya sebelum menghapus RRset DS. Setelah DS di sisi parent dihapus, data delegasi yang masih berada di cache juga harus melewati masa berlakunya sebelum child dapat menyelesaikan transisi ke operasi tanpa tanda tangan secara aman.
Karena itu, penghapusan memerlukan kehati-hatian yang setara dengan enrollment. Penghapusan set DS mengubah delegasi dari state yang terhubung secara kriptografis menjadi delegasi insecure setelah cache konvergen. Operasi ini bukan sekadar pembersihan metadata lama.
Authoritative server harus menyajikan target state yang konsisten
Parent dapat melakukan query ke lebih dari satu authoritative server milik child. Jika server-server tersebut menampilkan data CDS, CDNSKEY, atau pembaruan delegasi terkait yang saling bertentangan, bertindak berdasarkan respons yang datang lebih dahulu dapat mengubah deployment skew menjadi kesalahan pengelolaan trust.
RFC 9975 memperjelas persyaratan konsistensi untuk pemrosesan CDS/CDNSKEY dan CSYNC. Entitas di sisi parent yang menerima sinyal tersebut perlu memastikan target state yang diambil dari authoritative server memenuhi kondisi konsistensi yang diwajibkan sebelum menerapkan pembaruan.
Hal ini terutama relevan selama perubahan DNS bertahap. Publikasi zone, state signer, dan infrastruktur authoritative serving dapat berbeda sesaat jika urutan rollout buruk. Parental agent yang aman memperlakukan perbedaan tersebut sebagai alasan untuk tidak membentuk satu intended state dari observasi yang tidak kompatibel.
Pemeriksaan konsistensi dengan demikian merupakan bagian dari logika keamanan, bukan sekadar optimasi availability.
Otomatisasi tetap memerlukan state dan observability
Parental agent yang kuat memerlukan lebih dari query DNS berkala. Agent harus membedakan state delegasi saat ini dari state yang diusulkan, mencegah observasi lama menimpa state baru yang sudah diterima, menerapkan kebijakan penerimaan, serta mencatat kegagalan dengan cukup jelas agar operator dapat mendiagnosisnya.
RFC 7344 membahas perlindungan terhadap update usang, termasuk state berdasarkan data bertanda tangan dan perkembangan zone. Panduan operasional terkini untuk DS automation juga menekankan pemeriksaan penerimaan, pelaporan, dan koordinasi ketika beberapa pihak atau channel update dapat memengaruhi delegasi.
Konsekuensi praktisnya, otomatisasi sebaiknya memiliki transisi state yang terlihat. Operator perlu dapat membedakan sinyal yang tidak ada, tidak valid, tidak konsisten, masih menunggu pemeriksaan kebijakan, sudah diterima, atau telah tersinkronisasi. Menganggap setiap kondisi tanpa update sebagai kegagalan generik akan menutupi perbedaan antara penolakan aman dan workflow yang rusak.
Otomatisasi delegasi mempersempit batas manual yang rapuh
CDS dan CDNSKEY membawa pemeliharaan trust DNSSEC lebih dekat ke signed zone yang memiliki transisi key. Untuk delegasi aman yang sudah terbentuk, hal ini menyediakan jalur kontinuitas yang berguna: child memublikasikan prospective state yang terautentikasi, lalu parent dapat memvalidasi dan menerapkannya tanpa menyalin nilai DS melalui antarmuka manual terpisah.
Mekanisme ini tetap memiliki batas yang tegas. Enrollment awal memerlukan kebijakan bootstrap. Penghapusan memerlukan sinyal terautentikasi yang eksplisit serta urutan yang memperhitungkan cache. Tampilan authoritative yang saling bertentangan tidak boleh dilebur menjadi target state buatan.
Dengan batas tersebut tetap utuh, CDS dan CDNSKEY mengubah pemeliharaan DS menjadi operasi berbasis protokol sambil mempertahankan perbedaan antara rollover rutin, pembentukan trust pertama, dan penghapusan delegasi aman secara sengaja.