Anda memperbarui catatan A. Server baru Anda sedang berjalan. Anda menavigasi ke domain Anda — dan Anda masih melihat situs lama. Atau seseorang di negara lain melihat situs baru tersebut tetapi Anda tidak. Atau keduanya terjadi secara bersamaan untuk pengguna yang berbeda.

Ini adalah propagasi DNS. Ini bukan bug dan bukan registrar Anda yang lambat. Inilah yang sebenarnya terjadi dan cara mengelolanya.

Apa itu Propagasi DNS?

DNS (Sistem Nama Domain) adalah database terdistribusi secara global yang memetakan nama domain ke alamat IP. Ini bukan server tunggal — ini adalah hierarki ribuan penyelesai, masing-masing menyimpan jawaban dalam cache untuk jangka waktu tertentu.

Saat Anda memperbarui catatan DNS, Anda mengubah data di server nama resmi — yang dikontrol oleh registrar atau penyedia DNS Anda. Namun bagian internet lainnya tidak menanyakan server resmi Anda secara langsung. Mereka bertanya pada mereka penyelesai rekursif lokal (biasanya dijalankan oleh ISP mereka atau layanan DNS publik sejenisnya 1.1.1.1 atau 8.8.8.8), yang memiliki salinan catatan Anda yang disimpan dalam cache.

Propagasi adalah proses salinan cache tersebut kedaluwarsa dan diganti dengan catatan baru Anda.

Rantai Penyelesai DNS Lengkap

Pemahaman kenapa propagasi memerlukan waktu dan memerlukan pemahaman tentang cara kerja kueri DNS:

Diagram rantai penyelesai DNS yang menunjukkan bagaimana kueri berpindah dari perangkat melalui penyelesai ISP, server akar, server TLD ke server nama otoritatif
Rantai pencarian DNS lengkap. Langkah 2–4 biasanya dilewati karena penyelesai rekursif sudah memiliki jawaban yang di-cache — itulah sebabnya propagasi memerlukan waktu.

Langkah 1 — Browser Anda memeriksa cache lokalnya. Browser modern melakukan cache hasil DNS secara independen dari OS. Cache Chrome selama 60 detik; Firefox hingga nilai TTL. chrome://net-internals/#dns menunjukkan cache Chrome saat ini.

Langkah 2 — Penyelesai rintisan OS Anda memeriksa cache-nya. Windows, macOS, dan Linux semuanya memelihara cache DNS lokal (dibilas dengan ipconfig /flushdns, dscacheutil -flushcache, atau resolvectl flush-caches masing-masing).

Langkah 3 — Resolver rekursif Anda ditanyakan. Ini biasanya merupakan penyelesai ISP Anda, 1.1.1.1, 8.8.8.8, atau server DNS perusahaan. Ia memiliki cache sendiri, terpisah dari cache Anda, dan dibagikan ke semua penggunanya. Jika 10.000 orang menggunakan pemecah masalah ISP yang sama, satu jawaban yang di-cache akan melayani semuanya.

Langkah 4 — Resolver rekursif menjalankan hierarki (jika cache-nya kosong). Ia meminta server nama root untuk TLD, server TLD untuk server nama otoritatif, lalu server otoritatif untuk catatan Anda. Ini menyimpan jawaban dengan TTL yang Anda tentukan.

Propagasinya lambat karena: langkah 4 hanya berjalan ketika cache penyelesai telah kedaluwarsa. Sampai saat itu, ia menyajikan jawaban cache lama — terlepas dari apa yang Anda ubah di server resmi.

TTL: Angka yang Mengontrol Segalanya

TTL (Time To Live) adalah nilai yang Anda tetapkan pada setiap data DNS, diukur dalam hitungan detik. Ini memberi tahu penyelesai berapa lama untuk menyimpan data Anda dalam cache sebelum menanyakan ulang server resmi.

Nilai TTL umum:

TTL Detik Penggunaan umum
1 menit 60 Migrasi aktif, pengujian
5 menit 300 Pra-migrasi (ditetapkan 24 jam sebelumnya)
15 menit 900 Catatan yang sering diubah
1 jam 3600 Standar untuk sebagian besar rekaman
4 jam 14400 Catatan stabil
24 jam 86400 Default untuk banyak penyedia
48 jam 172800 Catatan server nama (NS).

TTL yang Anda atur menentukan maksimal jendela propagasi. Tapi ada batasannya.

Bagan yang menunjukkan waktu propagasi DNS vs nilai TTL dengan skenario kasus terbaik, tipikal, dan terburuk
Kasus terbaik mencerminkan penyelesai yang benar-benar menghormati TTL. Kasus terburuk: beberapa penyelesai ISP melakukan cache jauh melampaui TTL yang dinyatakan, terutama untuk TTL pendek — memperlakukan apa pun yang kurang dari 5 menit sebagai "5 menit" untuk mengurangi beban.

