Kenapa Website Masih ke Server Lama Padahal TTL Sudah Diturunkan

Record A sudah kamu ganti ke IP server baru, TTL juga sudah diturunkan jadi 300 detik. Tapi beberapa jam kemudian masih ada pengunjung yang mendarat di server lama. Sebagian melihat website baru, sebagian masih melihat versi lama, dan polanya terasa acak. Biasanya ini bukan DNS yang rusak. Penyebabnya urutan langkah yang kurang pas, atau ada lapisan cache yang terlewat. Istilah yang sering dipakai untuk ini adalah propagasi DNS, seolah-olah perubahan didorong pelan-pelan ke seluruh internet. Kenyataannya tidak ada yang mendorong apa pun. Yang terjadi adalah ribuan cache yang kedaluwarsa di waktu berbeda-beda. Kalau cara kerjanya sudah kebayang, kasus seperti ini jadi jauh lebih gampang dijelaskan dan dicek.

Gambaran sederhananya

Bayangkan kamu punya nomor telepon kantor yang dicatat banyak orang. Setiap orang menulis nomor itu di kertas tempel, lengkap dengan catatan 'cek ulang besok'. Suatu hari nomor kantor pindah. Kamu mengumumkan nomor baru sekaligus bilang 'mulai sekarang cek ulang tiap lima menit'. Masalahnya, pengumuman itu hanya sampai ke orang yang kebetulan bertanya lagi. Orang yang tadi pagi sudah mencatat nomor lama dengan catatan 'cek ulang besok' tidak akan bertanya sampai besok. Mereka tetap menelepon nomor lama dan merasa sudah benar. DNS bekerja persis seperti itu. Kertas tempelnya adalah cache di resolver, dan catatan 'cek ulang besok' adalah TTL yang berlaku saat record itu diambil.

Kenapa TTL baru tidak berlaku untuk cache yang sudah ada

Saat pengunjung membuka website, browser tidak bertanya langsung ke nameserver kamu. Pertanyaannya lewat recursive resolver, yaitu server DNS milik ISP, kantor, atau resolver publik yang mencari jawaban atas nama pengguna. Resolver ini bertanya ke nameserver authoritative (server yang benar-benar memegang zona domain kamu). Jawabannya lalu disimpan di cache selama TTL yang ikut dikirim bersama jawaban itu. Poin pentingnya: TTL adalah bagian dari jawaban, bukan pengaturan yang terus dibaca ulang. Begitu resolver menyimpan record A dengan TTL 86400 detik (contoh, sekitar satu hari), hitung mundurnya sudah berjalan. Resolver tidak tahu dan tidak peduli kalau satu jam kemudian kamu mengubah TTL di panel DNS. Ia baru bertanya lagi setelah hitungannya habis. Jadi kalau record A dan TTL diubah bersamaan, TTL baru hanya membantu resolver yang belum punya cache atau yang cache-nya kebetulan baru habis. Resolver yang mengambil record lama beberapa menit sebelum perubahan akan menyimpan IP lama sampai hampir satu hari penuh. Itu juga yang membuat polanya terlihat acak. Setiap resolver mengambil record di waktu yang berbeda, jadi waktu kedaluwarsanya juga berbeda-beda. Dua pengguna di kota yang sama bisa mendapat jawaban berbeda hanya karena ISP-nya berbeda. Bahkan di satu ISP pun hasilnya bisa beda kalau resolver mereka terdiri dari banyak node dengan cache masing-masing. Urutan yang benar adalah menurunkan TTL lebih dulu. Setelah itu tunggu minimal sepanjang TTL lama, supaya semua cache yang menyimpan TTL panjang sudah habis. Baru kemudian ganti IP-nya. Setelah migrasi stabil, TTL boleh dinaikkan lagi supaya resolver tidak terlalu sering bertanya.

Kalau nameserver ikut pindah, TTL-nya bukan milikmu

