Topik wawancara representatif

Wawancara system design: control plane DNS otoritatif yang dapat diaudit

Desain sistemSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Rancang control plane DNS otoritatif untuk SaaS multi-tenant dengan perubahan batch, DNSSEC, AXFR/IXFR, rollback, dan propagasi tingkat menit. Cakup model data, protokol penerbitan, kegagalan, dan audit.

Petunjuk dan ruang lingkup

Rancang control plane DNS otoritatif untuk SaaS multi-tenant. Pengguna mengirimkan rekaman A, AAAA, CNAME, dan TXT. Sistem memvalidasi konflik, membuat versi zona, memberi tahu node otoritatif, dan mendukung AXFR/IXFR, DNSSEC, rollout, rollback, dan audit.

Apa yang dievaluasi pewawancara

  • Memisahkan control plane, authoritative serving plane, dan recursive resolver.
  • Menggunakan versi zona yang tidak dapat diubah (immutable) dan penerbitan atomik.
  • Menghubungkan serial SOA, NOTIFY, AXFR, dan IXFR.
  • Isolasi tenant, otorisasi, perlindungan kunci DNSSEC, dan pencegahan rilis yang buruk.
  • Menangani node yang tertinggal, penerbitan parsial, caching negatif, dan rollback.

Klarifikasi yang perlu ditanyakan terlebih dahulu

Konfirmasikan jumlah zona, laju penulisan, SLO propagasi, DNSSEC, geografi node, model otorisasi dan persetujuan, serta apakah node lama hanya mendukung AXFR. Jika tidak ditentukan, asumsikan kluster otoritatif yang terdistribusi secara global dengan visibilitas tingkat menit.

Kerangka jawaban tiga puluh detik

Tulis rekaman yang dinormalisasi di control plane, buat versi zona yang immutable, validasi, dan alihkan node otoritatif secara atomik. Naikkan serial SOA; NOTIFY memicu IXFR, dengan AXFR sebagai cadangan. Setiap rilis memiliki status, bukti audit, dan pointer rollback. DNSSEC, otorisasi tenant, dan pemantauan propagasi adalah gerbang rilis (release gates).

Pembahasan mendalam langkah demi langkah

1. Memisahkan plane

Control plane menyimpan tenant, zona, rekaman, dan versi. Serving plane hanya merespons dari versi yang telah diterbitkan. Recursive resolver berada di luar jalur penulisan, dan TTL menciptakan penundaan visibilitas. Sebuah versi mencakup data zona kanonikal, serial SOA, checksum, status penandatanganan, dan target.

2. Merancang penulisan dan validasi

Tulis transaksi kandidat dan validasi nama, TTL, batasan tipe, konflik CNAME, batas delegasi, dan kuota tenant. Perubahan batch membawa id idempotensi dan versi optimis. Validasi yang gagal tidak akan pernah membuat versi yang dapat diterbitkan.

3. Menghasilkan dan menerbitkan secara atomik

Hasilkan struktur zona dan jalankan pemeriksaan sintaksis, delegasi, siklus, dan DNSSEC. Simpan objek berpenunjuk konten (content-addressed) yang telah divalidasi beserta checksum-nya. Node mengalihkan pointer versi secara atomik, menghindari jawaban campuran antara versi lama dan baru.

4. Propagasi dan node yang tertinggal

Node utama (primary) menaikkan serial dan mengirimkan NOTIFY. Node sekunder meminta IXFR, dan beralih ke AXFR jika rantai delta tidak tersedia atau gagal divalidasi. Node melaporkan serial, checksum, dan status penandatanganan. Node yang tertinggal akan dikosongkan (drained) atau menyajikan versi lama yang telah divalidasi; node tersebut tidak boleh secara diam-diam menyajikan zona kosong.

5. TTL, caching negatif, dan rollback

TTL mengontrol caching rekursif, dan respons NXDOMAIN disimpan dalam cache secara negatif. Siapkan target baru sebelum mengubah TTL; menghapus rekaman otoritatif tidak langsung membersihkan cache eksternal. Lakukan rollback ke versi lama yang telah divalidasi dengan serial yang lebih tinggi daripada menggunakan kembali serial lama.

