Temu Duga Rangkaian: Bagaimana Anda Menyelesaikan Masalah SERVFAIL Selepas Rollover DNSSEC?

Prompt dan Masa Ia Terpakai

Pada 21:00 UTC, example.com melakukan rollover kunci DNSSEC dan menukar rekod A untuk api.example.com daripada 192.0.2.20 kepada 192.0.2.40. Sepuluh minit kemudian, klien yang menggunakan beberapa penyelesai rekursif yang mengesahkan menerima SERVFAIL. Menambah +cd pada pertanyaan penyelesai yang sama mengembalikan alamat baharu dan RRSIG, dan pertanyaan langsung kepada pelayan autoritatif juga menerima respons. Klien lain terus menggunakan alamat lama. Induk pada masa ini menerbitkan DS dengan tag kunci 18200, manakala zon anak hanya menerbitkan DNSKEY dengan tag kunci 51900. Diagnosis, pulihkan, dan sahkan insiden tersebut tanpa meninggalkan sempadan pengesahan DNSSEC atau mengedarkan jawapan yang tidak dipercayai kepada pengguna.

Domain, alamat, tag kunci, masa, dan perubahan adalah andaian temu duga. 192.0.2.0/24 ialah blok alamat dokumentasi. Tugas utamanya adalah untuk mendapatkan status setiap lapisan resolusi DNS dan rantaian amanah DNSSEC daripada simptom yang boleh diperhatikan. Gangguan aplikasi tidak seharusnya disimpulkan daripada SERVFAIL sahaja. Soalan ini sesuai untuk peranan SRE, infrastruktur, rangkaian, keselamatan, bahagian belakang (backend), dan kejuruteraan perisian umum, jadi kategorinya adalah umum.

Perbincangan awam 2025 tentang temu duga peranan kanan masih menganggap pengetahuan DNS dan DNSSEC sebagai bahan temu duga yang relevan. Bukti tersebut menetapkan konteks temu duga semasa; ia tidak menetapkan kekerapan atau soalan majikan yang tetap. Laporan 2026 DENIC mengenai gangguan DNS .de mendokumenkan kecacatan rollover yang menyebabkan kebanyakan tandatangan tidak dapat disahkan dan menyebabkan penyelesai pengesahan menolak delegasi yang terjejas. Oleh itu, kegagalan kunci, tandatangan, dan pengesahan kekal nyata secara operasi.

Artikel sedia ada "apa yang berlaku apabila anda menaip URL" merangkumi kes biasa di mana klien mewakilkan kerja rekursif dan cache memendekkan laluan. Artikel SSRF memberi tumpuan kepada memberi kebenaran kepada alamat yang diselesaikan dan menutup jurang DNS-rebinding. Soalan ini memberi tumpuan kepada rekod DS induk, rekod DNSKEY/RRSIG anak, status pengesahan, susunan pemulihan yang selamat, dan pengesahan merentas penyelesai. Lapisan kegagalan dan invarian keselamatannya adalah berbeza.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah diagnosis berlapis. Kegagalan resolusi nama boleh berpunca daripada stub tempatan, penyelesai rekursif korporat atau awam, delegasi induk, pelayan autoritatif, pengesahan DNSSEC, atau data akhir A, AAAA, atau CNAME. Jawapan yang kukuh mengekalkan nama pertanyaan, jenis, masa, dan penyelesai secara malar, mengumpulkan RCODE, jawapan, TTL, data autoriti, dan rekod DNSSEC pada setiap lapisan, dan mengenal pasti titik pertama di mana pemerhatian menyimpang.

Isyarat kedua ialah tafsiran kod respons yang tepat. NXDOMAIN bermaksud rantaian autoritatif mendakwa bahawa nama yang ditanya tidak wujud. NOERROR dengan jawapan kosong boleh bermakna nama itu wujud tetapi tiada rekod jenis tersebut. Tamat masa bermakna tiada respons yang boleh digunakan tiba dalam bajet masa. REFUSED bermaksud pelayan menolak pertanyaan tersebut. SERVFAIL ialah kegagalan pelayan generik. Pengesahan DNSSEC yang gagal boleh menghasilkan SERVFAIL, tetapi satu kod status tidak boleh membuktikan punca tersebut.