Skenario kedua lebih sering membingungkan. Domainnya tidak cuma ganti IP, tapi juga pindah ke penyedia DNS baru. Artinya nameserver di registrar ikut diganti. Untuk tahu nameserver mana yang memegang domain kamu, resolver bertanya ke server TLD (misalnya server untuk .com). Server TLD menjawab dengan daftar record NS yang disebut delegasi. Delegasi ini disimpan di zona milik registry, bukan di zona kamu, jadi TTL-nya juga ditentukan registry. Untuk .com nilainya umumnya dua hari, dan TLD lain bisa berbeda. TTL ini tidak bisa kamu turunkan dari panel DNS mana pun. Selama delegasi lama masih ada di cache sebuah resolver, resolver itu tetap bertanya ke nameserver lama. Kalau di nameserver lama zona domain kamu masih ada dan isinya masih IP lama, pengunjung lewat resolver tersebut akan dikirim ke server lama. Ini tetap terjadi walaupun zona di penyedia baru sudah benar dan TTL-nya kecil. Kalau zona di penyedia lama sudah dihapus, gejalanya berbeda: domain gagal resolve atau mengembalikan error di sebagian jaringan. Ada satu detail lagi. Di dalam zona kamu sendiri juga ada record NS dengan TTL-nya sendiri. Sebagian resolver lebih percaya NS dari zona authoritative, sebagian lagi memakai NS dari delegasi di level TLD. Perilakunya tergantung software resolver. Karena itu, jangan berasumsi semua resolver akan pindah ke nameserver baru di waktu yang sama. Cara paling aman saat pindah nameserver adalah menyamakan isi zona di penyedia lama dan penyedia baru selama masa transisi. Kalau IP ikut berubah, ubah juga record A di nameserver lama. Dengan begitu, resolver mana pun yang masih memegang delegasi lama tetap mendapat IP yang benar. Penyedia lama baru boleh dimatikan setelah TTL delegasi di level TLD terlewati dengan aman.

Cache lain di luar resolver

Kadang semua resolver sudah memberi jawaban yang benar, tapi satu orang tetap melihat server lama. Di titik ini masalahnya biasanya sudah pindah ke perangkat pengguna atau ke jalur di antaranya. Yang pertama dicek adalah file hosts di komputer pengguna. Sebelum migrasi, file ini sering diubah untuk preview website di server baru, atau sebaliknya untuk mengarah ke server lama, lalu lupa dikembalikan. Entri di file hosts mengalahkan DNS sepenuhnya, jadi berapa pun TTL-nya tidak ada pengaruhnya. Berikutnya cache DNS di sistem operasi dan di browser. Banyak sistem operasi punya resolver lokal dengan cache sendiri, dan browser modern juga menyimpan hasil lookup untuk sementara. Browser juga bisa mempertahankan koneksi keep-alive yang sudah terbuka ke IP lama. Cara membersihkan cache-nya berbeda di tiap sistem operasi dan browser. Untuk tes cepat, menutup browser sepenuhnya atau mencoba dari jaringan lain (misalnya data seluler) biasanya sudah cukup. Lalu ada resolver yang tidak sepenuhnya patuh pada TTL. Sebagian resolver menerapkan batas minimum TTL, sehingga TTL 300 detik tetap disimpan lebih lama. Ini kebijakan operator resolver, dan dari sisi kamu tidak ada yang bisa memaksanya. Terakhir, kalau website ada di belakang reverse proxy atau CDN, IP server asli (origin) biasanya diatur di konfigurasi proxy, bukan dibaca dari record A publik. Mengganti record A tanpa mengganti origin di proxy membuat trafik tetap mengalir ke server lama. Letak pengaturannya tergantung layanan yang dipakai.

Cara cek jawaban tiap resolver dengan dig

Alih-alih menebak, cek setiap lapisan satu per satu. Ganti example.com dengan domain kamu. Ganti juga ns1.provider-baru.example dan ns1.provider-lama.example dengan nameserver yang sebenarnya.

BASH

# 1. Jawaban langsung dari nameserver authoritative baru (tanpa cache)
dig @ns1.provider-baru.example example.com A +norecurse +noall +answer

