Kamu mengarahkan domain ke server baru, klik simpan, lalu refresh halaman. Tidak ada yang berubah. Seorang teman di kota lain bilang dia sudah melihat situs baru, tapi di layarmu masih situs lama. Rekan kerja malah melihat sesuatu yang setengah-setengah. Kalau hal ini pernah bikin kamu ragu apakah perubahannya benar-benar tersimpan, tenang — kemungkinan besar kamu sudah melakukannya dengan benar.
Yang sedang kamu hadapi namanya propagasi DNS. Ini termasuk bagian yang paling sering disalahpahami saat mengelola website, dan sebagian besar karena namanya sendiri agak menyesatkan. Di artikel ini kita akan menelusuri apa yang sebenarnya terjadi di balik layar, kenapa ada jeda, dan apa yang bisa kamu lakukan supaya perubahan berikutnya berjalan lebih mulus. Setelah selesai membaca, perasaan “kok masih situs lama” tidak akan terasa misterius lagi, melainkan jadi sesuatu yang bisa kamu perkirakan.
Mengingat lagi: apa tugas DNS
Sebelum bicara soal propagasi, mari pastikan dasarnya kokoh dulu.
Setiap website tinggal di sebuah server, dan setiap server punya alamat berupa angka yang disebut alamat IP — kira-kira seperti 192.0.2.45. Komputer suka angka; manusia tidak. Tidak ada yang mau mengetik deretan angka untuk membuka sebuah situs. Maka kita mengetik nama yang ramah seperti acy-partner.com.
DNS, singkatan dari Domain Name System, adalah layanan yang menerjemahkan nama ramah itu menjadi angka yang dibutuhkan komputer. Analoginya begini: DNS itu seperti buku telepon internet. Kamu mencari sebuah nama, lalu DNS memberikan nomor yang harus dihubungi.
Ketika kamu “mengubah record DNS”, pada dasarnya kamu sedang menyunting satu baris di buku telepon itu. Misalnya, kamu mengubah record A (record yang memetakan sebuah nama ke alamat IP) supaya acy-partner.com sekarang menunjuk ke server yang baru.
Masalahnya: buku teleponnya bukan cuma satu. Ada jutaan salinannya, tersebar di seluruh dunia, dan semuanya tidak diperbarui pada saat yang sama persis.
Kenapa perubahan tidak instan: caching
Inilah inti persoalannya. Mencari record DNS langsung ke sumber aslinya setiap kali dibutuhkan akan sangat lambat dan boros. Miliaran orang membuka website setiap hari; kalau setiap kunjungan harus memicu pencarian baru ke seluruh penjuru dunia, seluruh sistem akan berjalan tersendat.
Untuk menghindari itu, DNS sangat mengandalkan caching. Caching artinya sederhana: “menyimpan salinan sementara dari sebuah jawaban supaya tidak perlu bertanya lagi dalam waktu dekat.”
Saat komputermu atau penyedia internetmu mencari acy-partner.com, jawabannya tidak langsung dibuang setelah dipakai. Jawaban itu disimpan untuk sementara. Ketika ada lagi yang mencari nama yang sama di jaringan itu, salinan yang tersimpan langsung diberikan — tidak perlu menjelajah jauh untuk bertanya ke server asli lagi.
Caching ini tidak terjadi di satu tempat saja. Ia terjadi berlapis-lapis:
Kamu (browser) menyimpan cache kecilnya sendiri
↓
Sistem operasimu juga menyimpan cache
↓
Resolver ISP-mu menyimpan jawaban untuk SEMUA pelanggannya
↓
Resolver lain di dunia masing-masing menyimpan cache sendiri-sendiri
↓
Server otoritatif record asli yang "benar" tinggal di sini
Ketika kamu menyunting sebuah record, kamu mengubahnya di lapisan paling bawah — server otoritatif. Tapi semua salinan cache di atasnya masih memegang jawaban yang lama. Mereka akan terus menyajikan jawaban lama itu sampai salinan tersimpannya kedaluwarsa. Sampai saat itu tiba, siapa pun yang mengandalkan cache tersebut tetap melihat record yang lama.
Itulah kenapa perubahannya terasa tidak merata: orang yang berbeda berbicara dengan cache yang berbeda, dan cache-cache itu kedaluwarsa pada waktu yang berbeda pula.
Namanya menyesatkan
Sebenarnya tidak ada yang “menyebar” atau “berjalan” ke seluruh dunia. Record barumu sudah tersimpan seketika di sumber otoritatif. “Propagasi” sebetulnya hanya proses cache di seluruh dunia perlahan-lahan melepaskan jawaban lama begitu salinannya kedaluwarsa. Ini soal cache yang kedaluwarsa, bukan data yang dikirimkan.
TTL: timer yang mengatur segalanya
Lalu berapa lama sebuah salinan cache bertahan sebelum kedaluwarsa? Itu ditentukan oleh satu pengaturan bernama TTL, singkatan dari Time To Live.
Setiap record DNS membawa nilai TTL, diukur dalam detik. Nilai itu pada dasarnya sebuah instruksi yang berkata: “Setelah kamu mengambil jawaban ini, kamu boleh terus memakainya selama sekian detik sebelum harus bertanya lagi.”
Beberapa nilai yang umum, diterjemahkan ke satuan waktu:
| Nilai TTL (detik) | Kira-kira setara | Artinya dalam praktik |
|---|---|---|
| 300 | 5 menit | Cache cepat menyegarkan diri; perubahan cepat tampak |
| 3600 | 1 jam | Default yang umum dan seimbang |
| 86400 | 24 jam | Jawaban lama bisa bertahan seharian penuh |
| 604800 | 1 minggu | Sangat lengket; bagus untuk kestabilan, menyulitkan saat berubah |
Inilah poin pentingnya: TTL yang menentukan perubahanmu adalah TTL yang berlaku sebelum kamu melakukan perubahan.
Bayangkan TTL pada record-mu adalah 86400 (24 jam). Tepat sebelum kamu menyuntingnya, ada resolver di negara lain yang mengambil jawaban lama. Resolver itu sekarang boleh terus memakai jawaban lama hingga 24 jam ke depan, apa pun yang kamu lakukan setelahnya. Suntinganmu memang sudah terjadi, tapi cache itu sudah terlanjur berjanji pada dirinya sendiri. Ia baru akan bertanya lagi untuk mendapatkan record terbaru ketika hitungan 24 jam-nya habis.
Inilah sebabnya “propagasi DNS” bisa makan waktu mulai dari beberapa menit sampai beberapa hari. Bukan acak dan bukan rusak — itu hanya cache yang sedang menghitung mundur timer masing-masing.
TTL = 3600 (1 jam)
10:00 Resolver ambil record LAMA, mulai timer 1 jam
10:15 Kamu ubah record di server otoritatif
10:30 Pengunjung lewat resolver ini → masih LAMA (timer belum habis)
11:00 Timer mencapai nol → resolver bertanya lagi → dapat record BARU
11:01 Pengunjung lewat resolver ini → sekarang BARU
Kenapa orang melihat hal berbeda di saat yang sama
Begitu kamu paham TTL, teka-teki “semua orang melihat hal yang berbeda” jadi terpecahkan dengan sendirinya.
Setiap resolver di dunia mengambil record lama pada waktunya sendiri-sendiri, jadi masing-masing memulai hitung mundur TTL pada saat yang berbeda. Resolver yang kebetulan mengambil record-mu lima menit sebelum perubahan akan kedaluwarsa lebih dulu. Resolver yang mengambilnya sejam lebih awal mungkin sudah hampir waktunya menyegarkan diri. Resolver lain yang baru mengambil setelah perubahan malah sudah punya jawaban baru.
Tambahkan kenyataan bahwa browser dan sistem operasimu sendiri juga menyimpan cache kecilnya, dan kamu bahkan bisa mengalami situasi aneh: ponselmu sudah menampilkan situs baru, tapi laptopmu di Wi-Fi yang sama masih menampilkan yang lama. Keduanya cuma menyimpan jawaban pada waktu yang berbeda.
Cara cepat mengintip melewati cache lokal
Kalau kamu ingin melihat apa yang sebenarnya sedang disajikan server otoritatif saat ini — melewati rantai cache di antaranya — kamu bisa bertanya langsung lewat terminal. Tool seperti dig (di macOS dan Linux) atau nslookup (di Windows) memungkinkan ini:
# Tanya resolver publik apa yang sedang ada di cache-nya
nslookup acy-partner.com 8.8.8.8
# Di macOS/Linux, 'dig' bahkan menampilkan sisa hitung mundur TTL
dig acy-partner.comAngka di sebelah record pada keluaran dig adalah sisa detik sebelum salinan cache itu kedaluwarsa. Memperhatikannya turun adalah cara paling jelas untuk benar-benar melihat propagasi sedang berlangsung.
Cara merencanakan perubahan agar mulus
Kamu tidak bisa memaksa cache kedaluwarsa lebih cepat setelah perubahan dilakukan — tapi dengan sedikit perencanaan di awal, kamu bisa membuat perubahan DNS terasa nyaris instan. Kuncinya adalah memikirkan TTL sebelum mengganti apa pun.
Turunkan TTL jauh-jauh hari
Ini taktik paling berguna. Jauh sebelum hari kamu berencana mengubah sebuah record, turunkan dulu TTL-nya ke angka kecil, misalnya 300 detik (5 menit).
Kenapa harus dari jauh hari? Karena menurunkan TTL hari ini baru benar-benar berlaku setelah TTL lama yang lebih besar kedaluwarsa di mana-mana. Jadi kalau record-mu sekarang ber-TTL 24 jam, langkahnya:
- Sehari atau dua hari sebelumnya: turunkan TTL ke 300 lalu simpan. Sekarang kamu menunggu cache 24 jam yang lama itu habis untuk terakhir kalinya.
- Di hari penggantian: lakukan perubahan yang sesungguhnya. Karena setiap cache kini menyegarkan diri tiap 5 menit, record baru sampai ke hampir semua orang dalam hitungan menit.
- Sehari setelahnya: begitu semuanya stabil, naikkan lagi TTL-nya (misalnya ke 3600 atau lebih) supaya sistem kembali efisien.
Jangan terlalu cepat mematikan server lama
Kesalahan yang umum adalah mengarahkan domain ke server baru lalu langsung mematikan server lama. Ingat, sebagian pengunjung masih akan diarahkan ke alamat lama sampai cache mereka kedaluwarsa. Biarkan server lama tetap menyala setidaknya selama TTL asli, supaya tidak ada yang menabrak jalan buntu selama masa peralihan.
Periksa ulang record sebelum menyimpan
Banyak “masalah propagasi” sebenarnya cuma salah ketik. Satu huruf hilang di alamat IP, satu spasi berlebih, atau jenis record yang salah bisa mengarahkan orang ke tempat yang tidak ada. Karena nilai yang salah pun akan ikut tersimpan di cache dan bertahan selama TTL penuh, satu kesalahan kecil membuatmu menunggu dua kali — sekali untuk record yang salah, sekali lagi untuk perbaikannya. Baca dengan teliti sebelum menyimpan.
Me-refresh browser tidak akan membantu
Saat kamu menunggu perubahan DNS, menekan F5 berkali-kali nyaris tidak ada gunanya — browser dan sistem operasimu sedang menyajikan jawaban cache mereka sendiri. Untuk benar-benar menguji, coba jaringan lain (misalnya data seluler), pakai perangkat lain, atau tanyakan langsung ke resolver publik seperti di atas. Tahan juga keinginan untuk “membetulkan” perubahan yang sebenarnya masih dalam masa TTL; biasanya kamu malah membuat keadaan lebih membingungkan.
Satu model pikir sederhana yang perlu dipegang
Kalau hanya boleh mengingat satu hal, ingat ini: perubahan DNS tersimpan seketika, tapi seluruh dunia boleh terus memakai salinan cache lamanya sampai TTL salinan itu habis. “Propagasi” hanyalah proses cache di seluruh planet kedaluwarsa dan menyegarkan diri pada jadwal masing-masing.
Jadi lain kali ketika sebuah perubahan record tidak langsung muncul, kamu tidak perlu panik, menyimpan ulang lima kali, atau menganggap ada yang rusak. Kamu bisa memeriksa server otoritatif secara langsung, memastikan nilai barunya sudah benar di sana, lalu cukup menunggu TTL habis. Jeda itu adalah fitur yang membuat seluruh internet tetap cepat — bukan bug.
Ringkasan
- DNS menerjemahkan nama ramah seperti
acy-partner.commenjadi alamat IP berupa angka — ia adalah buku telepon internet. - Hasil pencarian di-cache di banyak lapisan (browser, sistem operasi, resolver ISP, dan resolver di seluruh dunia) supaya sistem tetap cepat.
- Perubahan DNS tersimpan seketika di server otoritatif, tapi salinan cache di tempat lain terus menyajikan jawaban lama sampai kedaluwarsa.
- TTL (Time To Live) adalah timer yang menentukan berapa lama tiap cache menyimpan sebuah jawaban. TTL yang berlaku sebelum perubahanmu-lah yang menentukan lamanya menunggu.
- “Propagasi” adalah cache yang kedaluwarsa, bukan data yang menyebar — itu sebabnya orang yang berbeda melihat hasil yang berbeda selama masa peralihan.
- Agar perubahan mulus: turunkan TTL jauh hari, biarkan server lama tetap hidup selama masa peralihan, dan periksa record dengan cermat sebelum menyimpan.
Setelah propagasi terasa masuk akal, langkah berikutnya yang wajar adalah membiasakan diri membaca record DNS itu sendiri — berbagai jenis record (A, CNAME, MX, TXT dan kawan-kawannya) serta kegunaan masing-masing. Memahaminya akan mengubah DNS dari kotak misteri menjadi sesuatu yang bisa kamu kelola dengan percaya diri.