Isyarat ketiga ialah pemahaman tentang rantaian amanah (chain of trust). Rekod DS berada pada titik delegasi sebelah induk dan menghubungkan rantaian dipercayai induk kepada DNSKEY anak. Rekod RRSIG menandatangani RRset dalam zon anak, manakala pengesah (validator) juga menyemak algoritma, digest, batas masa tandatangan, dan sauh amanah (trust anchor). Tag kunci membantu mencari kunci calon; ia bukan bukti kriptografi. Jawapan mesti mengesahkan bahawa digest DS sepadan dengan DNSKEY sebenar dan kunci yang diterbitkan mengesahkan tandatangan yang berkaitan.

Isyarat keempat ialah perbandingan terkawal. Terhadap penyelesai rekursif yang sama, pertanyaan normal +dnssec yang gagal manakala pertanyaan +cd mengembalikan rekod mentah memberikan implikasi kuat terhadap laluan pengesahan. CD meminta penyelesai menyahdayakan semakan untuk pertanyaan tersebut dan berguna untuk diagnosis. Ia tidak menjadikan data yang dikembalikan boleh dipercayai dan bukan jalan pintas pengeluaran. Bit AD daripada penyelesai pengesahan yang dipercayai boleh mendakwa data yang disahkan (authenticated data). Ketiadaan AD juga boleh mencerminkan permintaan klien, dasar penyelesai, atau sempadan amanah, jadi ia mesti ditafsirkan bersama bukti yang lain.

Akhir sekali, penemu duga mencari disiplin pemulihan. Jika kunci lama yang dirujuk oleh DS induk semasa ditamatkan terlalu awal, laluan selamat yang paling pantas selalunya adalah memulihkan DNSKEY dan tandatangan sah yang boleh disahkan oleh DS semasa, kemudian menyambung semula rollover dengan tetingkap bertindih (overlap window). Menyahdayakan pengesahan secara global, mengosongkan cache sewenang-wenangnya, atau mengedit rekod A berulang kali meluaskan risiko. Selepas pemulihan, TTL sedia ada masih perlu menumpu (converge), dan pengesah bebas mesti membuktikan kedua-dua rantaian yang kukuh dan aplikasi yang berfungsi.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah impak menjejaskan satu nama, seluruh zon, atau banyak zon di bawah satu TLD? Skop menentukan sama ada hendak bermula dengan perubahan zon anak, penyedia autoritatif, atau insiden induk/pendaftar (registry).
• Penyelesai rekursif manakah yang sebenarnya digunakan oleh klien yang gagal? DNS disulitkan pelayar, pemaju (forwarder) korporat, VPN, dan tetapan sistem pengendalian boleh menghantar klien ke laluan yang berbeza dari rangkaian yang sama.
• Apakah RCODE, EDE, jenis pertanyaan, dan masa bagi setiap kegagalan? Kejayaan A dengan kegagalan AAAA, lompatan CNAME yang rosak, atau kegagalan yang terhad kepada penyelesai pengesahan menghasilkan cabang yang berbeza.
• Apakah nilai NS, DS, DNSKEY, RRSIG, dan TTL sebelum dan selepas perubahan? Susunan rollover, jangka hayat cache maksimum, dan kunci lama yang boleh dipulihkan menentukan mitigasi.
• Adakah semua pelayan autoritatif mengembalikan siri SOA dan RRset bertandatangan yang sama? Ketidaksejajaran versi dalam kalangan pelayan autoriti boleh mewujudkan hasil yang sekejap-sekejap; satu pelayan tidak mewakili keseluruhan zon.
• Adakah jam penyelesai dan penandatangan tepat? Rekod RRSIG mempunyai masa permulaan (inception) dan tamat tempoh, jadi ralat jam yang ketara boleh menyebabkan kegagalan pengesahan.
• Bolehkah IP lama terus memberi perkhidmatan kepada trafik dengan selamat? Jika ya, kekalkan keserasian semasa penumpuan TTL. Jika tidak, uruskan risiko sambungan tersebut secara berasingan kerana DNS tidak boleh membatalkan jawapan yang dicache secara paksa.
• Siapa yang mengawal DS induk dan perubahan kecemasan? Pendaftar (registrar), registry, penyedia DNS, dan pasukan on-call dalaman mempunyai kebenaran dan masa tindak balas yang berbeza.