# 2. Apakah nameserver lama masih menjawab dengan IP lama?
dig @ns1.provider-lama.example example.com A +norecurse +noall +answer

# 3. Jawaban dari beberapa resolver publik; kolom TTL = sisa waktu cache
dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer
dig @9.9.9.9 example.com A +noall +answer

# 4. Delegasi NS di level TLD beserta TTL-nya (contoh untuk .com)
dig NS com +short
dig @a.gtld-servers.net example.com NS +norecurse +noall +authority

# 5. Jalur resolusi lengkap dari root sampai authoritative
dig +trace example.com A

Cara membaca hasilnya kurang lebih begini. Di langkah pertama, angka TTL adalah nilai penuh yang kamu set, karena jawabannya datang langsung dari sumber. Di langkah ketiga, angka TTL adalah sisa waktu cache di resolver itu. Kalau resolver masih memberi IP lama dengan sisa TTL yang besar, artinya resolver itu sedang memegang cache lama. Yang bisa dilakukan hanya menunggu sampai hitungannya habis. Kalau langkah kedua masih mengembalikan IP lama, berarti ada resolver yang mungkin masih diarahkan ke sana. Perbaiki record A di nameserver lama. Langkah keempat memperlihatkan nameserver mana yang terdaftar di registry dan berapa lama delegasinya disimpan. Kalau isinya belum berubah, berarti perubahan di registrar belum diproses. Perlu diingat, dig dari laptop atau server kamu hanya mewakili resolver yang kamu tanya. Resolver ISP milik pengguna sering tidak bisa ditanya dari luar jaringannya. Untuk kasus seperti itu, minta pengguna menjalankan nslookup atau dig ke domain tersebut dari jaringan mereka sendiri, lalu bandingkan IP yang muncul dengan IP di nameserver authoritative. Kalau hasil dari jaringan pengguna sudah benar tapi browsernya masih membuka server lama, fokus ke file hosts dan cache di perangkat.

Kesalahan yang sering terjadi saat migrasi

Kesalahan paling umum sudah dibahas di atas: TTL diturunkan di menit yang sama dengan pergantian IP. Rasanya sudah mengikuti prosedur, padahal TTL kecil itu baru berguna kalau dipasang jauh sebelum perubahan, minimal sepanjang TTL lama. Kesalahan berikutnya adalah mematikan server lama terlalu cepat. Selama masih ada cache yang mengarah ke IP lama, server lama sebaiknya tetap hidup. Paling tidak ia masih bisa melayani dengan isi yang sama, atau mem-proxy trafik ke server baru. Untuk website dinamis atau toko online, ini penting juga karena data yang masuk ke server lama selama transisi bisa terpisah dari data di server baru. Lalu menghapus zona di penyedia DNS lama sebelum delegasi baru benar-benar dipakai semua resolver. Ini mengubah masalah ringan (sebagian pengunjung ke server lama) menjadi masalah yang lebih berat (sebagian pengunjung tidak bisa membuka domain sama sekali). Hal yang sama berlaku untuk email: record MX dan TXT yang hanya ada di zona baru tidak akan terlihat oleh resolver yang masih bertanya ke nameserver lama. Terakhir, menyimpulkan migrasi gagal atau berhasil hanya dari satu perangkat. Di meja support, pola ini sering muncul. Satu orang bilang website sudah baru, orang lain bilang masih lama, padahal keduanya benar untuk resolver dan cache yang mereka pakai. Mengecek beberapa resolver seperti contoh di atas biasanya cukup untuk menunjukkan posisi sebenarnya. Aturan praktisnya: anggap setiap perubahan DNS butuh waktu sepanjang TTL lama yang sudah tersebar, bukan TTL baru yang kamu pasang. Kalau nameserver ikut pindah, waktunya mengikuti TTL delegasi di registry. Turunkan TTL jauh sebelum migrasi, samakan isi zona lama dan baru, biarkan server lama tetap hidup selama masa transisi, dan pakai dig untuk memastikan lapisan mana yang masih memegang data lama sebelum mengambil langkah berikutnya.