Wawancara Jaringan: Bagaimana Cara Memecahkan Masalah SERVFAIL Setelah DNSSEC Rollover?

Pertanyaan dan Kapan Ini Berlaku

Pada 21:00 UTC, example.com melakukan rollover kunci DNSSEC dan mengubah record A untuk api.example.com dari 192.0.2.20 menjadi 192.0.2.40. Sepuluh menit kemudian, klien yang menggunakan beberapa resolver rekursif yang memvalidasi menerima SERVFAIL. Menambahkan +cd ke kueri resolver yang sama mengembalikan alamat baru dan sebuah RRSIG, serta kueri langsung ke server otoritatif juga menerima respons. Klien lain terus menggunakan alamat lama. Induk (parent) saat ini mempublikasikan DS dengan key tag 18200, sedangkan zona anak hanya mempublikasikan DNSKEY dengan key tag 51900. Lakukan diagnosis, pemulihan, dan verifikasi insiden tersebut tanpa meninggalkan batas validasi DNSSEC atau mendistribusikan jawaban yang tidak tepercaya kepada pengguna.

Domain, alamat, key tag, waktu, dan perubahan adalah asumsi wawancara. 192.0.2.0/24 adalah blok alamat dokumentasi. Tugas utamanya adalah menyimpulkan status setiap lapisan resolusi DNS dan rantai kepercayaan (chain of trust) DNSSEC dari gejala yang dapat diamati. Pemadaman aplikasi tidak boleh disimpulkan dari SERVFAIL saja. Pertanyaan ini cocok untuk peran SRE, infrastruktur, jaringan, keamanan, backend, dan rekayasa perangkat lunak umum, sehingga kategorinya adalah umum.

Diskusi publik tahun 2025 tentang wawancara peran senior masih memperlakukan pengetahuan DNS dan DNSSEC sebagai materi wawancara yang relevan. Bukti tersebut menetapkan konteks wawancara saat ini; itu tidak menetapkan frekuensi atau pertanyaan tetap dari perusahaan tertentu. Laporan DENIC tahun 2026 tentang pemadaman DNS .de mendokumentasikan cacat rollover yang membuat sebagian besar tanda tangan tidak dapat diverifikasi dan menyebabkan resolver yang memvalidasi menolak delegasi yang terdampak. Oleh karena itu, kegagalan kunci, tanda tangan, dan validasi tetap nyata secara operasional.

Artikel “apa yang terjadi saat Anda mengetik URL” yang sudah ada mencakup kasus normal saat klien mendelegasikan pekerjaan rekursif dan cache memperpendek jalur tersebut. Artikel SSRF berfokus pada otorisasi alamat yang di-resolve dan menutup celah DNS-rebinding. Pertanyaan ini berfokus pada record DS induk, record DNSKEY/RRSIG anak, status validasi, urutan pemulihan yang aman, dan verifikasi lintas resolver. Lapisan kegagalan dan invarian keamanannya berbeda.

Apa yang Dievaluasi Pewawancara

Sinyal pertama adalah diagnosis berlapis (layered diagnosis). Kegagalan resolusi nama dapat berasal dari stub lokal, resolver rekursif korporat atau publik, delegasi induk, server otoritatif, validasi DNSSEC, atau data A, AAAA, atau CNAME akhir. Jawaban yang kuat menjaga agar nama kueri, jenis, waktu, dan resolver tetap konstan, mengumpulkan RCODE, jawaban, TTL, data otoritas, dan record DNSSEC di setiap lapisan, serta mengidentifikasi titik pertama di mana hasil pengamatan mulai berbeda.

Sinyal kedua adalah interpretasi response code yang akurat. NXDOMAIN berarti rantai otoritatif menyatakan bahwa nama yang di-query tidak ada. NOERROR dengan jawaban kosong dapat berarti nama tersebut ada tetapi tidak memiliki record dari jenis tersebut. Waktu habis (timeout) berarti tidak ada respons yang dapat digunakan yang tiba dalam batas waktu. REFUSED berarti server menolak kueri. SERVFAIL adalah kegagalan server umum. Validasi DNSSEC yang gagal dapat menghasilkan SERVFAIL, tetapi satu kode status tidak dapat membuktikan penyebab tersebut secara mutlak.

