Masalah
Record DNS sudah diubah, tetapi sebagian pengguna masih melihat alamat lama. Ini sering disebut propagasi, tetapi yang biasanya terjadi adalah cache resolver masih menyimpan jawaban sesuai TTL yang diterima sebelumnya.
TutorialNetworkingPemula
Memahami TTL DNS dan kenapa perubahan record belum langsung terlihat
Pelajari bagaimana TTL memengaruhi cache resolver dan mengapa jawaban DNS lama dapat bertahan setelah record diperbarui.
Tujuan latihan
Membaca TTL pada jawaban DNS dan membedakan cache resolver dari data authoritative.
PersiapanTerminal dengan dig dan domain yang boleh Anda periksa. Jangan mengubah TTL produksi hanya untuk mengikuti latihan ini.
Authoritative DNS→
Resolver cache→
Client
Persiapan
Catat waktu perubahan, nilai record lama, nilai baru, dan TTL sebelum perubahan. TTL yang diubah setelah resolver sudah menyimpan jawaban lama tidak selalu memperpendek cache yang sudah telanjur ada.
1. Lihat TTL jawaban
Gunakan output ANSWER SECTION agar nilai TTL terlihat. Angka sebelum tipe record adalah sisa TTL dalam detik pada jawaban tersebut.
dig example.com A +noall +answer2. Bandingkan resolver
Resolver berbeda dapat memiliki sisa TTL berbeda karena waktu pengisian cache tidak sama.
dig @1.1.1.1 example.com A +noall +answer\ndig @8.8.8.8 example.com A +noall +answerCloudflare Proxied
Untuk record Cloudflare yang diproksikan, TTL default adalah Auto dan saat ini bernilai 300 detik. Cloudflare mencatat bahwa cache lokal dapat membuat perubahan terasa lebih lama dari lima menit.
Verifikasi
Jika authoritative sudah menampilkan nilai baru tetapi resolver masih menampilkan nilai lama dengan TTL yang menurun, tunggu sampai cache kedaluwarsa. Jika authoritative juga menampilkan nilai salah, fokuskan pemeriksaan pada konfigurasi zona atau delegasi.
4. Bedakan TTL positif dan cache negatif
Tidak semua cache DNS berasal dari jawaban A/AAAA yang berhasil. Jawaban negatif seperti NXDOMAIN juga dapat di-cache berdasarkan data SOA. Karena itu, hostname yang baru dibuat dapat tetap terlihat tidak ada pada resolver tertentu walaupun record sudah benar di authoritative.
Kesalahan umum
Menurunkan TTL setelah perubahan tidak mempercepat cache lama yang sudah tersimpan. Jangan mengubah record berkali-kali hanya karena dua resolver belum seragam, dan jangan menyebut semua keterlambatan sebagai 'propagasi' tanpa memeriksa TTL serta authoritative answer.
Checklist verifikasi
Simpan waktu perubahan, TTL sebelum perubahan, jawaban authoritative, dua resolver pembanding, dan sisa TTL. Jika authoritative benar dan TTL resolver terus turun, tindakan yang tepat biasanya menunggu, bukan membuat perubahan DNS tambahan.
Pelajaran
Jangan langsung mengubah record berulang kali ketika jawaban belum seragam. Catat TTL dan sumber jawaban; perubahan tambahan dapat membuat timeline troubleshooting semakin sulit dibaca.