Mist Network
Waktu Propagasi DNS: Berapa Lama Sebenarnya dan Cara Mempercepatnya
Perubahan DNS tidak didorong ke mana pun; jawaban lama hanya kedaluwarsa dari cache. Pelajari apa yang sebenarnya menentukan waktu propagasi DNS dan cara membuat perubahan berikutnya selesai dalam hitungan menit.
Waktu propagasi DNS adalah jeda antara saat Anda menyimpan perubahan DNS dan saat semua resolver di internet mengembalikan jawaban baru. Untuk edit record biasa, umumnya beberapa menit hingga sebesar TTL lama record tersebut; untuk penggantian nameserver bisa sampai 24–48 jam, karena record delegasi di zona induk di-cache lebih lama.
Kata "propagasi" sebenarnya agak menyesatkan. Tidak ada yang disiarkan ke seluruh internet. Server DNS otoritatif Anda sudah tahu nilai baru begitu Anda menekan simpan. Yang Anda tunggu adalah ribuan cache independen, di ISP, resolver publik, router dan sistem operasi, untuk membuang jawaban yang mereka simpan sebelumnya lalu bertanya lagi.
Kenapa perubahan DNS tidak instan
Setiap jawaban DNS membawa TTL (time to live), yaitu jumlah detik yang memberi tahu resolver berapa lama ia boleh memakai ulang jawaban itu tanpa bertanya lagi. Jika A record Anda punya TTL 3600 saat resolver ISP pengunjung mencarinya, resolver itu boleh terus menyajikan IP lama hingga satu jam setelah Anda mengubahnya, secepat apa pun penyedia DNS Anda.
Itulah seluruh mekanismenya. Resolver yang berbeda mengambil record Anda pada saat yang berbeda, sehingga salinan mereka kedaluwarsa pada saat yang berbeda pula. Inilah sebabnya satu teman sudah melihat situs baru sementara yang lain masih melihat situs lama, dan mengapa situs "cek propagasi DNS" menampilkan campuran lokasi hijau dan merah untuk sementara waktu.
Propagasi DNS berapa lama? Waktu yang umum
Jawabannya tergantung apa yang Anda ubah. Tabel di bawah menunjukkan rentang yang realistis, dengan asumsi cache menghormati TTL (sebagian besar resolver besar melakukannya).
| Perubahan | Penentu jeda | Waktu umum |
|---|---|---|
| Edit record A, AAAA atau CNAME | TTL lama record tersebut | 1 menit – TTL lama (sering 5 menit hingga 1 jam) |
| Menambah record yang benar-benar baru | Negative caching (SOA minimum) | Instan jika belum pernah dikueri; jika sudah, beberapa menit hingga sekitar satu jam |
| Mengubah MX atau TXT (SPF, DKIM, verifikasi) | TTL lama record set | Beberapa menit hingga beberapa jam |
| Mengganti nameserver di registrar | TTL record NS di zona TLD | Beberapa jam, hingga 24–48 jam |
| Mendaftarkan domain baru | Registry memublikasikan delegasi | Biasanya beberapa menit |
Baris "record baru" sering mengejutkan. Jika Anda, atau sebuah tool, mencari app.example.com sebelum record itu ada, resolver menyimpan jawaban "tidak ada". Jawaban negatif itu juga di-cache, selama periode yang diturunkan dari record SOA zona, sebagaimana didefinisikan di RFC 2308. Hindari menguji hostname sebelum Anda membuatnya.
Perubahan record vs perubahan nameserver
Perubahan record di dalam zona yang sama
Jika Anda hanya mengedit record, misalnya memindahkan situs ke server baru dengan memperbarui A record, Anda hanya berurusan dengan satu lapisan cache dan satu TTL. Jika TTL-nya 300 detik, praktis semua orang melihat IP baru dalam sekitar lima menit. Inilah kasus yang cepat dan bisa diprediksi, dan itulah yang terjadi saat Anda mengikuti panduan kami tentang cara mengarahkan domain ke VPS.
Perubahan nameserver
Mengganti nameserver berarti memindahkan seluruh zona ke penyedia DNS lain. Resolver mengetahui nameserver mana yang otoritatif dari server milik TLD, dan untuk TLD besar record delegasi itu umumnya ber-TTL satu atau dua hari. Anda tidak bisa menurunkan TTL tersebut; registry yang menetapkannya. Dari situlah angka terkenal "hingga 48 jam" berasal.
Selama jendela waktu itu sebagian resolver masih bertanya ke penyedia lama dan sebagian ke penyedia baru. Jika kedua zona tidak identik, pengunjung mendapat jawaban berbeda. Pola yang aman adalah membuat ulang semua record di penyedia baru terlebih dahulu, mengeceknya langsung, baru kemudian mengganti nameserver. Jika Anda masih menimbang perlu tidaknya memindahkan DNS, baca dulu DNS Cloudflare vs DNS registrar.
Cara mempercepat propagasi DNS (cara yang praktis)
Anda tidak bisa memaksa resolver orang lain mengosongkan cache-nya, tetapi Anda bisa memastikan hanya sedikit yang ter-cache untuk ditunggu. Rencanakan perubahannya seperti ini:
- Turunkan TTL lebih awal — setidaknya satu periode TTL lama penuh sebelum perubahan (untuk TTL 1 jam, beberapa jam sebelumnya), atur record yang akan diubah ke 60–300 detik.
- Siapkan tujuan — pastikan server, mailbox atau layanan baru sudah menjawab dengan benar, agar trafik yang datang lebih awal tetap tertangani.
- Lakukan perubahan — perbarui record. Karena cache kini hanya menyimpannya satu sampai lima menit, perpindahan menyebar hampir seketika.
- Verifikasi dari luar — kueri beberapa resolver publik dan server otoritatif secara langsung (lihat bagian berikutnya).
- Biarkan target lama hidup sebentar — tetap jalankan server lama setidaknya selama TTL lama ditambah margin aman, agar pengunjung yang tertinggal tidak menabrak IP mati.
- Naikkan lagi TTL — setelah stabil, kembalikan ke nilai yang lebih panjang seperti 3600 untuk mengurangi lookup dan menambah ketahanan.
Cara cek propagasi DNS
Mulailah dari sumber kebenaran: tanyakan langsung ke nameserver otoritatif Anda. Jika ia mengembalikan nilai baru, bagian Anda sudah selesai dan sisanya urusan cache. Perintah yang umum:
dig +short example.com A @ns1.yourprovider.com— jawaban otoritatif.dig +short example.com A @1.1.1.1dan@8.8.8.8— apa yang saat ini dikembalikan dua resolver publik besar. TTL yang tampil di output lengkapdigterus menghitung mundur; saat mencapai nol, kueri berikutnya mengambil nilai baru.nslookup example.com— tersedia di Windows saat dig tidak ada.dig NS example.com +trace— menelusuri delegasi dari root, berguna untuk memastikan perubahan nameserver di level TLD.
Situs "cek propagasi DNS" global menjalankan kueri yang sama dari banyak negara. Praktis untuk gambaran visual, tetapi ingat bahwa situs tersebut hanya mencerminkan segelintir resolver, bukan semua ISP.
Membersihkan cache Anda sendiri
Sering kali jawaban usang justru ada di perangkat Anda sendiri. Flush cache OS (ipconfig /flushdns di Windows, sudo resolvectl flush-caches di banyak sistem Linux, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder di macOS), restart browser, atau uji dengan data seluler untuk melewati router rumah.
Contoh: memindahkan situs ke server baru
Misalkan Anda memindahkan situs dari shared hosting lama ke VPS baru, dan A record Anda saat ini ber-TTL 3600 detik. Jadwal tanpa downtime bisa seperti ini:
- Senin pagi: turunkan TTL record A dan www ke 300 detik. Tunggu setidaknya satu jam agar cache satu jam yang lama habis, atau lakukan perpindahan keesokan harinya agar aman.
- Sebelum perpindahan: salin file dan database ke server baru, lalu uji situs di IP baru menggunakan file hosts komputer Anda.
- Perpindahan: perbarui A record. Karena cache menyimpannya paling lama lima menit, trafik mulai mengalir ke server baru dalam hitungan menit.
- Keesokan harinya: setelah log server lama tidak lagi menunjukkan kunjungan, matikan server itu dan naikkan kembali TTL ke 3600.
Untuk situs berbasis database, hentikan sebentar proses tulis seperti komentar atau pesanan selama perpindahan; jika tidak, beberapa entri terakhir yang masuk ke server lama mungkin tidak pernah sampai ke server baru. Jika Anda memindahkan email, terapkan logika yang sama pada record MX dan biarkan mailbox lama tetap terbuka beberapa hari.
Masalah propagasi yang umum dan solusinya
- Berfungsi untuk Anda, tidak untuk orang lain — cek server otoritatif; jika sudah benar, Anda tinggal menunggu cache. Jika belum, record disimpan di zona atau penyedia yang salah.
- Masih lama setelah 48 jam — biasanya domain memakai nameserver yang berbeda dari yang Anda edit. Bandingkan record NS di registrar dengan tempat Anda melakukan perubahan.
- Email bounce setelah pindah — record MX, SPF dan DKIM belum disalin ke zona baru sebelum nameserver diganti.
- Sertifikat SSL gagal terbit — validasi otoritas sertifikat masih mengenai IP lama, atau ada record CAA yang memblokirnya. Tunggu TTL habis lalu coba lagi.
Waktu propagasi DNS di mistREG
Domain yang didaftarkan di mistREG mendapatkan zona DNS yang di-host di jaringan otoritatif Cloudflare dan dikelola dari panel mistREG, sehingga perubahan langsung aktif di server otoritatif hampir seketika. Anda bisa memilih TTL berapa pun dari 60 hingga 86.400 detik atau membiarkannya "otomatis", sehingga rutinitas turunkan-TTL-dulu di atas mudah diikuti.
Record disajikan dalam mode DNS only, artinya IP yang Anda masukkan persis IP yang diterima pengunjung. Jika Anda lebih suka nameserver sendiri, Anda bisa mengatur nameserver kustom kapan saja; domain kemudian keluar dari zona yang di-host Cloudflare dan jendela propagasi nameserver yang biasa berlaku. Anda bisa mencari domain di 200+ TLD, membaca FAQ, atau menghubungi support lewat Telegram di @mistnetwork atau melalui sistem tiket di panel. Seperti biasa, penggunaan layanan tunduk pada ketentuan penyedia.