Sinyal ketiga adalah pemahaman tentang rantai kepercayaan (chain of trust). Record DS berada di titik delegasi sisi induk dan menghubungkan rantai tepercaya induk ke DNSKEY anak. Record RRSIG menandatangani RRset di zona anak, sementara validator juga memeriksa algoritma, digest, batas waktu tanda tangan, dan trust anchor. Sebuah key tag membantu menemukan kandidat kunci; itu bukan bukti kriptografis. Jawaban harus memverifikasi bahwa digest DS sesuai dengan DNSKEY yang sebenarnya dan bahwa kunci yang dipublikasikan memvalidasi tanda tangan terkait.

Sinyal keempat adalah perbandingan terkontrol. Terhadap resolver rekursif yang sama, kueri +dnssec normal yang gagal sementara kueri +cd mengembalikan record mentah sangat mengindikasikan masalah pada jalur validasi. CD meminta resolver untuk menonaktifkan pemeriksaan untuk kueri tersebut dan berguna untuk diagnosis. Hal itu tidak membuat data yang dikembalikan menjadi tepercaya dan bukan merupakan jalan pintas (bypass) produksi. Bit AD dari resolver pemvalidasi tepercaya dapat menyatakan data yang diautentikasi. Ketiadaan AD juga dapat mencerminkan permintaan klien, kebijakan resolver, atau batas kepercayaan, sehingga harus diinterpretasikan bersama dengan bukti lainnya.

Terakhir, pewawancara mencari disiplin pemulihan. Jika kunci lama yang dirujuk oleh DS induk saat ini dihentikan terlalu dini, jalur aman tercepat sering kali adalah memulihkan DNSKEY dan tanda tangan valid yang dapat diautentikasi oleh DS saat ini, lalu melanjutkan rollover dengan jendela tumpang tindih (overlap window). Menonaktifkan validasi secara global, melakukan flush cache sembarangan, atau mengedit record A berulang kali akan memperluas risiko. Setelah pemulihan, TTL yang ada masih harus konvergen, dan validator independen harus membuktikan rantai yang valid dan aplikasi yang berfungsi.

Pertanyaan yang Perlu Diklarifikasi Sebelum Menjawab

• Apakah dampaknya memengaruhi satu nama, seluruh zona, atau banyak zona di bawah satu TLD? Cakupan menentukan apakah harus memulai dari perubahan zona anak, penyedia otoritatif, atau insiden induk/registri.
• Resolver rekursif mana yang sebenarnya digunakan oleh klien yang gagal? DNS terenkripsi pada browser, forwarder korporat, VPN, dan pengaturan sistem operasi dapat mengarahkan klien ke jalur yang berbeda dari jaringan yang sama.
• Apa RCODE, EDE, jenis kueri, dan waktu dari setiap kegagalan? Keberhasilan A dengan kegagalan AAAA, lompatan CNAME yang rusak, atau kegagalan yang terbatas pada resolver yang memvalidasi menghasilkan cabang penanganan yang berbeda.
• Berapa nilai NS, DS, DNSKEY, RRSIG, dan TTL sebelum dan sesudah perubahan? Urutan rollover, masa pakai cache maksimum, dan kunci lama yang dapat dipulihkan menentukan mitigasi.
• Apakah semua server otoritatif mengembalikan serial SOA dan RRset bertanda tangan yang sama? Perbedaan versi (version skew) di antara server otoritatif dapat menimbulkan hasil yang intermiten; satu server tidak mewakili keseluruhan zona.
• Apakah jam resolver dan penandatangan akurat? Record RRSIG memiliki waktu inception dan expiration, sehingga kesalahan jam yang signifikan dapat menyebabkan kegagalan validasi.
• Bisakah IP lama tetap melayani lalu lintas dengan aman? Jika ya, pertahankan kompatibilitas selama konvergensi TTL. Jika tidak, kelola risiko koneksi tersebut secara terpisah karena DNS tidak dapat mencabut paksa jawaban yang di-cache.
• Siapa yang mengontrol DS induk dan perubahan darurat? Registrar, registri, penyedia DNS, dan tim on-call internal memiliki izin dan waktu respons yang berbeda.

