Perintah dan cakupan
Pertanyaan teknologi umum ini menguji dasar-dasar jaringan dan pemecahan masalah (troubleshooting). Kuncinya adalah memisahkan antara record otoritatif yang telah diperbarui dan jawaban lama yang disimpan oleh resolver rekursif atau klien.
Apa yang diuji oleh pewawancara
- Menjelaskan peran stub resolver, resolver rekursif, dan server otoritatif.
- Memberikan penalaran yang benar mengenai TTL, negative caching, dan tipe record independen.
- Menggunakan kueri dari berbagai lokasi dan resolver untuk mengisolasi masalah cache atau delegasi.
- Merencanakan cutover DNS yang dapat di-rollback alih-alih hanya menyuruh pengguna membersihkan cache.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan apakah perubahannya adalah A, AAAA, CNAME, atau delegasi NS; apakah kedua endpoint sehat; apakah masalah ini bersifat global atau terbatas pada penyedia, wilayah, atau jaringan tertentu; TTL lama dan parameter negative-cache SOA; status DNSSEC; dan apakah aplikasi melakukan pin hasil atau menggunakan connection pool.
Jawaban 30 detik
Saya akan mengueri server otoritatif terlebih dahulu, lalu membandingkan jawaban dan sisa TTL dari beberapa resolver publik dan jaringan yang terdampak. Jika otoritas sudah benar tetapi rekursi masih lama, cache atau TTL upstream adalah penyebabnya. Jika otoritas tidak konsisten, periksa delegasi, publikasi zona, dan otomatisasi. Sebelum cutover, turunkan TTL dan tunggu sepanjang jendela TTL lama, jaga kedua endpoint tetap sehat, amati lalu lintas, dan baru kemudian hentikan endpoint lama.
Pembahasan mendalam langkah demi langkah
1. Gambarkan jalur kueri yang sebenarnya
Aplikasi biasanya menghubungi stub resolver pada browser atau OS, yang kemudian bertanya ke resolver rekursif. Resolver rekursif mengembalikan jawaban yang di-cache jika masih baru atau mengikuti server root, TLD, dan otoritatif jika tidak. Server otoritatif menyimpan record zona tersebut. Setiap lapisan dapat memiliki cache dan waktu penyegaran (refresh) sendiri.
2. Jelaskan waktu dengan TTL dan negative caching
TTL yang lebih panjang meningkatkan rasio cache hit dan mengurangi beban kueri, tetapi menunda perubahan. Jawaban yang tersimpan dalam cache umumnya tetap ada sampai TTL lamanya mencapai nol. Respons negatif juga dapat di-cache sesuai dengan parameter terkait SOA, sehingga nama yang baru dibuat mungkin masih terlihat tidak ada. Ukur sisa TTL per tipe record dan resolver daripada menjanjikan satu durasi propagasi tunggal.
3. Buat investigasi dapat diulang (repeatable)
Kueri server otoritatif dan verifikasi delegasi yang konsisten. Kemudian kueri nama, tipe, dan flag yang sama melalui beberapa resolver rekursif, wilayah, dan jaringan, dengan mencatat jawaban, TTL, kode respons, dan waktu. Pola "otoritas benar, rekursi lama", "otoritas tidak konsisten", dan "hanya satu klien yang lama" masing-masing merujuk pada lapisan cache, publikasi/delegasi, dan lokal.
4. Singkirkan alamat usang non-DNS
Proksi HTTP, CDN, konfigurasi aplikasi, connection pool, service discovery, atau file hosts dapat terus menggunakan alamat lama setelah DNS benar. Periksa IP tujuan sebenarnya, sertifikat TLS, header respons, dan log load balancer untuk membuktikan bahwa kegagalan terjadi pada resolusi, bukan pada perutean atau caching aplikasi.
5. Rencanakan cutover yang aman
Turunkan TTL ke nilai yang dapat diterima bisnis sebelum perubahan dan tunggu hingga jendela TTL sebelumnya berakhir; jaga agar endpoint lama dan baru tersedia secara bersamaan. Setelah perubahan, pantau distribusi jawaban, kesalahan, dan lalu lintas nyata berdasarkan wilayah dan resolver. Pertahankan endpoint lama hingga jendela risiko ditutup, dan siapkan degradasi tingkat aplikasi atau layanan ganda karena rollback DNS juga bergantung pada cache.
Contoh jawaban yang kuat
Saya akan memverifikasi record otoritatif dan delegasi terlebih dahulu, kemudian mengueri beberapa resolver rekursif dan jaringan yang terpengaruh sambil mencatat jawaban dan sisa TTL. Otoritas yang diperbarui dengan jawaban rekursif yang lama berarti kedaluwarsa cache; otoritas yang tidak konsisten berarti masalah publikasi zona, NS, atau otomatisasi; beberapa perangkat yang anomali merujuk pada status cache lokal, hosts, proksi, atau connection pool. TTL mengontrol berapa lama jawaban lama dapat digunakan, dan negative caching memengaruhi nama baru, jadi saya tidak akan menjanjikan waktu propagasi yang pasti. Saya akan menurunkan TTL sebelum cutover, menjaga kedua endpoint tetap aktif, memantau lalu lintas nyata dan kesalahan, serta mempensiunkan endpoint lama hanya setelah jendela risiko berakhir.
Kesalahan umum
- Mengklaim bahwa propagasi DNS selalu selesai dalam beberapa menit.
- Membersihkan cache satu laptop dan menganggapnya sebagai bukti global.
- Hanya mengueri satu penyedia DNS publik.
- Memperbarui A sambil melupakan AAAA, CNAME, NS, atau DNSSEC.
- Mematikan layanan lama segera setelah otoritas berubah.
- Menyalahkan DNS ketika CDN, proksi, atau file hosts yang menyajikan alamat lama.
Pertanyaan lanjutan dan tanggapan
Mengapa record baru masih mengembalikan NXDOMAIN?
Resolver upstream mungkin telah menyimpan respons negatif dalam cache berdasarkan parameter terkait SOA. Konfirmasikan bahwa record otoritatif ada dan tunggu kedaluwarsa negative-cache.
Mengapa jawaban lama masih ada setelah menurunkan TTL?
Menurunkan TTL memengaruhi entri cache yang baru diambil; entri yang sudah ada tetap menghitung mundur TTL lamanya. Verifikasi juga bahwa record, zona, dan server otoritatif yang benar telah diubah.
Bisakah Anda memaksa setiap pengguna untuk menyegarkan DNS?
Tidak. Resolver rekursif dan klien berada di luar kendali Anda. Kurangi risiko dengan perubahan TTL lebih awal, endpoint ganda, perutean aplikasi, dan pemantauan.
Bagaimana Anda mendeteksi IPv6 sebagai penyebabnya?
Kueri dan uji A dan AAAA secara terpisah, dengan mencatat address family yang sebenarnya digunakan oleh klien. Jika AAAA masih mengarah ke endpoint lama, perbaiki secara terpisah.