Propagasi DNS: Berapa Lama Sebenarnya & Cara Mengeceknya

Propagasi DNS sebenarnya bukan proses "menyebarkan" data ke seluruh internet, melainkan menunggu cache di resolver-resolver DNS kedaluwarsa. Lama waktunya ditentukan terutama oleh nilai TTL (Time To Live) record lama: kalau TTL-nya 300 detik, sebagian besar pengguna akan melihat perubahan dalam hitungan menit; kalau 86400 detik, bisa sampai sekitar satu hari. Angka "24–48 jam" yang sering disebut hanyalah batas aman yang konservatif, bukan aturan pasti.

Di artikel ini Anda akan memahami apa yang sebenarnya terjadi saat Anda mengubah record DNS, kenapa sebagian orang sudah melihat perubahan sementara yang lain belum, bagaimana memeriksanya sendiri dengan dig ke resolver publik seperti 8.8.8.8 dan 1.1.1.1, serta strategi menurunkan TTL sebelum migrasi agar perpindahan server atau email berjalan mulus.

Apa yang Sebenarnya Disebut "Propagasi DNS"?

Saat Anda mengubah record A, CNAME, MX, atau TXT di panel DNS, perubahan itu langsung tersimpan di server DNS otoritatif (authoritative nameserver) domain Anda. Secara teknis, sejak detik itu data baru sudah "ada" di internet. Masalahnya, hampir tidak ada pengguna yang bertanya langsung ke server otoritatif.

Browser, aplikasi, dan server email bertanya ke resolver rekursif: resolver milik ISP, resolver kantor, atau resolver publik seperti Google Public DNS (8.8.8.8) dan Cloudflare (1.1.1.1). Resolver ini menyimpan jawaban di cache selama TTL yang tertera pada record. Selama cache belum habis, resolver akan terus memberikan jawaban lama tanpa bertanya ulang ke server otoritatif.

Jadi "propagasi" sebenarnya adalah kumpulan ribuan cache independen yang kedaluwarsa pada waktu berbeda-beda. Itulah sebabnya Anda bisa melihat website baru di laptop, sementara rekan Anda yang memakai ISP lain masih melihat server lama.

Lapisan cache yang perlu Anda ketahui

• Cache resolver rekursif: lapisan utama, patuh pada TTL record (beberapa resolver menerapkan batas minimum atau maksimum sendiri).
• Cache sistem operasi: Windows, macOS, dan Linux dengan systemd-resolved menyimpan hasil lookup secara lokal.
• Cache browser: Chrome dan Firefox punya cache DNS internal berumur pendek.
• Cache aplikasi: misalnya proses PHP-FPM, JVM, atau server mail yang menyimpan hasil resolusi di memori sampai di-restart.

Berapa Lama Propagasi DNS Sebenarnya?

Jawaban jujurnya: paling lama kira-kira sebesar TTL record lama, ditambah sedikit waktu untuk cache lokal. Kuncinya adalah TTL yang berlaku sebelum Anda melakukan perubahan, karena itulah angka yang sudah tersimpan di cache resolver.

Perlu dicatat, tabel di atas adalah perkiraan berdasarkan perilaku standar resolver. Ada resolver yang memperpendek TTL, ada juga yang (meskipun tidak dianjurkan) menyimpan lebih lama. Karena itu selalu sisakan margin.

Lalu dari mana angka "48 jam"?

Angka 24–48 jam lahir dari kasus pergantian nameserver (NS), bukan perubahan record biasa. Saat Anda memindahkan domain ke nameserver baru di registrar, data delegasi diperbarui di server TLD (misalnya server .com atau .id). Record NS di level TLD umumnya memiliki TTL yang cukup panjang, sering satu hingga dua hari. Resolver yang sudah menyimpan delegasi lama akan terus bertanya ke nameserver lama sampai cache itu habis.

Karena pengguna awam tidak bisa mengontrol TTL di level TLD, penyedia hosting memilih memberi angka aman "hingga 48 jam". Untuk perubahan record A atau MX biasa dengan TTL rendah, menunggu dua hari jelas berlebihan. Sebaliknya, untuk pergantian nameserver, angka itu masuk akal sebagai batas atas, meskipun banyak kasus selesai lebih cepat.

Negative caching: jebakan record yang belum ada

