Kenapa Perubahan DNS Lama Terlihat? Ini Soal TTL
Sudah ganti IP server tapi sebagian pelanggan masih melihat website lama? Pahami cache DNS, nilai TTL, dan cara merencanakan migrasi agar downtime minim.
Jawaban singkat
Yang disebut propagasi DNS sebenarnya adalah cache. Resolver di seluruh internet menyimpan jawaban lama sampai TTL-nya habis, jadi perubahan terlihat bertahap. Turunkan TTL satu sampai dua hari sebelum migrasi, biarkan server lama tetap hidup beberapa waktu, lalu naikkan TTL lagi setelah stabil.
Daftar isi
Kamu baru memindahkan website ke server baru dan mengubah record A domain ke IP yang baru. Dari laptopmu, website baru sudah tampil. Satu jam kemudian, rekan kerja di kota lain mengirim tangkapan layar: yang ia lihat masih website lama, lengkap dengan harga yang sudah kamu ganti. Pesanan dari formulir lama pun masih masuk ke server yang seharusnya sudah pensiun.
Tidak ada yang salah dengan perubahanmu. Yang terjadi adalah cache DNS, dan istilah populernya "propagasi". Memahami cara kerjanya membuat migrasi berikutnya jauh lebih tenang.
Propagasi sebenarnya adalah cache yang belum kedaluwarsa
Kata propagasi memberi kesan perubahan DNS "menyebar" dari satu server ke server lain. Kenyataannya tidak begitu. Ketika kamu mengubah record di server DNS otoritatif (tempat zona domainmu dikelola), perubahan itu langsung berlaku di sana. Yang belum berubah adalah salinan jawaban lama yang disimpan oleh resolver di luar sana.
Resolver adalah server DNS yang dipakai perangkat pengguna, misalnya milik penyedia internet, kantor, atau layanan resolver publik. Agar tidak bertanya ke server otoritatif setiap kali, resolver menyimpan jawaban selama waktu tertentu. Waktu itu ditentukan oleh TTL (time to live) yang menempel di setiap record. Selama TTL belum habis, resolver akan terus memberikan jawaban lama kepada semua penggunanya.
Karena setiap resolver menyimpan jawaban pada waktu berbeda, cachenya juga habis pada waktu berbeda. Itulah sebabnya sebagian orang sudah melihat server baru sementara yang lain masih ke server lama. Dasar cara kerja DNS ini dijelaskan lebih lengkap di apa itu DNS.
Lapisan cache yang perlu kamu tahu
Resolver bukan satu-satunya tempat menyimpan jawaban. Sistem operasi dan browser juga punya cache sendiri, dan beberapa aplikasi menyimpan hasil lookup selama proses berjalan. Di sisi lain ada cache negatif: jika seseorang menanyakan subdomain yang belum ada, resolver bisa mengingat jawaban "tidak ada" selama waktu yang diatur di record SOA zona. Jadi membuat subdomain baru setelah orang sempat mencobanya pun bisa tampak terlambat.
| Jenis perubahan | Yang menentukan lama terlihat | Bisa dipercepat? |
|---|---|---|
| Ubah record A, AAAA, CNAME | TTL record lama di cache resolver | Ya, turunkan TTL jauh hari sebelumnya |
| Ubah record MX | TTL record MX lama | Ya, dengan cara yang sama |
| Tambah subdomain baru | Cache negatif (nilai di SOA) bila sudah pernah ditanyakan | Sebagian, dengan menyetel nilai SOA |
| Ganti nameserver domain | TTL record NS di zona induk (registry) | Tidak, nilai di registry di luar kendalimu |
| Ganti IP di belakang CDN | Biasanya cepat, karena IP publik CDN tidak berubah | Sudah cepat secara bawaan |
Ganti nameserver adalah kasus khusus. Record NS untuk domainmu juga disimpan di zona induk (misalnya zona .com atau .id), dan TTL di sana ditentukan registry, sering lebih panjang daripada TTL yang biasa kamu pakai. Inilah alasan perpindahan nameserver kadang butuh waktu lebih lama dibanding mengubah satu record A.
Berapa nilai TTL yang masuk akal?
TTL ditulis dalam detik. Nilai 300 berarti lima menit, 3600 berarti satu jam, dan 86400 berarti sehari. Tidak ada angka yang benar untuk semua kasus, hanya kompromi.
TTL panjang mengurangi jumlah pertanyaan ke server otoritatif dan membuat lookup lebih sering dijawab dari cache, sehingga sedikit lebih cepat bagi pengguna. Kekurangannya, setiap perubahan butuh waktu lama untuk terlihat. TTL pendek membuat perubahan cepat berlaku, tapi menambah pertanyaan ke server DNS. Untuk record yang jarang berubah, satu jam sampai sehari umum dipakai. Untuk record yang mungkin perlu diganti cepat, misalnya saat persiapan migrasi atau failover, lima menit lebih aman.
Satu catatan: tidak semua resolver patuh sepenuhnya. Ada yang menerapkan batas minimum atau maksimum sendiri. Karena itu, rencanakan dengan asumsi beberapa pengguna akan terlambat sedikit lebih lama daripada TTL.
Merencanakan perubahan DNS tanpa drama
Kuncinya adalah menurunkan TTL sebelum perubahan, bukan saat perubahan. Kalau TTL record saat ini satu hari, menurunkannya ke lima menit tepat sebelum migrasi tidak banyak membantu, karena resolver yang sudah menyimpan jawaban lama tetap memegangnya selama satu hari penuh.
Urutan yang aman kira-kira begini:
- Cek TTL saat ini dengan
dig +noall +answer domainmu.com. Angka di kolom kedua adalah sisa TTL dari resolver yang kamu tanya. - Turunkan TTL record yang akan diubah ke nilai kecil, misalnya 300, paling tidak selama satu TTL lama sebelum hari migrasi.
- Siapkan server baru sampai benar-benar siap, termasuk sertifikat SSL dan data terbaru.
- Ubah record ke IP baru. Karena TTL sudah kecil, sebagian besar pengguna pindah dalam hitungan menit.
- Biarkan server lama tetap hidup untuk sementara, idealnya mengalihkan atau menolak penulisan data agar tidak ada pesanan yang hilang.
- Setelah stabil, naikkan kembali TTL ke nilai normal.
Langkah lima sering dilupakan. Selama masih ada pengguna yang diarahkan ke server lama, server itu harus tetap melayani atau setidaknya tidak menerima data yang kemudian hilang. Untuk website dengan database, jeda singkat untuk sinkronisasi terakhir sering lebih aman daripada dua server yang menerima data bersamaan. Gambaran lengkap pemindahan server ada di cara migrasi website ke VPS.
Cara mengecek dari sisi pengguna
Untuk melihat apa yang dijawab server otoritatif, tanyakan langsung: dig @ns1.penyedia-dns.com domainmu.com. Kalau jawabannya sudah baru, perubahanmu benar, dan sisanya tinggal menunggu cache habis. Bandingkan dengan dig @1.1.1.1 domainmu.com atau resolver lain untuk melihat kondisi cache di luar.
Di perangkatmu sendiri, cache sistem operasi bisa dikosongkan agar tidak tertipu jawaban lama. Perintahnya berbeda di setiap sistem, dan browser kadang perlu ditutup lalu dibuka ulang.
Kalau yang diubah adalah nameserver, misalnya karena pindah penyedia DNS atau transfer domain, pastikan zona di penyedia baru sudah berisi semua record yang sama sebelum mengganti nameserver. Record yang terlupa, terutama MX dan TXT untuk email, sering menjadi sumber masalah setelah perpindahan.
Intinya, perubahan DNS tidak lambat karena "menyebar", melainkan karena cache yang belum kedaluwarsa. Dengan menurunkan TTL jauh hari, menjaga server lama tetap hidup selama masa transisi, dan mengecek langsung ke server otoritatif, migrasi bisa berjalan dengan gangguan minimal.
