Bayangkan alamat pelayan bagi sesuatu domain telah ditukar. Laman baharu dibuka dari rumah, tetapi telefon masih bersambung ke pelayan lama. Walaupun nama yang ditaip sama, dua peranti mungkin mendapat hasil berlainan buat sementara jika menggunakan cache DNS yang berbeza. Cache HTTP melibatkan penggunaan semula respons halaman, manakala cache DNS melibatkan maklumat untuk mencari alamat sambungan.
Kita akan mengikuti hos perpustakaan rekaan, www.library.example, untuk memahami hubungan penyelesaian nama dengan cache. Nama dan jadual masa ini dibuat untuk penerangan, bukan hasil pengukuran respons perkhidmatan sebenar. Matlamatnya ialah membezakan cara DNS memberikan alamat, sebab perubahan kelihatan lambat, dan kegagalan selepas nama berjaya diselesaikan.
1. Satu nama boleh mempunyai beberapa jenis jawapan
DNS menyediakan maklumat yang dikaitkan dengan nama domain melalui jenis rekod yang berlainan. A menunjukkan alamat IPv4, AAAA menunjukkan alamat IPv6, dan satu nama boleh mempunyai beberapa alamat. CNAME ialah alias kepada nama lain, MX menunjukkan pelayan penerima e-mel, manakala NS menunjukkan pelayan nama autoritatif bagi zon berkenaan. Oleh itu, jawapan bagi nama yang sama bergantung pada jenis rekod yang diminta.
Seperti diterangkan dalam dokumentasi rekod DNS Cloudflare, nilai CNAME ialah nama lain, bukannya alamat IP. Jika alamat diperlukan, penyelesaian nama itu mungkin perlu diteruskan. Dalam https://www.library.example/books, nama hos yang diproses DNS ialah www.library.example. Laluan /books dan kandungan halaman bukan rekod DNS. Menetapkan CNAME juga tidak secara automatik menghasilkan pengalihan HTTP yang menukar alamat dalam pelayar.
2. Cara penyelesai rekursif mencari pelayan autoritatif
Fungsi penyelesaian nama pada peranti biasanya meminta jawapan daripada penyelesai rekursif yang dikonfigurasikan. Penyelesai menggunakan maklumat dalam cache jika mencukupi; jika tidak, ia bertanya kepada pelayan DNS lain sebelum memulangkan jawapan akhir atau ralat. Piawaian istilah DNS RFC 9499 membezakan peranan penyelesaian bagi pihak peminta dengan pelayan autoritatif yang memegang maklumat zonnya. Untuk membaca asal sesuatu jawapan, kita perlu mengenal pasti peranan pelayan yang menjawab.
Dalam aliran ringkas tanpa cache atau pelayan perantara yang meneruskan pertanyaan, penyelesai mendapat rujukan daripada akar kepada pelayan domain aras tertinggi, kemudian daripada pelayan itu kepada pelayan autoritatif zon sasaran. Akhirnya ia memperoleh rekod yang diminta atau alias daripada pelayan autoritatif. Satu pelayan akar tidak menyimpan alamat IP bagi semua laman web. Dalam penggunaan sebenar, penyelesai boleh bermula dengan maklumat delegasi yang sudah disimpan atau meneruskan pertanyaan kepada penyelesai lain; keseluruhan urutan ini tidak semestinya diulang pada setiap lawatan.
3. TTL ialah masa cache, bukannya jam seluruh dunia
TTL rekod menyampaikan tempoh penyimpanan cache dalam saat. Dalam respons cache biasa, baki masa berkurang sepanjang tempoh penyimpanan. Jika penyelesai menyimpan alamat pada 10:00 dengan TTL 300 saat, baki TTL bagi salinan yang sama pada 10:02 ialah kira-kira 180 saat. Jadual berikut mengandaikan satu penyelesai tanpa pertanyaan semula awal, pembaharuan awal atau penyajian data yang sudah luput.
| Masa rekaan | Alamat pada pelayan autoritatif | Tindakan penyelesai ini |
|---|---|---|
| 10:00 | Alamat lama | Menyimpan alamat lama dengan TTL 300 saat |
| 10:01 | Ditukar kepada alamat baharu | Salinan tersimpan masih berbaki 240 saat |
| 10:03 | Alamat baharu | Boleh menggunakan alamat lama selama baki 120 saat |
| Pertanyaan pertama selepas 10:05 | Alamat baharu | Diandaikan bertanya semula dan memperoleh alamat baharu, bukan salinan yang sudah luput |
Penyelesai lain mungkin menyimpan rekod itu lebih lewat atau belum pernah melihatnya. Masa pembaharuan yang berbeza bermakna satu TTL tidak menentukan saat semua pengguna sedunia melihat perubahan serentak. Cache juga boleh membuang data sebelum luput, dan memuat semula halaman tidak memadam salinan pada penyelesai yang dikongsi. TTL membantu memahami penggunaan semula respons DNS, bukan had masa bagi seluruh sambungan web atau pembaharuan paparan.
4. Bila TTL patut diturunkan dan cara jawapan negatif dicache
Cache yang menerima alamat lama dengan TTL 3,600 saat tidak dimaklumkan serta-merta apabila pengendali menurunkannya kepada 60 saat. Bagi perubahan alamat terancang, TTL perlu diselaraskan lebih awal dengan mengambil kira baki hayat jawapan yang disimpan menggunakan nilai lama. TTL rendah boleh menyebabkan pemeriksaan lebih kerap, tetapi turut meningkatkan beban pertanyaan dan kebergantungan pada pelayan autoritatif. Pertimbangkan rancangan perubahan serta tindak balas gangguan, bukan menetapkan satu nilai pendek yang sama bagi semua perkhidmatan.
NXDOMAIN, iaitu nama yang tidak wujud, dan NODATA, iaitu nama wujud tetapi jenis rekod yang diminta tiada, juga boleh dicache. Piawaian cache negatif RFC 2308 menentukan tempohnya menggunakan nilai lebih kecil antara TTL rekod SOA autoritatif dan medan MINIMUM dalam SOA. Maka jawapan lama bahawa sesuatu nama tiada boleh kekal sejurus selepas hos itu ditambah. TTL rekod A baharu sahaja tidak menjelaskan tempoh jawapan negatif tersebut.
5. Kekalkan nama, jenis dan pelayan yang sama ketika membandingkan
Catat nama tepat yang ditanya, jenis seperti A atau AAAA, pelayan DNS yang ditanya dan masa pertanyaan. Jika dig dipasang, arahan seperti dig example.com A menetapkan nama dan jenis dengan jelas. Untuk masalah sebenar, gantikan example.com dengan hos yang ingin diperiksa. Arahan ini ialah contoh prosedur, bukan rekod pelaksanaan atau ukuran masa respons yang dibuat untuk artikel ini.
Periksa status respons bersama nama, jenis, nilai dan TTL dalam bahagian ANSWER. Apabila pertanyaan sama dihantar semula kepada penyelesai sama, lihat sama ada TTL menurun, tetapi jangan terus menganggap kenaikan nilai sebagai ralat. Data mungkin diperbaharui lebih awal atau nod cache lain mungkin menjawab. Merekodkan A dan AAAA secara berasingan membantu mengenal pasti keluarga alamat yang menunjukkan perbezaan.
Pengendali boleh membandingkan jawapan penyelesai rekursif yang digunakan dengan jawapan pelayan autoritatif zon, menggunakan nama dan jenis yang sama. Jika jawapannya berbeza, periksa baki hayat cache, keseragaman data antara pelayan autoritatif dan tetapan delegasi mengikut urutan. Jawapan satu penyelesai awam tidak mewakili semua pengguna. DNS dalaman rangkaian syarikat atau tetapan DNS berasingan dalam pelayar juga boleh mengubah laluan, jadi rekodkan persekitaran sambungan semasa membandingkan.
6. Bezakan ralat DNS, ralat sambungan dan pengecualian
NXDOMAIN menyatakan nama tidak wujud, manakala NODATA bermaksud jenis rekod yang diminta tiada. SERVFAIL pula ialah kegagalan pelayan memproses pertanyaan, sedangkan tamat masa menunjukkan jawapan tidak diterima dalam tempoh menunggu yang ditetapkan. Semua keadaan ini tidak bermaksud domain telah dipadam. Simpan dahulu kod respons jika ada serta pelayan yang ditanya supaya langkah pemeriksaan seterusnya dapat ditentukan.
Jawapan lama selepas TTL luput tidak semestinya melanggar peraturan. Kaedah serve-stale dalam RFC 8767 menentukan cara maklumat luput boleh digunakan untuk meningkatkan ketersediaan dalam keadaan luar biasa apabila pembaharuan daripada pelayan autoritatif gagal. Ini tidak bermaksud setiap penyelesai menggunakan kaedah tersebut dengan tetapan yang sama. Semak tingkah laku penyelesai sebenar, bukan menentukan masa perubahan berkuat kuasa daripada satu nilai TTL sahaja.
Akhir sekali, alamat yang berjaya diselesaikan tidak menjamin laman web boleh dibuka. Laluan rangkaian ke alamat itu, sijil TLS, pelayan web dan aplikasi merupakan peringkat berasingan. Jika DNS memberikan alamat yang dijangka tetapi halaman tidak terbuka, beralihlah kepada peringkat sambungan berikutnya. Merekodkan jawapan DNS dan respons web secara berasingan membantu mengecilkan lokasi kegagalan sebelum memadam cache halaman atau menukar tetapan DNS tanpa arah.