Sanyanggae LogoSanyanggae

💻 Web & Frontend

Bagaimana DNS menemukan alamat? Kueri rekursif, server otoritatif, TTL, dan cache

Ikuti domain perpustakaan rekaan untuk membedakan catatan DNS, peran server rekursif dan otoritatif, TTL serta cache negatif, dan kesalahan resolusi nama dari kegagalan koneksi web.

사냥개 (Sanyanggae)Diterbitkan Diperbarui 12 menit

Ini adalah terjemahan naskah asli bahasa Korea. Naskah asli bahasa Korea · Peninjauan terjemahan: Ditinjau AI

Diagram penjelasan DNS: server rekursif dan otoritatif, TTL dan penyegaran, membedakan kesalahan
Diagram penjelasan buatan Sanyanggae: server rekursif dan otoritatif, TTL dan penyegaran, membedakan kesalahan.

Bayangkan alamat server suatu domain sudah diubah, tetapi di rumah situs baru terbuka sementara ponsel masih terhubung ke server lama. Walaupun kedua perangkat memasukkan nama yang sama, hasilnya dapat berbeda sementara jika melewati cache DNS yang berbeda. Cache HTTP untuk mengambil ulang halaman dan cache DNS untuk mengetahui alamat tujuan koneksi memiliki objek pemeriksaan yang berbeda sejak awal.

Artikel ini mengikuti host perpustakaan rekaan www.library.example untuk membahas hubungan resolusi nama dan cache. Nama serta jadwal contoh dibuat untuk penjelasan, bukan hasil pengukuran respons layanan nyata. Tujuannya memisahkan proses DNS memberikan alamat, alasan perubahan tampak terlambat, dan kegagalan setelah resolusi nama.

1. DNS memiliki berbagai jenis jawaban untuk sebuah nama

DNS menyediakan informasi yang terkait dengan nama domain dalam berbagai jenis catatan. A menunjukkan alamat IPv4 dan AAAA menunjukkan alamat IPv6; satu nama juga dapat memiliki beberapa alamat. CNAME adalah alias yang menunjuk nama lain, MX menunjukkan server penerima surel, dan NS menunjukkan server nama otoritatif untuk zona tersebut. Jadi, meskipun nama yang ditanyakan sama, jawabannya dapat berbeda jika jenis catatan yang diminta berbeda.

Seperti dijelaskan dalam panduan catatan DNS Cloudflare, nilai CNAME adalah nama lain, bukan alamat IP. Jika alamat diperlukan, resolusi nama itu dapat dilanjutkan. Selain itu, pada https://www.library.example/books, nama host yang ditangani DNS adalah www.library.example. Jalur /books atau isi halaman tidak didaftarkan ke DNS. Menetapkan CNAME juga tidak otomatis membuat pengalihan HTTP yang mengubah bilah alamat peramban.

2. Cara resolver rekursif menemukan server otoritatif

Fungsi resolusi nama pada perangkat biasanya meminta jawaban kepada resolver rekursif yang dikonfigurasi. Resolver rekursif memakai informasi yang dibutuhkan jika tersedia dalam cache; jika belum cukup, ia menanyakan server DNS lain lalu mengembalikan jawaban akhir atau kesalahan. Standar istilah DNS RFC 9499 membedakan peran yang melakukan resolusi atas nama klien ini dari server otoritatif yang memiliki informasi zona tanggung jawabnya. Asal jawaban harus dibaca sesuai peran server saat merespons.

Dalam alur sederhana tanpa cache dan perantara penerusan, resolver memperoleh petunjuk server domain tingkat atas dari root, lalu petunjuk server otoritatif zona tujuan dari server tersebut. Server otoritatif terakhir memberikan catatan atau alias yang diperlukan. Bukan satu server root yang menyimpan alamat IP semua situs web. Dalam praktiknya, proses dapat dimulai dari informasi delegasi yang telah disimpan atau diteruskan ke resolver lain, sehingga seluruh urutan ini tidak harus diulang setiap kali situs dikunjungi.

3. TTL adalah sisa masa cache, bukan jam serentak seluruh dunia

TTL suatu catatan adalah informasi masa hidup cache yang disampaikan dalam detik. Pada respons cache biasa, waktu tersisa berkurang selama data disimpan. Misalnya, jika resolver menyimpan alamat dengan TTL 300 detik tepat pukul 10:00, saat salinan yang sama dijawabkan pada 10:02, sisa TTL sekitar 180 detik. Jadwal berikut mengasumsikan satu resolver tanpa kueri ulang, penyegaran dini, atau penyajian respons kedaluwarsa.

Waktu rekaanAlamat pada server otoritatifTindakan resolver ini
10:00Alamat lamaMenyimpan alamat lama dengan TTL 300 detik
10:01Diubah menjadi alamat baruSalinan tersimpan masih memiliki 240 detik
10:03Alamat baruAlamat lama dapat dipakai kembali selama sisa 120 detik
Kueri pertama mulai 10:05Alamat baruDiasumsikan melakukan kueri ulang untuk mengganti salinan kedaluwarsa dan mendapatkan alamat baru