Kerangka Jawaban 30 Detik

“Saya akan memastikan resolver rekursif klien yang bermasalah dan mencatat RCODE, EDE, data A/AAAA/CNAME, TTL, dan timestamp. Terhadap resolver yang sama, SERVFAIL secara normal dan data dengan +cd mengarahkan saya ke jalur validasi DNSSEC. Saya akan mengambil DS dari induk dan DNSKEY, RRSIG, serta SOA dari setiap server otoritatif, lalu membandingkan digest, algoritma, waktu tanda tangan, dan konsistensi node. Di sini DS induk tidak memiliki DNSKEY anak yang cocok, konsisten dengan penghentian kunci lama yang terlalu dini. Pertama-tama saya akan memulihkan kunci dan tanda tangan yang sudah terbukti baik yang cocok dengan DS saat ini. Setelah beberapa validator mengembalikan jawaban yang diautentikasi, saya akan memantau konvergensi TTL dan menambahkan rollover tumpang tindih, validasi pra-publikasi, peringatan kedaluwarsa tanda tangan, dan pemeriksaan sintetis multi-vantage.”

Jawaban Mendalam Langkah demi Langkah

Langkah 1: Tetapkan batas kegagalan dan kontrol

Catat waktu, jaringan klien, resolver rekursif aktual, nama kueri, dan jenis kueri untuk satu kegagalan. Lewati cache aplikasi dan browser lalu lakukan kueri ke resolver yang digunakan klien. Kemudian pilih resolver pemvalidasi independen sebagai kontrol. Jangan mengubah nama, jenis, dan resolver secara bersamaan, karena perbedaan tersebut tidak lagi mengisolasi variabel.

dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com AAAA +dnssec
dig @<control-resolver> api.example.com A +dnssec

Simpan status, flag, Answer, Authority, Additional, TTL, dan Extended DNS Error EDNS apa pun dari respons lengkap. Jika A tervalidasi sementara AAAA gagal, periksa AAAA dan rantai CNAME-nya. Jika setiap jenis mengalami timeout, periksa terlebih dahulu keterjangkauan jaringan, port 53, ketersediaan server otoritatif, dan penanganan ukuran paket. Jika hanya satu resolver rekursif yang gagal, cache, kebijakan, jam, atau rantai forwarding-nya tetap menjadi kandidat masalah.

Klien yang masih mengakses IP lama bukanlah bukti yang kontradiktif. RRset A lama dapat digunakan kembali hingga TTL-nya kedaluwarsa, dan tanda tangan yang menyertainya mungkin masih valid. TTL tidak dapat diperpendek secara retroaktif setelah dipublikasikan, jadi jaga agar endpoint lama tetap aman dan kompatibel selama jendela cache yang diketahui.

Langkah 2: Gunakan perbandingan CD untuk memasuki cabang DNSSEC

Ulangi nama dan jenis yang sama terhadap resolver gagal yang sama dengan CD diaktifkan:

dig @<affected-resolver> api.example.com A +dnssec
dig @<affected-resolver> api.example.com A +dnssec +cd

Jika kueri normal mengembalikan SERVFAIL tetapi +cd mengembalikan record A, DNSKEY, atau RRSIG, kegagalan validasi menjadi hipotesis utama. Pemecahan masalah domain Google Public DNS menggunakan kontras yang sama—Status 2 dengan keberhasilan saat validasi dinonaktifkan—untuk mengidentifikasi kemungkinan masalah DNSSEC, dan Extended DNS Errors dapat memberikan alasan yang lebih spesifik. Lanjutkan memeriksa jalur mentah karena timeout server otoritatif, loop delegasi, dan kesalahan server lainnya juga dapat menghasilkan SERVFAIL.