Ada satu kasus yang sering membingungkan. Misalnya Anda mengecek mail.domainanda.com sebelum membuat record-nya. Resolver akan menerima jawaban NXDOMAIN (tidak ada) dan menyimpan jawaban negatif itu di cache. Lama penyimpanannya diatur oleh record SOA zona (lihat RFC 2308), bukan oleh TTL record yang baru Anda buat. Jadi jangan terburu-buru mengecek subdomain baru sebelum record-nya benar-benar tersimpan, karena justru Anda sendiri yang "mengunci" jawaban kosong di resolver.

Cara Mengecek Propagasi DNS dengan dig

Alat paling andal untuk memeriksa DNS adalah dig. Di macOS dan sebagian besar distro Linux sudah tersedia; di Ubuntu/Debian bisa dipasang lewat paket dnsutils. Pengguna Windows bisa memakai nslookup atau memasang BIND tools.

1. Tanya langsung ke server otoritatif

Langkah pertama selalu memastikan data di sumbernya sudah benar. Cari dulu nameserver domain Anda, lalu tanya langsung ke salah satunya.

dig NS contohdomain.com +short
# misal hasilnya: ns1.provider-dns.net.

dig @ns1.provider-dns.net contohdomain.com A +noall +answer

Kalau jawaban server otoritatif sudah menampilkan IP baru, berarti konfigurasi Anda benar. Sisanya murni soal cache.

2. Bandingkan dengan resolver publik

dig @8.8.8.8 contohdomain.com A +noall +answer
dig @1.1.1.1 contohdomain.com A +noall +answer
dig @9.9.9.9 contohdomain.com A +noall +answer

Perhatikan kolom kedua pada baris jawaban. Contohnya:

contohdomain.com.   2873   IN   A   203.0.113.10

Angka 2873 adalah sisa TTL di cache resolver tersebut, dalam detik. Artinya resolver itu akan tetap memberi jawaban ini selama kira-kira 48 menit lagi sebelum bertanya ulang. Ini informasi yang sangat berguna: Anda tidak perlu menebak, cukup baca sisa TTL-nya.

3. Lacak jalur resolusi dengan +trace

dig contohdomain.com A +trace

Opsi +trace membuat dig melakukan resolusi sendiri dari root server, ke server TLD, lalu ke nameserver otoritatif, tanpa memakai cache resolver. Ini cara terbaik untuk memastikan delegasi nameserver di level TLD sudah mengarah ke provider baru setelah Anda mengganti NS.

4. Cek record email (MX dan TXT)

dig @8.8.8.8 contohdomain.com MX +short
dig @1.1.1.1 contohdomain.com TXT +short
dig @8.8.8.8 _dmarc.contohdomain.com TXT +short

Untuk record SPF dan DMARC, Anda juga bisa memakai SPF Checker dan DMARC Checker untuk melihat apakah sintaksnya valid setelah record tersebar.

Strategi Menurunkan TTL Sebelum Perubahan

Teknik paling efektif untuk mempercepat "propagasi" adalah merencanakannya. Karena yang menentukan adalah TTL record lama, Anda perlu menurunkan TTL sebelum melakukan perubahan, dan memberi waktu agar TTL rendah itu ikut tersimpan di cache.

1. H-2 atau H-1: turunkan TTL record yang akan diubah (misalnya A record @ dan www) dari 86400 atau 3600 menjadi 300.
2. Tunggu minimal sebesar TTL lama. Kalau TTL lama 86400, tunggu setidaknya satu hari agar semua resolver membuang cache lama yang masih ber-TTL panjang.
3. Hari H: ubah nilai record ke IP atau target baru. Sekarang cache hanya bertahan sekitar 5 menit.
4. Pantau dengan dig @8.8.8.8 dan dig @1.1.1.1, serta cek log akses di server lama untuk melihat apakah trafik masih masuk.
5. Setelah stabil (misalnya 1–2 hari), naikkan kembali TTL ke 3600 atau lebih agar beban query lebih rendah dan resolusi tetap cepat.

Kesalahan umum adalah menurunkan TTL bersamaan dengan mengubah IP. Pada skenario itu, resolver yang sudah menyimpan record lama dengan TTL 86400 tetap memegangnya selama satu hari penuh, sehingga penurunan TTL tidak membantu sama sekali.

Jaga server lama tetap hidup

Selama masa transisi, sebagian pengunjung masih akan diarahkan ke server lama. Jangan matikan server lama terlalu cepat. Untuk website dinamis, pertimbangkan membuat situs lama dalam mode baca-saja atau mengarahkan koneksi database ke server baru, agar data tidak terpecah. Untuk email, biarkan server mail lama tetap menerima pesan beberapa hari setelah MX berubah, lalu pindahkan isi mailbox-nya.