Rahasia kotor tentang TTL: banyak ISP mengabaikan nilai TTL yang rendah. Penyelesai yang melayani jutaan pengguna tidak mampu melakukan kueri ulang setiap 60 detik untuk domain dengan lalu lintas tinggi. Beberapa menerapkan waktu cache minimum 5 menit terlepas dari apa yang Anda nyatakan. Ini berarti TTL yang sangat rendah (60–300 detik) berperilaku lebih seperti TTL 5 menit dalam praktiknya untuk sebagian penyelesai.

TTL 24 jam berarti beberapa pengguna mungkin melihat catatan lama Anda selama 24 jam penuh setelah Anda melakukan perubahan — bahkan jika Anda mengubahnya segera setelah masa berlaku TTL sebelumnya habis.

Berapa Lama Sebenarnya Propagasi DNS?

Bagan garis waktu bergaya Gantt yang menunjukkan propagasi DNS ke berbagai wilayah dunia setelah perubahan data DNS
Garis waktu propagasi regional untuk rekaman dengan TTL 1 jam. Resolver lokal memperbarui paling cepat; ISP outlier yang mengabaikan TTL dapat mengalami keterlambatan selama berjam-jam. Ini menjelaskan mengapa beberapa pengguna melihat situs baru Anda sementara yang lain melihat situs lama.

Dengan TTL standar 1 jam, berikut yang diharapkan:

  • Perangkat lokal Anda: hampir seketika setelah membersihkan cache
  • Penyelesai kota yang sama: 5–30 menit (resolver menanyakan secara resmi ketika cache-nya habis masa berlakunya)
  • DNS publik utama (8.8.8.8, 1.1.1.1): biasanya 10–60 menit
  • Penyebaran ke seluruh dunia: 1–4 jam untuk sebagian besar pengguna
  • ISP lambat/outlier: hingga 8–12 jam

Angka "hingga 48 jam" yang Anda lihat di mana pun secara teknis mungkin terjadi, tetapi semakin jarang untuk data A dan CNAME dengan TTL normal. Ini lebih akurat untuk perubahan catatan NS (server nama), yang memiliki TTL bawaan yang lebih panjang dan menyebar melalui lapisan root/TLD.

Mengapa tepatnya 48 jam? Catatan NS sering kali memiliki TTL yang ditetapkan oleh registri (bukan Anda), biasanya 24–48 jam. Saat Anda mengubah server nama di registrar, Anda menunggu registri TLD diperbarui — dan pembaruan tersebut menyebar melalui server root di seluruh dunia. Jalur ini membutuhkan waktu lebih lama dibandingkan perubahan rekaman sederhana dalam server nama tetap.

Pendekatan Profesional: Turunkan TTL Anda terlebih dahulu

Kesalahan terbesar yang dilakukan orang dengan migrasi DNS: mengubah catatan tanpa menurunkan TTL terlebih dahulu.

Proses yang benar untuk migrasi terencana:

  1. 48 jam sebelum migrasi: Turunkan TTL menjadi 300 detik (5 menit) pada semua rekaman yang ingin Anda ubah
  2. Tunggu TTL penuh saat ini sebelum jendela migrasi (beri waktu bagi penyelesai untuk mengambil TTL pendek yang baru)
  3. Ubah catatan Anda — propagasi sekarang memakan waktu maksimal 5 menit, bukan 24 jam
  4. Setelah migrasi stabil: menaikkan TTL kembali ke 3600 atau lebih tinggi Rentang

Inilah perbedaan antara jendela propagasi 5 menit dan 24 jam. Setiap profesional DNS melakukan ini. Kebanyakan pemula belajar dengan cara yang sulit.

Cara Memeriksa Propagasi DNS Saat Ini

Cara tercepat: gunakan milik kami Pemeriksa Propagasi DNS — ini menanyakan domain Anda dari beberapa lokasi geografis secara bersamaan dan menunjukkan apakah setiap wilayah mengembalikan data lama atau baru.

Apa yang Anda cari:

  • Hijau / IP yang cocok: wilayah tersebut melihat rekor baru Anda
  • IP lama masih ditampilkan: Resolver tersebut belum kehabisan cache-nya
  • Hasil yang beragam: normal selama propagasi — beberapa wilayah melihat yang baru, sebagian lagi melihat yang lama

Periksa melalui baris perintah jika Anda ingin memverifikasi jawaban resmi secara langsung (melewati cache apa pun):

Perintah 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

Jika dig @ns1.yourprovider.com menunjukkan rekor baru Anda tetapi dig @8.8.8.8 masih menampilkan yang lama, perubahan Anda sudah benar — Anda hanya menunggu cache penyelesai rekursif kedaluwarsa.

Bersihkan cache DNS lokal Anda untuk berhenti melihat data basi di mesin Anda sendiri:

Perintah 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