Rangka Kerja Jawapan 30 Saat

"Saya akan mengenal pasti penyelesai rekursif klien yang gagal dan merekodkan RCODE, EDE, data A/AAAA/CNAME, TTL, dan cap masa. Terhadap penyelesai yang sama, SERVFAIL secara normal dan data dengan +cd mengarahkan saya ke laluan pengesahan DNSSEC. Saya akan mendapatkan DS daripada induk dan DNSKEY, RRSIG, dan SOA daripada setiap pelayan autoritatif, kemudian membandingkan digest, algoritma, masa tandatangan, dan ketekalan nod. Di sini DS induk tidak mempunyai DNSKEY anak yang sepadan, konsisten dengan tindakan menamatkan kunci lama terlalu awal. Saya akan terlebih dahulu memulihkan kunci dan tandatangan yang diketahui baik yang sepadan dengan DS semasa. Selepas beberapa pengesah mengembalikan jawapan yang disahkan, saya akan memantau penumpuan TTL dan menambah rollover bertindih, pengesahan praterbitan, makluman tamat tempoh tandatangan, dan pemeriksaan sintetik pelbagai sudut pandang."

Jawapan Mendalam Langkah Demi Langkah

Langkah 1: Tetapkan sempadan kegagalan dan kawalan

Rekodkan masa, rangkaian klien, penyelesai rekursif sebenar, nama pertanyaan, dan jenis pertanyaan untuk satu kegagalan. Pintas cache aplikasi dan pelayar dan buat pertanyaan kepada penyelesai yang digunakan oleh klien. Kemudian pilih penyelesai pengesahan bebas sebagai kawalan. Jangan ubah nama, jenis, dan penyelesai secara serentak, kerana perbezaan tersebut tidak lagi mengasingkan pemboleh ubah.

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

Kekalkan status, bendera, Answer, Authority, Additional, TTL, dan sebarang Extended DNS Error EDNS daripada respons penuh. Jika A disahkan manakala AAAA gagal, periksa AAAA dan rantaian CNAME miliknya. Jika setiap jenis mengalami tamat masa, periksa terlebih dahulu kebolehcapaian rangkaian, port 53, ketersediaan autoritatif, dan pengendalian saiz paket. Jika hanya satu penyelesai rekursif gagal, cache, dasar, jam, atau rantaian pemajuannya kekal sebagai calon punca masalah.

Klien yang masih mencapai IP lama bukanlah bukti yang bercanggah. RRset A lama boleh diguna semula sehingga TTL-nya tamat, dan tandatangan yang mengiringinya mungkin masih sah. TTL tidak boleh dipendekkan secara retroaktif selepas penerbitan, jadi pastikan titik akhir lama selamat dan serasi sepanjang tetingkap cache yang diketahui.

Langkah 2: Gunakan perbandingan CD untuk memasuki cabang DNSSEC

Ulangi nama dan jenis yang sama terhadap penyelesai gagal yang sama dengan CD ditetapkan:

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

Jika pertanyaan normal mengembalikan SERVFAIL tetapi +cd mengembalikan rekod A, DNSKEY, atau RRSIG, kegagalan pengesahan menjadi hipotesis utama. Penyelesaian masalah domain Google Public DNS menggunakan kontras yang sama—Status 2 dengan kejayaan apabila pengesahan dinyahdayakan—untuk mengenal pasti masalah DNSSEC yang berkemungkinan, dan Extended DNS Errors boleh memberikan sebab yang lebih khusus. Teruskan memeriksa laluan mentah kerana tamat masa autoritatif, gelung delegasi, dan kerosakan pelayan lain juga boleh menghasilkan SERVFAIL.