+cd mengekspos data yang seharusnya ditolak oleh resolver. Mengarahkan aplikasi ke resolver yang tidak memvalidasi atau menonaktifkan DNSSEC secara global mengubah insiden ketersediaan menjadi risiko integritas. Jika seorang incident commander menggunakan pengecualian validasi selama pemadaman hulu yang luas, hal itu tetap memerlukan cakupan domain yang sempit, batas waktu, risiko yang tercatat, dan kriteria keluar yang eksplisit.

Langkah 3: Periksa delegasi, data otoritatif, dan tanda tangan secara terpisah

Pertama, gunakan trace untuk mengidentifikasi jalur sebenarnya melalui root, induk, dan delegasi anak. Trace adalah pengamatan terhadap jalur kueri, bukan hasil validasi kriptografis lengkap. Lakukan kueri DS langsung dari otoritas induk, dan kueri DNSKEY, SOA, serta RRset bisnis dari setiap otoritas anak.

dig +trace example.com DS +dnssec
dig @<parent-authoritative> example.com DS +dnssec
dig @<child-authoritative-1> example.com DNSKEY +dnssec
dig @<child-authoritative-1> api.example.com A +dnssec
dig @<child-authoritative-1> example.com SOA +dnssec

Ulangi kueri untuk setiap otoritas dan bandingkan set NS, glue, serial SOA, RRset DNSKEY, dan record RRSIG. Server otoritatif yang mengembalikan A dan RRSIG membuktikan bahwa server tersebut menyajikan data. Server otoritatif umumnya tidak memvalidasi rantai lengkap dari trust anchor induk atas nama pemohon. Oleh karena itu, keberhasilan otoritas langsung dan kegagalan validasi rekursif dapat terjadi secara bersamaan.

Periksa apakah pemilik, algoritma, jenis digest, dan digest dari DS induk sesuai dengan DNSKEY anak; apakah RRset DNSKEY memiliki tanda tangan yang valid saat ini; apakah RRSIG dari RRset A bisnis memiliki key tag, algoritma, inception, dan expiration yang masuk akal; dan apakah setiap zona bertanda tangan dalam rantai CNAME dapat membentuk rantai. Validator independen dapat mengidentifikasi node yang gagal, yang kemudian harus dikonfirmasi oleh record mentah.

Dalam skenario ini, key tag DS 18200 milik induk tidak memiliki kandidat dalam RRset DNSKEY anak, dan digest-nya tidak cocok dengan kunci saat ini 51900. Korelasi dengan waktu perubahan menunjukkan bahwa KSK/DNSKEY lama dihapus sebelum DS induk menyelesaikan transisi yang aman. Ketidakcocokan tag adalah petunjuk; perbandingan digest dan validasi tanda tangan melengkapi buktinya.

Langkah 4: Pulihkan dalam batas keamanan

Bekukan rollover otomatis dan perubahan DNS yang tidak terkait. Amankan log perubahan, snapshot zona, pengidentifikasi kunci, dan respons yang gagal. Jika private key sebelumnya masih ada dalam sistem kunci yang dikontrol, pulihkan DNSKEY-nya dan buat tanda tangan yang terbukti baik yang membentuk rantai melalui DS induk saat ini. Ini sering kali lebih cepat daripada menunggu perubahan pada induk. Validasi rantai lengkap secara terisolasi sebelum mempublikasikan status yang sama dari semua otoritas.

Jika kunci lama tidak dapat dipulihkan, pemilik DNS dan keamanan harus mengoordinasikan perbaikan DS induk dengan registrar dan memperhitungkan waktu propagasi. Menghapus DS mengembalikan anak ke status tidak bertanda tangan (unsigned), melemahkan jaminan otentikasinya, dan masih memiliki latensi cache serta perubahan induk. Ini adalah opsi pemulihan yang disetujui, terdokumentasi, dan terarah, bukan jalan pintas biasa. Membuat kunci baru hanya dengan key tag yang sama tidak akan berhasil—digest-nya tidak akan cocok.

