Permintaan
Rancang control plane rollover kunci DNSSEC untuk platform yang menghosting puluhan ribu zona yang ditandatangani. Sistem ini mengoordinasikan rekaman DS registrar, rekaman DNSKEY/RRSIG DNS otoritatif, dan persetujuan tenant tanpa mengekspos validating resolver ke rantai validasi yang rusak.
Skenario dan batasan
Masa aktif KSK dan ZSK berbeda, API registrar mengalami latensi dan dapat dicoba ulang, serta node otoritatif tersebar di berbagai wilayah. Control plane memerlukan percobaan ulang yang idempoten, jeda per-tenant, transisi status yang dapat diaudit, dan perilaku fail-closed ketika suatu langkah tidak pasti.
Apa yang diuji
Inti dari pengujian ini adalah state machine, time invariant, orkestrasi side-effect eksternal, dan observabilitas. Jawaban yang kuat membedakan antara pra-publikasi DNSKEY, publikasi DS, penghentian kunci lama, dan tumpang tindih tanda tangan; membuat kunci saja bukanlah sebuah rollover.
Pendekatan referensi
Pertahankan state machine per zona: observe, prepublish, ds-submit, ds-visible, sign-with-both, retire-old, dan verify. Catat versi yang diinginkan, token operasi, anggaran TTL, dan snapshot bukti pada setiap transisi. Publikasikan DNSKEY baru ke semua node otoritatif dan tunggu TTL-nya, lalu kirimkan DS melalui registrar. Setelah DS induk terlihat melalui beberapa recursive resolver, tanda tangani dengan kedua kunci selama jendela keamanan, dan baru setelah itu hapus DS dan DNSKEY lama.
Jalankan satu zona pada satu waktu di bawah lease. Panggilan eksternal menggunakan kunci idempotensi dan exponential backoff. Bekukan zona pada SERVFAIL, ketidakcocokan DS/DNSKEY, atau RRSIG yang kedaluwarsa; pertahankan materi lama dan minta persetujuan manusia.
Detail penting
Basis data menyimpan status yang diinginkan, sementara kueri DNS dan pembacaan ulang registrar adalah sumber kebenaran (sources of truth); konflik tidak boleh ditimpa secara membabi buta. Pengaturan waktu mencakup TTL otoritatif dan rekursif, validitas tanda tangan, dan margin propagasi. Simpan kunci privat dalam penyimpanan KMS yang terkontrol, dan catat sidik jari (fingerprint), key tag, versi, serta pelaku alih-alih materi privat.
Jebakan umum
Mengubah satu objek registrar secara bersamaan di seluruh tenant; hanya memeriksa node otoritatif dan bukan DS induk; menghapus kunci lama segera setelah langkah yang gagal; memperlakukan percobaan ulang antrean sebagai idempotensi; dan menghilangkan jalur jeda atau pengambilalihan manual oleh manusia.
Rubrik evaluasi
Jawaban yang kuat mendefinisikan batasan antara control plane, DNS otoritatif, registrar, validating resolver, dan penyimpanan audit; menyatakan setidaknya tiga invariant keamanan; dan menentukan kondisi masuk, keluar, serta rollback untuk setiap status. Jawaban tersebut juga menyebutkan metrik tingkat keberhasilan, SERVFAIL, latensi propagasi, dan lease yang macet.
Pertanyaan lanjutan
Mengapa publikasi DS biasanya dilakukan setelah pra-publikasi DNSKEY?
Pra-publikasi memungkinkan node otoritatif dan cache memperoleh DNSKEY baru terlebih dahulu. DS induk kemudian dapat mengarah ke kunci yang dapat diambil oleh validator, sehingga mengurangi jendela di mana DS terlihat tetapi DNSKEY tidak ditemukan.
Bagaimana Anda mencoba ulang ketika panggilan registrar mengalami timeout tetapi mungkin telah berhasil?
Baca DS registrar saat ini menggunakan versi zona dan token idempotensi, lalu putuskan apakah akan mencoba ulang. Jangan mengirimkan mutasi kedua yang tidak diketahui hanya berdasarkan satu timeout.
Kapan sistem dapat menghapus DS lama secara otomatis?
Hanya setelah DS baru tetap terlihat di set recursive-resolver target, validasi RRSIG berhasil, dan jendela TTL serta tanda tangan memenuhi kebijakan. Jika tidak, zona tetap dibekukan.