+cd mendedahkan data yang sebaliknya akan ditolak oleh penyelesai. Menghalakan aplikasi ke penyelesai yang tidak mengesahkan atau menyahdayakan DNSSEC secara global mengubah insiden ketersediaan menjadi risiko integriti. Jika seorang komander insiden menggunakan pengecualian pengesahan semasa gangguan hulu yang luas, ia masih memerlukan skop domain yang sempit, had masa, risiko yang direkodkan, dan kriteria keluar yang jelas.

Langkah 3: Periksa delegasi, data autoritatif, dan tandatangan secara berasingan

Mula-mula gunakan trace untuk menyenaraikan laluan sebenar melalui delegasi root, induk, dan anak. Trace ialah pemerhatian terhadap laluan pertanyaan, bukan hasil pengesahan kriptografi yang lengkap. Buat pertanyaan DS terus daripada autoriti induk, dan buat pertanyaan DNSKEY, SOA, dan RRset perniagaan daripada setiap autoriti 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 pertanyaan untuk setiap autoriti dan bandingkan set NS, glue, siri SOA, RRset DNSKEY, dan rekod RRSIG. Pelayan autoritatif yang mengembalikan A dan RRSIG membuktikan bahawa ia menyediakan data. Pelayan autoritatif secara amnya tidak mengesahkan rantaian lengkap daripada sauh amanah induk bagi pihak peminta. Oleh itu, kejayaan autoriti langsung dan kegagalan pengesahan rekursif boleh wujud bersama.

Semak bahawa pemilik DS induk, algoritma, jenis digest, dan digest sepadan dengan DNSKEY anak; bahawa RRset DNSKEY mempunyai tandatangan yang sah pada masa ini; bahawa RRSIG RRset A perniagaan mempunyai tag kunci, algoritma, masa permulaan, dan tamat tempoh yang munasabah; dan bahawa setiap zon bertandatangan dalam rantaian CNAME boleh mewujudkan rantaian. Pengesah bebas boleh mengenal pasti nod yang gagal, selepas itu rekod mentah harus mengesahkannya.

Dalam senario ini, tag kunci DS induk 18200 tidak mempunyai calon dalam RRset DNSKEY anak, dan digest miliknya tidak sepadan dengan kunci semasa 51900. Korelasi dengan masa perubahan menunjukkan bahawa KSK/DNSKEY lama telah dialih keluar sebelum DS induk menyelesaikan peralihan yang selamat. Ketidakpadanan tag ialah petunjuk; perbandingan digest dan pengesahan tandatangan melengkapkan bukti.

Langkah 4: Pulihkan dalam sempadan keselamatan

Bekukan rollover automatik dan perubahan DNS yang tidak berkaitan. Kekalkan log perubahan, snapshot zon, pengecam kunci, dan respons yang gagal. Jika kunci peribadi sebelumnya kekal dalam sistem kunci terkawal, pulihkan DNSKEY miliknya dan jana tandatangan yang diketahui baik yang mewujudkan rantaian melalui DS induk semasa. Ini selalunya lebih pantas daripada menunggu perubahan induk. Sahkan rantaian lengkap secara terasing sebelum menerbitkan status yang sama daripada semua autoriti.

Jika kunci lama tidak dapat dipulihkan, pemilik DNS dan keselamatan mesti menyelaraskan pembetulan DS induk dengan pendaftar dan mengambil kira masa penyebaran. Mengalih keluar DS mengembalikan anak kepada status tidak bertandatangan, melemahkan jaminan pengesahannya, dan masih mempunyai kependaman cache dan perubahan induk. Ia adalah pilihan pemulihan yang diluluskan, didokumenkan, dan diskopkan, bukan jalan pintas yang mudah. Menjana kunci baharu dengan hanya tag kunci yang sama tidak boleh berfungsi—digest tidak akan sepadan.

Jika titik akhir A lama kekal selamat, teruskan memberi perkhidmatan melaluinya sepanjang tetingkap TTL RRset lama. Titik akhir lama dan baharu mesti menggunakan dasar konfigurasi dan pengesahan kritikal yang serasi. Pengosongan cache hanya boleh menjejaskan penyelesai di bawah kawalan pengendali, jadi pemulihan tidak boleh bergantung pada pengosongan global yang tidak wujud.

