Gesaan dan skop
Reka bentuk satah kawalan DNS berwibawa untuk SaaS berbilang penyewa. Pengguna menyerahkan rekod A, AAAA, CNAME dan TXT. Sistem mengesahkan konflik, mencipta versi zon, memberitahu nod berwibawa, dan menyokong AXFR/IXFR, DNSSEC, pelancaran, pengunduran dan audit.
Perkara yang dinilai oleh penemu duga
- Mengasingkan satah kawalan, satah perkhidmatan berwibawa dan penyelesai rekursif.
- Menggunakan versi zon tidak boleh ubah (immutable) dan penerbitan atomik.
- Menyambungkan siri SOA, NOTIFY, AXFR dan IXFR.
- Pengasingan penyewa, pembenaran (authorization), perlindungan kunci DNSSEC dan pencegahan keluaran bermasalah.
- Mengendalikan nod yang ketinggalan, penerbitan separa, pemuatan cache negatif dan pengunduran.
Penjelasan untuk ditanya terlebih dahulu
Sahkan bilangan zon, kadar penulisan, SLO penyebaran, DNSSEC, geografi nod, model pembenaran dan kelulusan, serta sama ada nod lama hanya menyokong AXFR. Jika tidak dinyatakan, anggap kluster berwibawa teragih secara global dengan keterlihatan peringkat minit.
Rangka kerja jawapan tiga puluh saat
Tulis rekod ternormal dalam satah kawalan, cipta versi zon yang tidak boleh ubah, sahkan dan tukar nod berwibawa secara atomik. Tingkatkan siri SOA; NOTIFY mencetuskan IXFR, dengan AXFR sebagai sandaran. Setiap keluaran mempunyai keadaan, bukti audit dan penunjuk pengunduran. DNSSEC, pembenaran penyewa dan pemantauan penyebaran merupakan pintu kawalan keluaran (release gates).
Perbincangan mendalam langkah demi langkah
1. Asingkan satah
Satah kawalan menyimpan penyewa, zon, rekod dan versi. Satah perkhidmatan hanya menjawab daripada versi yang diterbitkan. Penyelesai rekursif berada di luar laluan penulisan, dan TTL mewujudkan kelewatan keterlihatan. Sesuatu versi merangkumi data zon kanonikal, siri SOA, checksum, keadaan menandatangani dan sasaran.
2. Reka bentuk penulisan dan pengesahan
Tulis transaksi calon dan sahkan nama, TTL, kekangan jenis, konflik CNAME, sempadan delegasi dan kuota penyewa. Perubahan kelompok membawa id keidempotensian dan versi optimistik. Pengesahan yang gagal tidak akan mencipta versi yang boleh diterbitkan.
3. Jana dan terbitkan secara atomik
Jana struktur zon dan jalankan semakan sintaks, delegasi, kitaran dan DNSSEC. Simpan objek beralamat kandungan (content-addressed) yang telah disahkan dan checksum. Nod menukar penunjuk versi secara atomik, mengelakkan jawapan lama dan baharu bercampur.
4. Penyebaran dan nod yang ketinggalan
Nod utama meningkatkan siri dan menghantar NOTIFY. Nod sekunder meminta IXFR, beralih kepada AXFR apabila rantai delta tidak tersedia atau gagal disahkan. Nod melaporkan siri, checksum dan keadaan menandatangani. Nod yang ketinggalan akan disalirkan (drained) atau menyajikan versi lama yang telah disahkan; ia tidak boleh menyajikan zon kosong secara senyap.
5. TTL, pemuatan cache negatif dan pengunduran
TTL mengawal pemuatan cache rekursif, dan respons NXDOMAIN dicache secara negatif. Sediakan sasaran baharu sebelum menukar TTL; memadamkan rekod berwibawa tidak mengosongkan cache luaran serta-merta. Undur semula kepada versi lama yang disahkan dengan siri yang lebih tinggi dan bukannya menggunakan semula siri lama.
6. Keselamatan dan pengasingan penyewa
Gunakan RBAC skop zon, kelulusan dan kawalan dwi. Sahkan API kemas kini dalaman dan cegah ulangan (replay). Simpan kunci DNSSEC dalam KMS atau HSM dan sekat keluaran apabila proses menandatangani gagal. Audit pelaku, permintaan, versi, siri dan keputusan tanpa menyimpan rahsia penyewa.
7. Kebolehcerapan dan latih tubi
Pantau kependaman penerbitan, pencongan siri (serial skew), nisbah IXFR/AXFR, kegagalan menandatangani, SERVFAIL, perubahan NXDOMAIN, kejayaan pertanyaan dan pengedaran serantau. Lakukan latih tubi kegagalan nod utama, pemisahan rangkaian, sejarah delta yang hilang, zon rosak, giliran kunci dan pengunduran sambil membuktikan bahawa versi lama yang telah disahkan kekal tersedia.
Contoh jawapan berkualiti tinggi
Saya akan mengekalkan versi zon tidak boleh ubah yang diasingkan mengikut penyewa dalam satah kawalan dan membiarkan nod berwibawa menyajikan satu versi yang disahkan. Sahkan nama, TTL, konflik CNAME, delegasi dan kuota dengan permintaan kelompok idempoten dan versi optimistik. Jana zon kanonikal, sahkan sintaks, DNSSEC dan checksum, kemudian tukar penunjuk secara atomik.
Nod utama meningkatkan siri dan menghantar NOTIFY; nod sekunder mengutamakan IXFR dan beralih kepada AXFR. Nod melaporkan siri, checksum dan keadaan menandatangani. TTL dan pemuatan cache negatif menentukan keterlihatan luaran, manakala pengunduran menggunakan siri yang lebih baharu. RBAC, kelulusan, KMS/HSM, audit, pemantauan SERVFAIL dan pencongan siri, serta latih tubi pemisahan dan giliran kunci bertindak sebagai pintu kawalan keluaran.
Kesilapan lazim
- Menganggap kelewatan cache rekursif sebagai kegagalan satah kawalan.
- Mengedit fail zon kongsi secara terus dan menyajikan penulisan separa.
- Menganggap NOTIFY bermakna penyebaran telah selesai sepenuhnya.
- Menyajikan zon kosong selepas IXFR gagal.
- Menggunakan semula siri SOA lama semasa pengunduran.
- Memberikan penyewa akses terus kepada kunci peribadi DNSSEC.
- Mengabaikan pemantauan NXDOMAIN dan SERVFAIL.
Soalan susulan dan respons
Soalan susulan 1: Mengapakah siri SOA mesti meningkat?
Nod dan cache membandingkan siri untuk menentukan kesegaran data. Pengunduran juga memerlukan siri yang lebih tinggi supaya ia tidak disalah anggap sebagai versi lama.
Soalan susulan 2: Bagaimana jika IXFR tidak dapat mencari delta?
Minta AXFR. Jika pemindahan gagal, kekalkan versi yang disahkan dan keluarkan amaran; jangan sesekali menyajikan zon kosong.
Soalan susulan 3: Apakah yang anda lakukan dengan nod yang jauh ketinggalan?
Bandingkan siri dan checksum, salirkannya atau kekalkannya pada versi lama yang disahkan, kemudian selaraskannya dengan AXFR dan pertanyaan sampel.
Soalan susulan 4: Bolehkah anda menerbitkan data yang tidak ditandatangani selepas proses menandatangani DNSSEC gagal?
Jika kontrak zon memerlukan tandatangan, sekat penerbitan dan baiki kunci atau rantai tersebut. Jangan turun taraf keselamatan secara senyap.