Jika endpoint A lama tetap aman, terus layani melalui jendela TTL dari RRset lama. Endpoint lama dan baru harus menggunakan konfigurasi kritis dan kebijakan autentikasi yang kompatibel. Flushing cache hanya dapat memengaruhi resolver di bawah kendali operator, sehingga pemulihan tidak dapat bergantung pada flush global yang sebenarnya tidak ada.

Langkah 5: Buktikan bahwa DNS dan aplikasi telah pulih

Lakukan kueri terhadap nama yang telah diperbaiki dari resolver rekursif pemvalidasi independen dan berbagai wilayah. Konfirmasikan bahwa SERVFAIL telah hilang, jawabannya sesuai yang diharapkan, dan hasil validasi tepercaya ada. Kemudian lakukan resolusi lengkap dengan resolver yang memiliki cache segar atau alat validasi independen sehingga cache lama yang berhasil tidak menyembunyikan kecacatan tersebut. Bandingkan serial SOA, record DNSKEY, dan tanda tangan pada setiap otoritas serta catat sisa masa berlaku tanda tangan.

Validasi aplikasi berikutnya: health check, sertifikat TLS, permintaan terautentikasi, dan API penting pada alamat lama dan baru harus berfungsi. Keberhasilan DNS dengan endpoint baru yang salah dikonfigurasi adalah pemulihan yang tidak lengkap. Amati tingkat kegagalan, lalu lintas ke alamat lama, RCODE, latensi pencarian, dan kesalahan bisnis untuk jendela TTL dan tanda tangan asli hingga lalu lintas cache lama konvergen. Cakup A, AAAA, CNAME, dan jenis record lainnya yang digunakan oleh layanan.

Simpan linimasa publikasi, kegagalan validator pertama, bukti akar penyebab, keputusan keamanan, pemulihan induk/anak, dan konvergensi TTL. Tutup insiden hanya setelah validasi independen dan hasil pengguna keduanya telah pulih.

Langkah 6: Ubah rollover menjadi proses rilis yang dapat diuji (falsifiable)

Lakukan pra-publikasi DNSKEY baru agar server otoritatif dan cache dapat mengamatinya. Perbarui DS induk saat rantai lama masih valid, tunggu TTL dan alur kerja registrasi yang relevan, validasi rantai lama dan baru yang dapat diterima secara terus-menerus, dan baru kemudian hentikan DS, tanda tangan, dan kunci lama. Urutan pastinya harus mengikuti prosedur yang didukung penyedia dan registri; jumlah menit tunggu yang tetap bukanlah aturan universal.

Release gate harus membuktikan bahwa setiap penandatangan produksi mempublikasikan data DNSKEY dan tanda tangan yang saling valid dan didukung; DS induk mencapai kunci yang dituju; record RRSIG memiliki sisa masa berlaku yang memadai; sampel RRset bisnis tervalidasi; dan peringatan mencapai penanggung jawab manusia. Laporan DENIC tahun 2026 juga menunjukkan cacat yang memerlukan beberapa HSM dan lolos dari pengujian single-HSM, sementara peringatan validasi yang ada tidak ditangani dengan benar. Oleh karena itu, pencegahan membutuhkan cakupan topologi produksi dan pengujian loop peringatan secara berkala.

Contoh Jawaban Berkualitas Tinggi

“Pertama-tama saya akan mengidentifikasi resolver rekursif, jenis kueri, dan timestamp yang digunakan oleh klien yang gagal dan menyimpan respons lengkapnya. Untuk resolver yang sama, api.example.com A +dnssec mengembalikan SERVFAIL, sementara menambahkan +cd mengembalikan A dan RRSIG. Kontras terkontrol tersebut memprioritaskan validasi DNSSEC. Respons CD masih belum tepercaya dan tidak dapat diteruskan ke aplikasi produksi.