Catatan: membersihkan cache lokal Anda tidak membantu jika penyelesai ISP Anda masih memiliki jawaban lama yang di-cache. Perangkat Anda hanya akan menanyakan ulang penyelesai ISP Anda dan mendapatkan jawaban basi lagi.

Skenario Propagasi DNS Umum

Skenario 1: Migrasi Situs Web ke Server Baru

Anda pindah dari host lama → host baru. Rekor A lama: 203.0.113.10. Baru: 198.51.100.20.

Apa yang terjadi selama propagasi: pengguna dengan catatan lama yang di-cache mendarat di server lama. Pengguna yang penyelesainya telah disegarkan akan melihat server baru. Kedua server harus berjalan dan menyajikan konten yang sama hingga propagasi selesai. Jika Anda mematikan server lama terlalu dini, pengguna dengan cache basi akan mengalami kesalahan.

Mitigasi: menjaga server lama tetap hidup setidaknya selama satu TTL penuh setelah perubahan. Jika TTL asli adalah 24 jam, pertahankan server lama tetap aktif 24 jam setelah perubahan.

Skenario 2: Migrasi Penyedia Email (Catatan MX)

Perubahan data MX memengaruhi tujuan pengiriman email masuk. Email yang dikirim selama propagasi mungkin masuk ke server email lama atau baru bergantung pada data MX mana yang diselesaikan oleh server pengirim.

Resiko: email dikirim ke server lama setelah Anda berhenti memantaunya. Perbaikan: konfigurasikan server email lama untuk meneruskan ke server baru selama seminggu setelah migrasi, atau biarkan kotak pesan lama tetap dapat diakses selama jendela TTL.

Skenario 3: CDN atau Load Balancer Cutover (perubahan CNAME)

Data CNAME yang menunjuk ke CDN atau penyeimbang beban biasanya menyebar lebih cepat daripada data A — CNAME itu sendiri menyimpan cache, namun IP dasar yang dikembalikan CDN dapat berubah dengan cepat tanpa memengaruhi penyebaran data Anda.

Hati-hati terhadap: Perataan CNAME. Beberapa penyedia DNS "meratakan" data CNAME di puncak zona (mengganti CNAME dengan data A yang ditentukan). Hal ini dapat menyebabkan perilaku tak terduga selama migrasi jika penyedia menyimpan IP yang diratakan dalam cache.

Skenario 4: Perubahan Server Nama (Catatan NS).

Jenis propagasi paling lambat. Catatan server nama disimpan di tingkat registri TLD (.com, .net, dll.) dengan TTL yang ditetapkan oleh registri, biasanya 24–48 jam. Anda tidak mengontrol TTL ini.

Saat Anda mengubah server nama di registrar Anda:

  1. Pendaftar Anda memberi tahu registri TLD
  2. Registri memperbarui delegasi
  3. Pembaruan registri menyebar ke seluruh server nama root di seluruh dunia

Harapkan 12–48 jam untuk propagasi penuh. Tidak ada trik pra-penurunan TTL yang membantu di sini.

Daftar Periksa Pemecahan Masalah

✅ Jika perubahan DNS Anda tidak menyebar

1. Konfirmasikan kebenaran data baru di <strong>server resmi</strong>: <code>dig example.com @ns1.yourprovider.com</code><br> 2. Periksa apa yang dilihat oleh beberapa penyelesai publik: <a href="/dns-propagation.php">Alat Propagasi DNS →</a><br> 3. Hapus cache lokal Anda (perintah di atas) — Anda mungkin hanya melihat cache Anda sendiri cache basi<br> 4. Periksa TTL Anda: <code>gali example.com | grep TTL</code> — jika 86400, Anda menunggu hingga 24 jam<br> 5. Jika otoritatif menunjukkan benar tetapi penyelesai tidak: tunggu hingga TTL kedaluwarsa — tidak ada lagi yang bisa dilakukan<br> 6. Jika otoritatif menunjukkan catatan yang salah: Anda membuat perubahan di penyedia yang salah, atau perubahan belum disimpan

Propagasi DNS vs Replikasi DNS: Perbedaannya

Hal ini sering membingungkan. Keduanya terkait tetapi berbeda:

Propagasi DNS = menunggu cache penyelesai rekursif kedaluwarsa dan melakukan kueri ulang. Ini adalah penundaan yang Anda alami sebagai pengguna. Anda tidak bisa memaksanya. Anda hanya dapat menguranginya dengan menurunkan TTL terlebih dahulu.

Replikasi DNS = menyinkronkan antara beberapa server nama resmi untuk zona yang sama (misalnya, ns1.provider.com dan ns2.provider.com). Kebanyakan penyedia DNS mereplikasi dalam hitungan detik. Jika Anda melakukan perubahan dan perubahan tidak muncul di server nama penyedia Anda dalam waktu 5 menit, itu adalah masalah di pihak penyedia — hubungi dukungan.

Alat