Resolver lain mungkin menyimpan catatan ini lebih lambat atau belum pernah melihatnya. Karena waktu pembaruannya berbeda, satu TTL tidak dapat menentukan saat semua pengguna di dunia beralih bersamaan. Cache dapat membuang data sebelum kedaluwarsa, dan memuat ulang halaman web tidak menghapus salinan pada resolver bersama. TTL adalah petunjuk untuk memahami penggunaan ulang respons DNS, bukan batas waktu seluruh koneksi web atau pembaruan tampilan.

4. Kapan menurunkan TTL dan cache jawaban “tidak ada”

Cache yang telah menerima alamat lama dengan TTL 3600 detik tidak langsung diberi tahu ketika pengelola sekarang menurunkan TTL menjadi 60 detik. Untuk perubahan alamat yang direncanakan, sesuaikan TTL lebih awal dan pertimbangkan berapa lama respons dengan masa simpan lama yang lebih panjang masih bertahan. TTL rendah dapat membuat perubahan lebih sering diperiksa, tetapi juga meningkatkan beban kueri serta ketergantungan pada server otoritatif. Daripada menerapkan angka pendek yang sama pada semua layanan, pertimbangkan rencana perubahan bersama penanganan gangguan.

NXDOMAIN yang menyatakan nama tidak ada, atau NODATA ketika nama ada tetapi jenis catatan yang diminta tidak tersedia, juga dapat disimpan dalam cache. Standar cache negatif RFC 2308 menetapkan nilai yang lebih kecil antara TTL catatan SOA server otoritatif dan nilai MINIMUM pada SOA sebagai masa cache jawaban negatif. Karena itu, segera setelah host yang sebelumnya tidak ada ditambahkan, jawaban lama “tidak ada” dapat tetap tersimpan. Menganggap masa jawabannya sama hanya dengan melihat TTL catatan A yang baru dapat membuat penyebabnya terlewat.

5. Periksa dengan nama, jenis, dan server yang sama

Catatan pemeriksaan perlu memuat nama persis yang ditanyakan, jenis seperti A atau AAAA, server DNS yang ditanya, dan waktunya. Jika dig terpasang, nama serta jenis dapat ditentukan seperti pada dig example.com A. Saat menyelidiki masalah nyata, ganti example.com dengan host yang ingin diperiksa. Perintah ini hanya contoh prosedur, bukan catatan bahwa artikel ini benar-benar menjalankannya atau mengukur waktu respons.

Periksa status respons bersama nama, jenis, nilai, dan TTL di bagian ANSWER. Amati apakah TTL berkurang ketika kueri yang sama dikirim ulang ke resolver yang sama, tetapi jangan langsung menyimpulkan kesalahan jika nilainya bertambah. Data mungkin disegarkan lebih awal atau respons datang dari simpul lain dalam beberapa simpul cache. Mencatat hasil A dan AAAA secara terpisah tanpa mencampurnya memudahkan penentuan kelompok alamat yang berbeda.

Pengelola dapat membandingkan jawaban resolver rekursif yang digunakan dengan jawaban server otoritatif zona kelolaannya untuk nama dan jenis yang sama. Jika berbeda, periksa sisa masa cache, kesesuaian data antarserver otoritatif, lalu pengaturan delegasi. Jangan menggeneralisasi jawaban satu resolver publik sebagai keadaan semua pengguna. DNS internal jaringan perusahaan atau pengaturan DNS terpisah di peramban dapat mengubah jalur kueri, sehingga lingkungan koneksi juga harus dicatat saat membandingkan.

6. Bedakan kesalahan DNS, kesalahan koneksi, dan pengecualian

NXDOMAIN adalah respons bahwa nama tidak ada, sedangkan NODATA adalah keadaan ketika jenis catatan yang diminta tidak tersedia. Sebaliknya, SERVFAIL adalah kegagalan server memproses kueri, dan waktu habis adalah pengamatan bahwa jawaban tidak diterima selama waktu tunggu yang ditentukan. Semuanya tidak boleh dibaca sebagai “domain telah dihapus”. Simpan dahulu apakah ada kode respons dan server mana yang ditanya agar sasaran pemeriksaan berikutnya dapat ditentukan.

Terlihatnya jawaban lama setelah TTL berlalu tidak selalu melanggar aturan. Metode serve-stale dalam RFC 8767 menetapkan cara memakai informasi kedaluwarsa untuk meningkatkan ketersediaan dalam keadaan khusus ketika pembaruan dari server otoritatif tidak bisa dilakukan. Ini bukan berarti semua resolver menggunakannya dengan konfigurasi yang sama. Jadi, daripada menetapkan waktu penerapan perubahan dari satu nilai TTL, periksa perilaku resolver yang benar-benar digunakan.

Terakhir, alamat yang berhasil dicari tidak menjamin koneksi situs web berhasil. Jaringan menuju alamat itu, sertifikat TLS, server web, dan aplikasi merupakan tahap yang terpisah. Jika DNS memberikan alamat yang diharapkan tetapi halaman tidak terbuka, pindahkan penyelidikan ke tahap koneksi berikutnya. Mencatat jawaban resolusi nama dan respons web secara terpisah membantu mempersempit titik kegagalan sebelum menghapus cache halaman atau mengubah pengaturan DNS tanpa arah.

Sumber dan bacaan lanjutan

Artikel ini menjelaskan informasi dari sumber publik. Penyebutan lembaga tidak berarti lembaga tersebut meninjau atau mengesahkannya.

Tentang pengelola dan kontak

Artikel bertopik sama