Saya akan menggunakan +trace untuk mengamati delegasi sebenarnya, melakukan kueri DS langsung dari induk, dan kueri DNSKEY, SOA, A, serta RRSIG dari setiap otoritas anak. Saya akan menguji apakah algoritma dan digest DS induk cocok dengan DNSKEY, apakah semua otoritas berbagi serial yang sama, apakah setiap key tag dan rentang waktu RRSIG masuk akal, dan di mana validator independen melabeli rantai tersebut sebagai bogus. Jawaban otoritas langsung tidak membuktikan rantai tersebut, karena server tersebut hanya menyediakan record sementara validator rekursif masih harus menghubungkan kunci anak ke DS induk dan trust anchor.

DS 18200 pada skenario tidak memiliki DNSKEY yang cocok, dan digest-nya tidak cocok dengan kunci 51900, menunjukkan bahwa kunci lama dihentikan terlalu dini. Saya akan membekukan perubahan, memulihkan DNSKEY lama dan tanda tangan valid yang cocok dengan DS saat ini dari sistem kunci yang dikontrol, memvalidasinya secara terisolasi, dan mempublikasikan status yang konsisten dari semua otoritas. Jika kunci lama tidak dapat dipulihkan, pemilik keamanan dan registrar harus mengoordinasikan perbaikan DS. Saya tidak akan menonaktifkan validasi secara global atau berasumsi bahwa flush cache global itu ada.

Setelah pemulihan, saya akan menjalankan kueri cold dan warm dari berbagai wilayah dan resolver pemvalidasi independen, memeriksa RCODE, status terautentikasi, A/AAAA/CNAME, TTL, dan serial otoritas. Saya juga akan menguji TLS dan API penting pada alamat lama dan baru. Klien mungkin secara sah menggunakan IP lama selama masa TTL-nya, sehingga endpoint tersebut tetap kompatibel hingga lalu lintas konvergen. Terakhir, saya akan menambahkan pra-publikasi kunci, rantai yang tumpang tindih, release gate DS induk, pemantauan kedaluwarsa tanda tangan, pemeriksaan konsistensi multi-otoritas, latihan topologi produksi, dan pengiriman peringatan yang terverifikasi ke dalam proses rollover.”

Kesalahan Umum

• Mengubah server aplikasi segera setelah melihat SERVFAIL → DNS belum menghasilkan alamat yang tepercaya, sehingga aplikasi mungkin tidak menerima lalu lintas sama sekali → Pastikan resolver-nya dan periksa RCODE, EDE, serta delegasi terlebih dahulu.
• Memperlakukan keberhasilan +cd sebagai data tepercaya → CD melewati validasi dan dapat mengembalikan data yang rusak → Gunakan hanya sebagai kontrol, lalu validasi DS, DNSKEY, dan RRSIG.
• Mengesampingkan DNSSEC karena kueri otoritas langsung berhasil → Otoritas dapat menyajikan data yang tidak tervalidasi melalui rantai induk → Uji ketersediaan data dan validasi kriptografis secara terpisah.
• Hanya membandingkan key tag → Key tag hanya memilih kandidat tetapi tidak menggantikan validasi algoritma dan digest → Hitung atau validasi hubungan lengkap DS-ke-DNSKEY secara independen.
• Menyebut IP lama dan SERVFAIL sebagai satu bug cache → Cache lama yang valid dan validasi baru yang gagal dapat terjadi bersamaan → Segmentasikan pengamatan berdasarkan resolver, usia cache, dan TTL.
• Menghapus kunci lama secara langsung selama rollover → Record DS induk dan cache rekursif mungkin masih bergantung pada rantai lama → Pertahankan rantai yang tumpang tindih hingga gate validasi dan TTL terlewati.
• Menonaktifkan DNSSEC secara global sebagai mitigasi → Resolusi kembali pulih dengan mengorbankan autentikasi → Pulihkan rantai yang terbukti baik terlebih dahulu; batasi cakupan, batasi waktu, setujui, dan cabut pengecualian apa pun.
• Menurunkan TTL setelah publikasi → Jawaban yang di-cache terus menggunakan TTL yang mereka terima sebelumnya → Rencanakan TTL sebelum migrasi dan jaga kompatibilitas endpoint lama selama insiden.
• Hanya menguji dig, bukan produknya → IP baru masih dapat memiliki kegagalan sertifikat, perutean, atau konfigurasi → Verifikasi resolusi, TLS, API penting, dan tingkat kesalahan pengguna.
• Hanya menguji satu penandatangan → Jalur produksi multi-node atau multi-HSM dapat menghasilkan output yang berbeda → Latih topologi nyata dan bandingkan setiap node penandatangan.