Langkah 5: Buktikan bahawa DNS dan aplikasi telah pulih

Tanya nama yang telah dibetulkan daripada penyelesai rekursif pengesahan dan wilayah bebas. Sahkan bahawa SERVFAIL telah tiada, jawapan adalah seperti yang dijangkakan, dan hasil pengesahan yang dipercayai hadir. Kemudian lakukan resolusi lengkap dengan penyelesai cache segar atau alat pengesahan bebas supaya cache lama yang berjaya tidak menyembunyikan kecacatan tersebut. Bandingkan siri SOA, rekod DNSKEY, dan tandatangan pada setiap autoriti dan rekod baki jangka hayat tandatangan.

Sahkan aplikasi seterusnya: pemeriksaan kesihatan, sijil TLS, permintaan yang disahkan, dan API kritikal pada alamat lama dan baharu mesti berfungsi. Kejayaan DNS dengan titik akhir baharu yang tersalah konfigurasi ialah pemulihan yang tidak lengkap. Perhatikan kadar kegagalan, trafik ke alamat lama, RCODE, kependaman carian, dan ralat perniagaan untuk tetingkap TTL dan tandatangan asal sehingga trafik cache lama menumpu. Lindungi A, AAAA, CNAME, dan sebarang jenis rekod lain yang digunakan oleh perkhidmatan tersebut.

Kekalkan garis masa penerbitan, kegagalan pengesah pertama, bukti punca utama, keputusan keselamatan, pemulihan induk/anak, dan penumpuan TTL. Tutup insiden hanya selepas pengesahan bebas dan hasil pengguna kedua-duanya telah pulih.

Langkah 6: Ubah rollover menjadi proses pelepasan yang boleh difalsifikasi

Praterbitkan DNSKEY baharu supaya pelayan autoritatif dan cache dapat memerhatikannya. Kemas kini DS induk semasa rantaian lama masih sah, tunggu TTL yang berkaitan dan aliran kerja pendaftaran, sahkan secara berterusan rantaian lama dan baharu yang boleh diterima, dan hanya selepas itu tamatkan DS, tandatangan, dan kunci lama. Urutan yang tepat mesti mengikut prosedur yang disokong oleh penyedia dan registry; satu jumlah minit menunggu yang tetap bukanlah peraturan sejagat.

Pintu pelepasan (release gates) harus membuktikan bahawa setiap penandatangan pengeluaran menerbitkan data DNSKEY dan tandatangan yang sah dan disokong bersama; DS induk mencapai kunci yang dimaksudkan; rekod RRSIG mempunyai baki jangka hayat yang mencukupi; sampel RRset perniagaan disahkan; dan makluman sampai kepada pemilik manusia. Laporan 2026 DENIC juga menunjukkan kecacatan yang memerlukan pelbagai HSM dan terlepas daripada ujian HSM tunggal, manakala makluman pengesahan sedia ada tidak dikendalikan dengan betul. Oleh itu, pencegahan memerlukan liputan topologi pengeluaran dan gelung makluman yang dipraktikkan.

Contoh Jawapan Berkualiti Tinggi

"Mula-mula saya akan mengenal pasti penyelesai rekursif, jenis pertanyaan, dan cap masa yang digunakan oleh klien yang gagal dan menyimpan respons lengkap. Bagi penyelesai yang sama, api.example.com A +dnssec mengembalikan SERVFAIL, manakala menambah +cd mengembalikan A dan RRSIG. Kontras terkawal itu mengutamakan pengesahan DNSSEC. Respons CD masih tidak dipercayai dan tidak boleh diserahkan kepada aplikasi pengeluaran.

Saya akan menggunakan +trace untuk memerhatikan delegasi sebenar, membuat pertanyaan DS terus daripada induk, dan membuat pertanyaan DNSKEY, SOA, A, dan RRSIG daripada setiap autoriti anak. Saya akan menguji sama ada algoritma dan digest DS induk sepadan dengan DNSKEY, sama ada semua autoriti berkongsi siri, sama ada setiap tag kunci RRSIG dan julat masa adalah munasabah, dan di mana pengesah bebas melabelkan rantaian itu sebagai palsu (bogus). Jawapan autoriti langsung tidak membuktikan rantaian tersebut, kerana pelayan tersebut membekalkan rekod manakala pengesah rekursif masih perlu menyambungkan kunci anak kepada DS induk dan sauh amanah.

