Nameserver sudah diganti sejak pagi. Rekan Anda di kota lain melaporkan website barunya sudah terbuka, tetapi di layar Anda masih halaman lama. Pertanyaannya bukan lagi apa yang terjadi, melainkan sudah sampai mana perubahan itu menyebar — dan apakah masih ada yang bisa dilakukan selain menunggu.
Cek propagasi domain adalah cara menjawab pertanyaan pertama, dan hasilnya menentukan jawaban pertanyaan kedua. Sebagian orang menyebutnya cek propagasi DNS, dan keduanya merujuk pada tindakan yang sama: menanyakan catatan Anda ke beberapa resolver, lalu membandingkan jawaban yang mereka berikan. Propagasi sendiri merupakan periode saat jawaban lama masih tersimpan di berbagai server perantara; mekanismenya dibahas terpisah di pengertian propagasi DNS.
Cek Propagasi Domain lewat Alat Global
Cara paling umum adalah memasukkan nama domain ke layanan pemeriksa seperti whatsmydns.net atau dnschecker.org. Layanan tersebut bertanya dari puluhan titik di berbagai negara, lalu menampilkan jawaban yang diterima masing-masing titik dalam bentuk peta atau daftar. Kalau sebagian titik menunjukkan alamat IP baru dan sebagian masih lama, itulah gambaran propagasi yang sedang berjalan.
Ada dua hal yang perlu diluruskan sebelum Anda menyimpulkan sesuatu dari peta tersebut:
- Semua titik hijau belum tentu berarti selesai: layanan itu bertanya ke resolver yang ia pilih sendiri, bukan ke resolver yang dipakai pengunjung Anda. Pelanggan sebuah penyedia internet di Surabaya bisa saja masih menerima jawaban lama meskipun seluruh peta sudah hijau.
- Titik merah belum tentu berarti gagal: satu titik yang masih menampilkan alamat lama hanya menunjukkan resolver di sana belum melewati batas simpannya. Selama nilainya belum habis, jawaban lama memang seharusnya masih muncul.
Keterbatasan paling terasa muncul justru pada pertanyaan yang paling ingin Anda jawab. Peta itu memberi tahu apa yang sedang dilihat tiap lokasi, tetapi tidak memberi tahu berapa lama lagi jawaban lama itu akan bertahan. Padahal angkanya tersedia, dan bisa Anda ambil sendiri.
Cek Propagasi Langsung dari Browser
Resolver publik Google menyediakan antarmuka DNS over HTTPS (protokol yang membungkus permintaan DNS di dalam koneksi HTTPS biasa) yang mengembalikan jawaban dalam bentuk JSON. Karena berjalan di atas HTTPS, alamatnya bisa langsung dibuka di address bar tanpa memasang apa pun:
https://dns.google/resolve?name=namadomain.com&type=AGanti namadomain.com dengan domain Anda, dan type=A dengan jenis catatan yang ingin dilihat — MX untuk email, NS untuk nameserver, TXT untuk verifikasi. Hasilnya kurang lebih seperti berikut:
{
"Status": 0,
"Answer": [
{ "name": "namadomain.com.", "type": 1, "TTL": 300, "data": "104.21.63.91" }
]
}Tiga bagian yang perlu Anda baca. Status bernilai 0 berarti permintaan berhasil dijawab; nilai 3 berarti nama tersebut tidak ditemukan. data adalah jawaban yang sedang dipegang resolver itu saat ini — inilah yang dibandingkan dengan nilai yang Anda pasang. Dan TTL adalah sisa detik sebelum resolver tersebut wajib bertanya ulang.
Cloudflare menyediakan endpoint serupa, tetapi tidak bisa dibuka begitu saja di address bar. Permintaan tanpa header khusus dijawab dengan kode kesalahan, jadi endpoint ini hanya cocok dijalankan dari terminal:
curl -sS -H "accept: application/dns-json" \
"https://cloudflare-dns.com/dns-query?name=namadomain.com&type=A"Memeriksa dari dua penyedia sekaligus berguna karena keduanya memelihara cache yang berdiri sendiri. Untuk pemeriksaan yang lebih rinci lewat baris perintah, tersedia juga pendekatan klasik memakai perintah nslookup.
Membaca Sisa TTL pada Hasil Pengecekan
Angka TTL pada hasil di atas bukan nilai yang Anda pasang di panel, melainkan sisa umur jawaban yang sedang disimpan resolver tersebut. Kalau Anda memasang TTL 3600 detik dan hasilnya menunjukkan 900, artinya resolver itu akan bertanya ulang lima belas menit lagi. Sejak saat itu ia akan menerima nilai baru Anda.
Ada satu perilaku yang perlu Anda ketahui supaya tidak salah menyimpulkan. Angka tersebut tidak selalu menurun pada pemeriksaan berikutnya, dan kadang justru naik. Pengujian pada 19 Agustus 2026 menunjukkan dua permintaan berselang empat detik ke endpoint Google mengembalikan sisa 278 detik, lalu 300 detik.
Resolver publik bukan satu mesin, melainkan banyak server yang tersebar dan memelihara cache masing-masing. Dua permintaan berurutan dari Anda dapat dilayani oleh server yang berbeda, sehingga sisa TTL-nya juga berbeda. Kesimpulannya, satu titik pemeriksaan tidak pernah cukup untuk menyatakan propagasi sudah selesai.
Cara Mempercepat Propagasi yang Benar-Benar Bekerja
Mempercepat propagasi domain sebenarnya hanya mungkin lewat dua tindakan yang berpengaruh pada resolver di luar komputer Anda. Sisanya, termasuk yang paling sering disarankan, hanya mengubah tampilan di perangkat sendiri.
Langkah #1: Turunkan TTL Sebelum Perubahan, Bukan Sesudahnya
Nilai yang mengunci penantian Anda adalah TTL yang sudah tersimpan di resolver, bukan yang baru dipasang. Karena itu urutannya tidak bisa dibalik:
- Turunkan TTL catatan yang akan diubah menjadi 300 detik, tanpa mengubah isinya sama sekali.
- Tunggu selama nilai TTL lama. Kalau sebelumnya 86400 detik, tunggu satu hari penuh agar seluruh resolver sempat mengambil nilai baru yang pendek itu.
- Baru lakukan perubahan yang sebenarnya. Sejak titik ini, propagasi hanya butuh hitungan menit.
- Kembalikan TTL ke nilai semula setelah perubahan stabil, agar beban permintaan ke nameserver kembali normal.
Konsekuensinya jelas: percepatan ini hanya tersedia bagi yang merencanakan migrasi sehari sebelumnya. Kalau perubahan sudah dilakukan, langkah ini tidak lagi menolong untuk perubahan tersebut.
Langkah #2: Kosongkan Cache Resolver Publik Lewat Alat Resminya
Google dan Cloudflare menyediakan halaman resmi untuk mengosongkan cache satu nama pada resolver mereka:
- Google Public DNS: tersedia di
developers.google.com/speed/public-dns/cache - Cloudflare: tersedia di
one.one.one.one/purge-cache
Batasannya perlu diketahui sejak awal supaya harapan Anda sesuai. Setiap jenis catatan harus dikosongkan terpisah — mengosongkan A tidak ikut mengosongkan MX. Domain yang memakai EDNS Client Subnet (mekanisme yang mengirim lokasi peminta agar jawaban bisa disesuaikan) tidak dapat dikosongkan lewat alat Google. Nama domain berhuruf non-Latin harus ditulis dalam bentuk punycode. Alat tersebut juga dilindungi verifikasi otomatis, sehingga tidak bisa dipanggil berulang lewat skrip.
Kedua alat ini hanya menyentuh resolver milik Google dan Cloudflare. Resolver bawaan penyedia internet — yang dipakai mayoritas pengunjung Indonesia — tidak terpengaruh sama sekali dan tetap menunggu TTL-nya habis.
Kalau yang ingin diperbaiki hanya tampilan di komputer Anda sendiri, yang dibutuhkan berbeda lagi, yaitu mengosongkan cache lokal. Langkahnya per sistem operasi ada di fungsi dan cara flush DNS cache.
Trik File Hosts: Apa yang Sebenarnya Terjadi
Salah satu saran yang paling sering beredar adalah menambahkan baris berisi alamat IP dan nama domain ke file hosts di komputer. Setelah itu website memang langsung terbuka, dan hasilnya mudah disalahartikan sebagai propagasi yang berhasil dipercepat.
Yang sebenarnya terjadi berbeda. File hosts dibaca sistem operasi sebelum permintaan DNS dikirim ke mana pun. Baris yang Anda tambahkan membuat komputer itu berhenti bertanya sama sekali dan langsung memakai alamat yang Anda tulis. Propagasi di luar sana berjalan persis seperti sebelumnya, tidak lebih cepat sedetik pun, dan tidak ada pengunjung lain yang ikut merasakannya.
Meski begitu, tindakan ini punya kegunaan asli yang berharga, hanya saja bukan yang dijanjikan namanya. Dengan memaksa satu komputer menuju server baru, Anda dapat menguji website di server tujuan sebelum trafik sungguhan dialihkan ke sana. Berkas, basis data, dan sertifikat bisa dipastikan lengkap lebih dulu, semuanya sebelum catatan DNS disentuh.
Risikonya justru muncul dari lupa. Selama baris itu masih ada, komputer Anda selamanya menuju server baru, sementara pengunjung mungkin masih diarahkan ke server lama. Anda akan menyimpulkan migrasi sudah beres padahal belum, dan kesalahan itu bisa berlangsung berhari-hari tanpa gejala. Hapus barisnya segera setelah pengujian selesai.
Kapan Wajar Menunggu, Kapan Berarti Ada yang Salah
Menunggu masuk akal selama gejalanya sesuai dengan cara kerja cache. Kalau gejalanya di luar itu, yang Anda hadapi adalah kesalahan pengaturan, dan menunggu tidak akan memperbaikinya.
Perbedaannya bisa dikenali dari beberapa tanda berikut:
- Sebagian lokasi sudah benar, sebagian belum: wajar. Inilah bentuk propagasi yang normal. Tunggu sampai sisa TTL terpanjang habis.
- Semua lokasi menunjukkan alamat lama setelah lewat dari TTL lama: tidak wajar. Periksa apakah catatan tersimpan di zona yang benar, terutama jika domain Anda dikelola di dua tempat sekaligus.
- Semua lokasi menjawab nama tidak ditemukan: biasanya nameserver salah ketik atau belum aktif. Bandingkan penulisannya huruf per huruf di panel pengelolaan domain Anda, dan pastikan langkahnya sesuai cara merubah nameserver dari client area. Selama kondisi ini berlangsung, pengunjung yang membuka domain Anda melihat pesan DNS_PROBE_FINISHED_NXDOMAIN di peramban.
- Domain gagal diakses total tepat setelah pindah penyedia DNS: kemungkinan besar DNSSEC masih aktif di registrar sementara penyedia baru tidak memegang kuncinya. Ini kegagalan, bukan kelambatan, dan tidak akan membaik dengan menunggu. Urutan mematikannya ada di pengertian DNSSEC.
- Subdomain baru tetap tidak ditemukan padahal catatannya sudah ada: kemungkinan alamatnya pernah dibuka sebelum catatan dibuat, sehingga jawaban "tidak ada" tersimpan lebih dulu.
Patokan praktisnya sederhana. Hubungi penyedia hosting Anda kalau seluruh titik pemeriksaan masih menunjukkan data lama setelah melewati dua kali nilai TTL lama, atau kalau gejalanya masuk poin 3 dan 4 di atas.
Pertanyaan yang Sering Muncul
Apakah menyalakan ulang router mempercepat propagasi? Tidak. Tindakan itu paling banter mengosongkan cache kecil di router Anda sendiri. Resolver penyedia internet yang melayani ribuan pelanggan lain tetap memegang jawaban lamanya sampai TTL habis.
Apakah mengganti DNS publik di laptop membuat propagasi selesai lebih cepat? Tidak, meskipun hasilnya sering terlihat langsung. Anda hanya berpindah bertanya ke resolver lain yang kebetulan belum menyimpan jawaban lama. Pengunjung Anda tetap menunggu seperti semula.
Kenapa hasil pemeriksaan berbeda antara satu lokasi dan lokasi lain? Karena setiap resolver mulai menyimpan jawaban pada waktu yang berbeda, sehingga masa simpannya juga habis pada waktu yang berbeda. Perbedaan ini normal selama propagasi berlangsung.
Berapa kali sebaiknya melakukan pemeriksaan? Secukupnya saja. Memeriksa setiap beberapa menit tidak mengubah apa pun, karena angka TTL berkurang menurut jamnya sendiri. Satu kali di awal untuk membaca sisa waktu, lalu satu kali lagi setelah perkiraan itu lewat, sudah memadai.
Apakah hasil cek propagasi DNS berbeda kalau diperiksa dari ponsel? Bisa berbeda, dan itu wajar. Jaringan seluler memakai resolver operator yang menyimpan jawaban pada waktu berbeda dari resolver jaringan kantor atau rumah Anda.
Apakah alat pemeriksa propagasi berbayar lebih akurat? Tidak ada perbedaan mendasar. Semua alat melakukan hal yang sama, yaitu bertanya ke sejumlah resolver dan menampilkan jawabannya. Yang membedakan hanya jumlah titik pemeriksaan dan tampilannya.
Kesimpulan
Pemeriksaan propagasi yang benar-benar berguna bukan sekadar melihat peta berubah hijau, melainkan membaca sisa waktu yang masih dipegang resolver. Angka itu tersedia gratis lewat endpoint DNS over HTTPS Google yang bisa dibuka langsung di browser, dan ia menjawab pertanyaan yang tidak dijawab peta mana pun.
Untuk mempercepatnya, hanya ada dua tindakan yang berpengaruh di luar komputer Anda: menurunkan TTL jauh sebelum perubahan dilakukan, dan mengosongkan cache resolver publik lewat alat resminya. Selebihnya, termasuk trik file hosts dan menyalakan ulang router, hanya mengubah apa yang Anda lihat sendiri. Untuk memahami mengapa penantian itu ada dan apa yang menentukan panjangnya, lanjutkan ke pengertian propagasi DNS.
Semoga artikel ini membantu.