6. Keamanan dan isolasi tenant

Gunakan RBAC berskala zona, persetujuan, dan kontrol ganda. Autentikasi API pembaruan internal dan cegah pemutaran ulang (replay). Simpan kunci DNSSEC di KMS atau HSM dan blokir rilis jika penandatanganan gagal. Audit aktor, permintaan, versi, serial, dan hasil tanpa menyimpan rahasia tenant.

7. Observabilitas dan latihan simulasi

Pantau latensi penerbitan, deviasi serial (serial skew), rasio IXFR/AXFR, kegagalan penandatanganan, SERVFAIL, perubahan NXDOMAIN, keberhasilan kueri, dan distribusi regional. Lakukan simulasi kegagalan node utama, partisi jaringan, riwayat delta yang hilang, zona buruk, rotasi kunci, dan rollback sambil membuktikan bahwa versi tervalidasi yang lama tetap tersedia.

Contoh jawaban berkualitas tinggi

Saya akan menyimpan versi zona immutable yang terisolasi per tenant di control plane dan membiarkan node otoritatif menyajikan satu versi yang telah divalidasi. Validasi nama, TTL, konflik CNAME, delegasi, dan kuota dengan permintaan batch yang idempoten dan versi optimis. Hasilkan zona kanonikal, verifikasi sintaksis, DNSSEC, dan checksum, lalu alihkan pointer secara atomik.

Node utama menaikkan serial dan mengirimkan NOTIFY; node sekunder memprioritaskan IXFR dan beralih ke AXFR. Node melaporkan serial, checksum, dan status penandatanganan. TTL dan caching negatif menentukan visibilitas eksternal, sedangkan rollback menggunakan serial yang lebih baru. RBAC, persetujuan, KMS/HSM, audit, pemantauan SERVFAIL serta serial skew, dan simulasi partisi serta rotasi kunci berfungsi sebagai gerbang rilis.

Kesalahan umum

  • Menganggap penundaan cache rekursif sebagai kegagalan control plane.
  • Mengedit file zona bersama secara langsung dan menyajikan penulisan parsial.
  • Mengasumsikan bahwa NOTIFY berarti propagasi telah selesai.
  • Menyajikan zona kosong setelah IXFR gagal.
  • Menggunakan kembali serial SOA lama saat rollback.
  • Memberikan tenant akses langsung ke kunci privat DNSSEC.
  • Mengabaikan pemantauan NXDOMAIN dan SERVFAIL.

Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Mengapa serial SOA harus bertambah?

Node dan cache membandingkan serial untuk menentukan kebaruan. Rollback juga membutuhkan serial yang lebih tinggi agar tidak disalahartikan sebagai versi lama.

Pertanyaan lanjutan 2: Bagaimana jika IXFR tidak dapat menemukan deltanya?

Minta AXFR. Jika transfer gagal, pertahankan versi yang telah divalidasi dan kirimkan peringatan; jangan pernah menyajikan zona kosong.

Pertanyaan lanjutan 3: Apa yang Anda lakukan dengan node yang tertinggal jauh?

Bandingkan serial dan checksum, kosongkan node tersebut atau pertahankan pada versi lama yang telah divalidasi, lalu lakukan sinkronisasi dengan AXFR dan kueri sampel.

Pertanyaan lanjutan 4: Bisakah Anda menerbitkan data yang tidak bertanda tangan setelah penandatanganan DNSSEC gagal?

Jika kontrak zona mewajibkan tanda tangan, blokir penerbitan dan perbaiki kunci atau rantai tersebut. Jangan menurunkan tingkat keamanan secara diam-diam.

Sumber publik

Pertanyaan terkait

Alat wawancara terkait

Gunakan Jawab untuk jawaban desain sistem

Perjelas persyaratan terlebih dahulu, lalu lanjutkan dengan skala, arsitektur, pilihan komponen, dan trade-off.

Lihat alat