DS 18200 senario ini tidak mempunyai DNSKEY yang sepadan, dan digest miliknya tidak sepadan dengan kunci 51900, menunjukkan bahawa kunci lama telah ditamatkan terlalu awal. Saya akan membekukan perubahan, memulihkan DNSKEY lama dan tandatangan sah yang sepadan dengan DS semasa daripada sistem kunci terkawal, mengesahkannya secara terasing, dan menerbitkan status yang konsisten daripada semua autoriti. Jika kunci lama tidak dapat dipulihkan, pemilik keselamatan dan pendaftar mesti menyelaraskan pembetulan DS. Saya tidak akan menyahdayakan pengesahan secara global atau menganggap pengosongan cache global wujud.

Selepas pemulihan, saya akan menjalankan pertanyaan sejuk (cold) dan hangat (warm) dari pelbagai wilayah dan penyelesai pengesahan bebas, menyemak RCODE, status disahkan, A/AAAA/CNAME, TTL, dan siri autoriti. Saya juga akan menguji TLS dan API kritikal pada kedua-dua alamat lama dan baharu. Klien secara sah boleh menggunakan IP lama semasa TTL-nya, jadi titik akhir itu kekal serasi sehingga trafik menumpu. Akhir sekali, saya akan menambah praterbitan kunci, rantaian bertindih, pintu pelepasan DS induk, pemantauan tamat tempoh tandatangan, pemeriksaan ketekalan pelbagai autoriti, latihan topologi pengeluaran, dan penghantaran makluman yang disahkan kepada proses rollover."

Kesilapan Biasa

• Menukar pelayan aplikasi serta-merta selepas melihat SERVFAIL → DNS belum menghasilkan alamat yang dipercayai, jadi aplikasi mungkin tidak menerima sebarang trafik → Kenal pasti penyelesai dan periksa RCODE, EDE, dan delegasi terlebih dahulu.
• Menganggap kejayaan +cd sebagai data yang dipercayai → CD melangkau pengesahan dan boleh mengembalikan data yang rosak → Gunakan ia hanya sebagai kawalan, kemudian sahkan DS, DNSKEY, dan RRSIG.
• Mengetepikan DNSSEC kerana pertanyaan autoriti langsung berfungsi → Autoriti boleh menyediakan data yang tidak sah melalui rantaian induk → Uji ketersediaan data dan pengesahan kriptografi secara berasingan.
• Hanya membandingkan tag kunci → Tag kunci memilih calon tetapi tidak menggantikan pengesahan algoritma dan digest → Kira atau sahkan hubungan lengkap DS-ke-DNSKEY secara bebas.
• Memanggil IP lama dan SERVFAIL sebagai satu pepijat cache → Cache lama yang sah dan pengesahan baharu yang gagal boleh wujud bersama → Segmenkan pemerhatian mengikut penyelesai, usia cache, dan TTL.
• Memadam kunci lama serta-merta semasa rollover → Rekod DS induk dan cache rekursif masih boleh bergantung pada rantaian lama → Kekalkan rantaian bertindih sehingga pintu pengesahan dan TTL lulus.
• Menyahdayakan DNSSEC secara global sebagai mitigasi → Resolusi kembali pulih tetapi mengorbankan pengesahan → Pulihkan rantaian yang diketahui baik dahulu; skopkan, tetapkan had masa, luluskan, dan undurkan sebarang pengecualian.
• Menurunkan TTL selepas penerbitan → Jawapan yang dicache terus menggunakan TTL yang telah mereka terima → Rancang TTL sebelum migrasi dan pastikan titik akhir lama serasi semasa insiden.
• Hanya menguji dig, bukan produk → IP baharu masih boleh mengalami kegagalan sijil, penghalaan, atau konfigurasi → Sahkan resolusi, TLS, API kritikal, dan kadar ralat pengguna.
• Hanya menguji satu penandatangan → Laluan pengeluaran berbilang nod atau berbilang HSM boleh menjana hasil yang berbeza → Lakukan ujian pada topologi sebenar dan bandingkan setiap nod penandatanganan.

