Gesaan dan skop
Soalan teknologi umum ini menguji asas rangkaian dan penyelesaian masalah. Perkara utama adalah membezakan antara rekod berwibawa (authoritative) yang dikemas kini dengan jawapan lama yang dipegang oleh resolver rekursif atau klien.
Perkara yang diuji oleh penemu duga
- Menerangkan peranan stub resolver, resolver rekursif dan pelayan berwibawa.
- Memberikan hujah yang betul tentang TTL, negative caching dan jenis rekod bebas.
- Menggunakan pertanyaan dari pelbagai lokasi dan resolver untuk mengasingkan isu cache atau delegasi.
- Merancang peralihan DNS yang boleh diundur balik (reversible) dan bukannya sekadar menyuruh pengguna mengosongkan cache.
Soalan penjelasan untuk ditanya
Sahkan sama ada perubahan tersebut ialah A, AAAA, CNAME atau delegasi NS; sama ada kedua-dua endpoint sihat; sama ada isu tersebut bersifat global atau terhad kepada penyedia, wilayah atau rangkaian tertentu; TTL lama dan parameter negative-cache SOA; status DNSSEC; dan sama ada aplikasi mengepin hasil atau menggunakan kolam sambungan (connection pools).
Jawapan 30 saat
Saya akan membuat pertanyaan kepada pelayan berwibawa terlebih dahulu, kemudian membandingkan jawapan dan baki TTL daripada beberapa resolver awam dan rangkaian yang terjejas. Jika autoriti adalah betul tetapi rekursi adalah lama, cache atau TTL huluan (upstream) bertanggungjawab. Jika autoriti tidak konsisten, periksa delegasi, penerbitan zon dan automasi. Sebelum peralihan, turunkan TTL dan tunggu sepanjang tempoh TTL lama, pastikan kedua-dua endpoint sihat, perhatikan trafik dan hanya selepas itu tamatkan perkhidmatan yang lama.
Perincian langkah demi langkah
1. Lakarkan laluan pertanyaan sebenar
Aplikasi biasanya menghubungi stub resolver penyemak imbas atau OS, yang seterusnya bertanya kepada resolver rekursif. Resolver rekursif mengembalikan jawapan yang dicache apabila ia masih baharu atau mengikuti pelayan root, TLD dan berwibawa apabila ia tiada dalam cache. Pelayan berwibawa menyimpan rekod zon tersebut. Setiap lapisan boleh mempunyai cache dan masa penyegaran tersendiri.
2. Terangkan masa dengan TTL dan negative caching
TTL yang lebih panjang meningkatkan kadar capaian cache (cache hit rate) dan mengurangkan beban pertanyaan, tetapi melambatkan perubahan. Jawapan sedia ada dalam cache secara amnya kekal sehingga TTL lamanya mencapai sifar. Respons negatif juga boleh dicache mengikut parameter berkaitan SOA, jadi nama yang baru dibuat mungkin masih kelihatan tidak wujud. Ukur baki TTL mengikut jenis rekod dan resolver dan bukannya menjanjikan satu tempoh masa perambatan (propagation).
3. Jadikan siasatan boleh diulang
Buat pertanyaan kepada pelayan berwibawa dan sahkan delegasi yang konsisten. Kemudian buat pertanyaan untuk nama, jenis dan bendera yang sama melalui pelbagai resolver rekursif, wilayah dan rangkaian, dengan merekodkan jawapan, TTL, kod respons dan masa. Corak "autoriti betul, rekursi lama", "autoriti tidak konsisten" dan "hanya satu klien lama" masing-masing menunjukkan lapisan cache, penerbitan/delegasi dan tempatan.
4. Singkirkan alamat lapuk bukan DNS
Proksi HTTP, CDN, konfigurasi aplikasi, connection pools, penemuan perkhidmatan (service discovery) atau fail hosts boleh terus menggunakan alamat lama selepas DNS betul. Periksa IP destinasi sebenar, sijil TLS, pengepala respons dan log pengimbang beban untuk membuktikan bahawa kegagalan berlaku pada resolusi dan bukannya penghalaan atau caching aplikasi.
5. Rancang peralihan yang selamat
Turunkan TTL kepada nilai yang boleh diterima oleh perniagaan sebelum perubahan dan tunggu sehingga tempoh TTL sebelumnya berlalu; pastikan kedua-dua endpoint lama dan baharu tersedia bersama-sama. Selepas perubahan, pantau pengedaran jawapan, ralat dan trafik sebenar mengikut wilayah dan resolver. Kekalkan endpoint lama sehingga tempoh risiko berakhir, dan sediakan degradasi peringkat aplikasi atau perkhidmatan dwi-arah kerana pembalikan (rollback) DNS juga perlu menunggu cache luput.
Contoh jawapan yang mantap
Saya akan mengesahkan rekod berwibawa dan delegasi terlebih dahulu, kemudian membuat pertanyaan kepada beberapa resolver rekursif dan rangkaian yang terjejas sambil merekodkan jawapan dan baki TTL. Autoriti yang dikemas kini dengan jawapan rekursif lama bermakna menunggu tamat tempoh cache; autoriti yang tidak konsisten bermakna isu penerbitan zon, NS atau automasi; beberapa peranti yang tidak normal menunjukkan status cache tempatan, hosts, proksi atau connection pool. TTL mengawal berapa lama jawapan lama boleh digunakan, dan negative caching mempengaruhi nama baharu, jadi saya tidak akan menjanjikan masa perambatan yang tetap. Saya akan menurunkan TTL sebelum peralihan, memastikan kedua-dua endpoint aktif, memantau trafik sebenar dan ralat, serta melupuskan endpoint lama hanya selepas tempoh risiko.
Kesilapan lazim
- Mendakwa bahawa perambatan DNS sentiasa selesai dalam masa beberapa minit.
- Mengosongkan cache satu komputer riba dan menganggapnya sebagai bukti global.
- Hanya membuat pertanyaan kepada satu penyedia DNS awam.
- Mengemas kini A tetapi terlupa AAAA, CNAME, NS atau DNSSEC.
- Menutup perkhidmatan lama serta-merta selepas perubahan autoriti dibuat.
- Menyalahkan DNS apabila CDN, proksi atau fail hosts yang menyediakan alamat lama.
Soalan susulan dan respons
Mengapakah rekod baharu masih mengembalikan NXDOMAIN?
Resolver huluan mungkin telah mencache respons negatif di bawah parameter berkaitan SOA. Sahkan bahawa rekod berwibawa wujud dan tunggu sehingga tamat tempoh negative-cache.
Mengapakah jawapan lama masih ada selepas menurunkan TTL?
Menurunkan TTL mempengaruhi entri cache yang baru diambil; entri sedia ada masih mengira detik TTL lamanya. Sahkan juga bahawa rekod, zon dan pelayan berwibawa yang betul telah diubah.
Bolehkah anda memaksa setiap pengguna untuk menyegarkan DNS?
Tidak. Resolver rekursif dan klien berada di luar kawalan anda. Kurangkan risiko dengan perubahan TTL awal, endpoint dwi-arah, penghalaan aplikasi dan pemantauan.
Bagaimanakah anda mengesan IPv6 sebagai puncanya?
Buat pertanyaan dan uji A dan AAAA secara berasingan, dengan merekodkan famili alamat yang sebenarnya digunakan oleh klien. Jika AAAA masih menunjuk ke endpoint lama, betulkannya secara berasingan.