Propagasi DNS: Kenapa Perubahan Butuh Waktu

Kamu sudah mengubah record DNS, tapi sebagian orang masih melihat situs lama. Ini penjelasan kenapa perubahan DNS tidak instan, arti propagasi sebenarnya, dan peran TTL.

Diterbitkan 15 September 20269 menit bacaOleh ACY Partner Indonesia
Sampul Propagasi DNS dengan timer TTL yang sedang berjalan
300 × 250Slot Iklan TersediaPasang iklan Anda di sini

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.com

Angka 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:

  1. Sehari atau dua hari sebelumnya: turunkan TTL ke 300 lalu simpan. Sekarang kamu menunggu cache 24 jam yang lama itu habis untuk terakhir kalinya.
  2. 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.
  3. 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.com menjadi 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.

Tag:dnspropagasi-dnsttldomainweb-fundamentalscaching
728 × 90Slot Iklan TersediaPasang iklan Anda di sini

Artikel Terkait

Lihat Semua Artikel

Artikel yang Mungkin Kamu Suka

Ilustrasi DOM sebagai pohon dari node HTML
Dasar-Dasar Web / Browser

Apa Itu DOM?

Penjelasan DOM untuk pemula: pohon HTML yang hidup di memori browser. Pahami apa itu DOM, bagaimana pohonnya dibentuk, dan kenapa ia begitu penting.

15 Sep 20267 menit baca
Ilustrasi berjudul Apa Itu Web Browser dengan code chip fetch ke render
Dasar-Dasar Web / Browser

Apa Itu Web Browser?

Penjelasan sederhana soal web browser: program yang mengambil berkas dari web lalu menyusunnya menjadi halaman yang kamu lihat, satu tab dan satu klik setiap saat.

15 Sep 20268 menit baca
Ilustrasi engine browser menjalankan skrip lewat event loop
Dasar-Dasar Web / Browser

Cara Browser Menangani JavaScript

Penjelasan ramah pemula soal bagaimana browser membaca, mengubah, dan menjalankan JavaScript, kenapa hanya punya satu jalur utama, dan bagaimana cara memuat skrip memengaruhi tampilan halaman.

15 Sep 20268 menit baca
Sampul biru gelap bertuliskan Cara Kerja Browser dengan chip kode parse ke layout ke paint
Dasar-Dasar Web / Browser

Cara Kerja Browser: Gambaran Umum

Penjelasan ramah pemula tentang apa yang dilakukan browser dari kamu mengetik URL sampai halaman muncul: jaringan, parsing, render tree, layout, paint, compositing, dan mesin JavaScript.

15 Sep 20268 menit baca
Sampul Critical Rendering Path dengan chip timer first paint
Dasar-Dasar Web / Browser

Critical Rendering Path

Ikuti langkah persis yang dilakukan browser untuk mengubah HTML, CSS, dan JavaScript menjadi piksel pertama yang terlihat, dan pahami kenapa posisi CSS dan JS menentukan secepat apa halaman muncul.

15 Sep 20267 menit baca
Sampul Dasar Keamanan Browser dengan chip kode berlambang perisai same-origin
Dasar-Dasar Web / Browser

Dasar Keamanan Browser: Cara Browser Diam-Diam Melindungimu

Panduan ramah untuk pemula tentang cara browser menjaga keamananmu: same-origin policy, sandboxing antar-tab, gembok HTTPS, mixed content, dan pengantar lembut soal kenapa input bisa berbahaya.

15 Sep 202610 menit baca