Pertanyaan Lanjutan dan Cara Menjawabnya

Lanjutan 1: Bagaimana Anda membedakan dengan cepat antara NXDOMAIN, jawaban kosong, dan SERVFAIL?

Periksa RCODE dan bagian Authority. NXDOMAIN menyatakan bahwa nama yang di-query tidak ada. NOERROR dengan Answer yang kosong dapat berarti bahwa nama tersebut ada tanpa jenis yang diminta, biasanya disertai SOA. SERVFAIL berarti server tidak dapat menghasilkan hasil yang dapat diterima; data DNSSEC bogus, timeout upstream, kegagalan delegasi, dan kesalahan internal semuanya dapat menyebabkannya. Tentukan lapisan mana yang menghasilkan respons dan apakah jawaban negatif memiliki bukti penolakan yang diautentikasi (authenticated denial of existence), daripada hanya mengandalkan pesan browser.

Lanjutan 2: Mengapa beberapa resolver berhasil sementara yang lain gagal?

Bandingkan apakah mereka memvalidasi DNSSEC, RRset mana yang mereka cache, kapan masa berlakunya habis, upstream mereka, jam, dan kebijakan lokal. Resolver yang berhasil mungkin masih menyajikan cache pra-rollover yang valid atau mungkin tidak melakukan validasi. Resolver yang gagal mungkin telah me-refresh dan mendapati rantai yang rusak. Keberagaman resolver adalah sebuah petunjuk; perilaku CD/AD, record mentah, dan usia cache melengkapi atribusi masalah.

Lanjutan 3: Bisakah flushing cache memulihkan setiap pengguna secara instan?

Operator hanya dapat melakukan flush pada browser, sistem operasi, atau resolver rekursif yang dikendalikannya. Resolver dan endpoint eksternal mengikuti TTL yang telah mereka terima, dan pemilik domain tidak memiliki API flush global. Memulihkan rantai bertanda tangan yang terbukti baik sambil menjaga kompatibilitas endpoint lama menangani kueri cold dan klien dengan jawaban lama. Pengurangan TTL pra-migrasi hanya berfungsi jika dilakukan cukup awal agar TTL sebelumnya kedaluwarsa.

Lanjutan 4: Bagaimana perbedaan batas rollover KSK dan ZSK?

Penerapan umum menggunakan KSK untuk menandatangani RRset DNSKEY dan ZSK untuk menandatangani RRset bisnis seperti A dan AAAA. Rollover KSK melintasi batas DS induk sehingga melibatkan organisasi dan cache yang berbeda. Rollover ZSK biasanya berada di dalam zona anak tetapi tetap memerlukan validitas DNSKEY dan RRSIG yang tumpang tindih. Penyedia dapat menggunakan model kunci yang berbeda, jadi simpulkan jawaban dari flag DNSKEY aktual, penandatangan, dan prosedur yang didukung alih-alih menerapkan label secara mekanis.

Lanjutan 5: Release gate apa yang akan Anda tambahkan ke DNSSEC rollover?

Jalankan rollover di lingkungan pra-produksi dengan topologi yang setara dengan produksi dan buktikan bahwa setiap penandatangan menghasilkan output yang saling valid. Sebelum rilis, periksa DS induk, DNSKEY anak, algoritma yang didukung, inception/expiration RRSIG, serial SOA, dan konsistensi otoritas, lalu jalankan kueri cold melalui setidaknya dua validator independen. Peringatan membutuhkan penanggung jawab yang jelas, jalur eskalasi, dan prosedur rollback yang telah dilatih. Injeksikan tanda tangan kedaluwarsa, kunci yang hilang, dan ketidakkonsistenan node untuk membuktikan bahwa insiden akan terdeteksi dan tertangani.