Soalan Susulan dan Cara Menjawab

Susulan 1: Bagaimanakah anda membezakan dengan cepat NXDOMAIN, jawapan kosong, dan SERVFAIL?

Periksa bahagian RCODE dan Authority. NXDOMAIN mendakwa nama yang ditanya tidak wujud. NOERROR dengan Answer kosong boleh bermakna nama tersebut wujud tanpa jenis yang diminta, biasanya dengan SOA. SERVFAIL bermaksud pelayan tidak dapat menghasilkan hasil yang boleh diterima; data DNSSEC bogus, tamat masa hulu, kegagalan delegasi, dan kerosakan dalaman semuanya boleh menyebabkannya. Tentukan lapisan mana yang menghasilkan respons dan sama ada jawapan negatif mempunyai bukti penafian yang disahkan (authenticated denial evidence) dan bukannya bergantung pada mesej pelayar.

Susulan 2: Mengapa sesetengah penyelesai berjaya manakala yang lain gagal?

Bandingkan sama ada mereka mengesahkan DNSSEC, RRset mana yang mereka cache, bila ia tamat tempoh, hulu mereka, jam, dan dasar tempatan. Penyelesai yang berjaya mungkin masih menyediakan cache prarollover yang sah atau mungkin tidak mengesahkan. Penyelesai yang gagal mungkin telah disegarkan dan menemui rantaian yang rosak. Kepelbagaian penyelesai adalah satu petunjuk; tingkah laku CD/AD, rekod mentah, dan usia cache melengkapkan atribusi.

Susulan 3: Bolehkah pengosongan cache memulihkan setiap pengguna serta-merta?

Pengendali hanya boleh mengosongkan pelayar, sistem pengendalian, atau penyelesai rekursif yang dikawalnya. Penyelesai luaran dan titik akhir mengikut TTL yang telah mereka terima, dan pemilik domain tidak mempunyai API pengosongan global. Memulihkan rantaian bertandatangan yang diketahui baik sambil mengekalkan titik akhir lama serasi meliputi kedua-dua pertanyaan sejuk dan klien dengan jawapan lama. Pengurangan TTL pramigrasi hanya berfungsi apabila dilakukan cukup awal supaya TTL sebelumnya sempat tamat.

Susulan 4: Bagaimanakah sempadan rollover KSK dan ZSK berbeza?

Penyebaran biasa menggunakan KSK untuk menandatangani RRset DNSKEY dan ZSK untuk menandatangani RRset perniagaan seperti A dan AAAA. Rollover KSK melintasi sempadan DS induk dan oleh itu merentasi organisasi dan cache. Rollover ZSK biasanya terkandung dalam zon anak tetapi masih memerlukan kesahan DNSKEY dan RRSIG yang bertindih. Penyedia boleh menggunakan model kunci yang berbeza, jadi dapatkan jawapan daripada bendera DNSKEY sebenar, penandatangan, dan prosedur yang disokong dan bukannya menggunakan label secara mekanikal.

Susulan 5: Apakah pintu pelepasan yang akan anda tambahkan pada rollover DNSSEC?

Jalankan rollover dalam persekitaran prapengeluaran dengan topologi yang setara dengan pengeluaran dan buktikan bahawa setiap penandatangan menghasilkan output yang sah bersama. Sebelum pelepasan, semak DS induk, DNSKEY anak, algoritma yang disokong, permulaan/tamat tempoh RRSIG, siri SOA, dan ketekalan autoriti, kemudian laksanakan pertanyaan sejuk melalui sekurang-kurangnya dua pengesah bebas. Makluman memerlukan pemilik dinamakan, laluan peningkatan (escalation), dan rollback yang dipraktikkan. Suntik tandatangan yang telah tamat tempoh, kunci yang hilang, dan ketidakkonsistenan nod untuk membuktikan bahawa insiden tersebut akan dikesan dan dikendalikan.