Membersihkan Cache di Sisi Anda

Kalau server otoritatif dan resolver publik sudah menampilkan data baru tetapi komputer Anda belum, kemungkinan cache lokal yang menahan. Berikut perintahnya:

# Windows
ipconfig /flushdns

# macOS (versi modern)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux dengan systemd-resolved
resolvectl flush-caches

Google Public DNS dan Cloudflare 1.1.1.1 juga menyediakan halaman web untuk meminta pembersihan cache satu nama domain. Fitur ini berguna jika Anda tidak sabar menunggu, tetapi ingat bahwa itu hanya membersihkan cache di resolver mereka, bukan di ISP lain.

Kesalahan Umum Saat Menunggu Propagasi

• Mengecek hanya dari browser. Browser punya cache sendiri dan mungkin juga cache HTTP. Selalu verifikasi dengan dig.
• Mengubah record di tempat yang salah. Jika domain memakai nameserver Cloudflare, perubahan di panel DNS registrar tidak berpengaruh apa-apa. Pastikan dengan dig NS siapa nameserver aktifnya.
• Lupa titik di akhir nama (FQDN) pada panel yang memakai format zona mentah, sehingga mail.contohdomain.com berubah menjadi mail.contohdomain.com.contohdomain.com.
• Menurunkan TTL terlambat, seperti dijelaskan di atas.
• Mengecek subdomain sebelum dibuat, sehingga terkena negative caching.
• Mengira situs "propagation checker" adalah kebenaran mutlak. Situs tersebut hanya mengambil sampel beberapa resolver di berbagai negara. Berguna sebagai gambaran, tetapi bukan representasi seluruh ISP.

Checklist Migrasi DNS

• Catat semua record yang ada (A, AAAA, CNAME, MX, TXT, SRV) sebelum memindahkan nameserver.
• Turunkan TTL record yang akan diubah, lalu tunggu sebesar TTL lama.
• Ubah record, lalu verifikasi di server otoritatif dengan dig @nameserver.
• Bandingkan dengan dig @8.8.8.8 dan dig @1.1.1.1, baca sisa TTL.
• Biarkan server lama tetap aktif selama masa transisi.
• Kembalikan TTL ke nilai normal setelah stabil.

Jika migrasi Anda melibatkan pemindahan aplikasi Laravel, panduan deploy Laravel ke VPS Ubuntu dengan Nginx bisa membantu menyiapkan server baru sebelum DNS dialihkan. Untuk memahami dasar resolusi nama domain dan pemilihan penyedia, baca juga cara memilih domain dan hosting untuk website.

FAQ Propagasi DNS

Apakah propagasi DNS selalu butuh 24–48 jam?

Tidak. Untuk perubahan record biasa, waktunya sekitar sebesar TTL record lama. Dengan TTL 300, perubahan biasanya terlihat dalam beberapa menit. Angka 24–48 jam lebih relevan untuk pergantian nameserver, karena TTL delegasi di level TLD umumnya panjang.

Bisakah saya memaksa propagasi agar lebih cepat?

Anda tidak bisa memaksa ribuan resolver di seluruh dunia membuang cache-nya. Yang bisa dilakukan adalah menurunkan TTL jauh-jauh hari sebelum perubahan, membersihkan cache lokal, dan meminta flush di resolver publik tertentu yang menyediakan fitur tersebut.

Kenapa di HP sudah berubah tapi di laptop belum?

Kemungkinan besar keduanya memakai resolver berbeda (misalnya data seluler versus Wi-Fi kantor), atau laptop Anda masih menyimpan cache sistem operasi dan browser. Bersihkan cache lokal lalu cek ulang dengan dig.

Berapa TTL yang ideal untuk penggunaan sehari-hari?

Tidak ada angka tunggal yang benar. Nilai 3600 (1 jam) adalah kompromi umum antara kecepatan perubahan dan efisiensi cache. Record yang jarang berubah bisa lebih panjang, sementara record yang sedang dalam masa migrasi sebaiknya 300.

Apakah perubahan record TXT untuk SPF atau DMARC juga terkena propagasi?

Ya, aturan TTL berlaku sama untuk semua jenis record. Server penerima email yang sudah menyimpan record SPF lama akan memakainya sampai TTL habis, jadi perhitungkan hal ini sebelum mengubah layanan pengirim email.