# Cek Propagasi DNS: Perkirakan Sisa Waktu Tunggu Anda URL: https://notificationharbor.com/id/tools/cek-propagasi-dns Type: tool Locale: id Published: 2026-10-07 Updated: 2026-10-08 --- > Perkirakan waktu tunggu terburuk setelah perubahan DNS dari TTL dan waktu sejak Anda menyimpan edit. Berjalan di browser, mencakup record, kunci DKIM baru, dan pergantian nameserver. ## Cek propagasi DNS: berapa lama sampai perubahan Anda aktif Masukkan TTL dan waktu sejak Anda mengubah record. Pengecek propagasi DNS ini menampilkan sisa waktu terburuk untuk perubahan record, kunci DKIM baru, atau pergantian nameserver. ## Pengecek propagasi DNS Pilih jenis perubahan, masukkan TTL yang berlaku, dan waktu sejak Anda menyimpannya. Hasil diperbarui saat Anda mengetik, dan tidak ada data yang meninggalkan browser Anda. *[Interactive widget — see the live page for the full experience]* ## Yang sebenarnya diukur kalkulator ini ### Propagasi adalah kedaluwarsa cache DNS tidak mendorong perubahan ke mana pun. Setiap resolver menyimpan jawaban yang sudah diambilnya sampai TTL habis, lalu bertanya lagi. Resolver paling lambat adalah yang mengambil jawaban lama tepat sebelum edit Anda, sehingga kasus terburuknya sama dengan TTL lama. ### Record baru punya jam sendiri Record yang belum pernah ada tetap bisa disimpan sebagai tidak ada. Jawaban negatif itu berlaku selama nilai yang lebih kecil antara TTL SOA dan field minimum SOA. Jika belum ada yang mencari nama itu lebih awal, record baru langsung terlihat. ### Pergantian nameserver mengikuti registry Mengganti nameserver mengubah record NS di zona induk, dan TTL-nya tidak Anda atur. Kalkulator menerimanya sebagai input, dengan dua hari sebagai nilai umum untuk TLD besar seperti .com. ## Empat langkah untuk memperpendek waktu tunggu 1. **Baca TTL saat ini** — Jalankan dig pada record dan baca angka di bagian answer. Itulah TTL yang harus dilampaui oleh perubahan Anda. 2. **Turunkan lebih awal** — Atur TTL menjadi 300 dtk, lalu tunggu minimal selama TTL lama sebelum Anda mengedit record. Resolver harus membuang salinan berumur panjang lebih dulu. 3. **Lakukan perubahan dan catat waktunya** — Simpan edit, catat jamnya, lalu masukkan waktu yang sudah berlalu ke kalkulator di atas. 4. **Verifikasi di sumber, lalu di resolver** — Query nameserver otoritatif Anda lebih dulu, lalu resolver publik. Naikkan kembali TTL setelah keduanya sama dan jendela waktu sudah berlalu. ## Pertanyaan umum ### Apakah pengecek propagasi DNS ini gratis? Ya. Tanpa pendaftaran dan tanpa batas permintaan. Perhitungannya hanya aritmetika dari tiga angka yang Anda ketik, jadi berjalan di browser dan tidak ada yang dikirim ke server kami. ### Apakah alat ini menanyakan server DNS secara langsung? Tidak. Alat ini tidak mencari record Anda dari resolver di seluruh dunia. Alat ini menghitung waktu terlama jawaban cache bisa bertahan, dari TTL yang Anda masukkan. Untuk melihat apa yang dikembalikan resolver tertentu saat ini, jalankan dig ke resolver itu dan bandingkan dengan jendela waktu yang ditampilkan di sini. ### Mengapa estimasi memakai TTL lama, bukan TTL baru? Resolver menyimpan jawaban yang mereka ambil sebelum edit Anda, beserta TTL yang menyertainya. Menurunkan TTL dalam edit yang sama tidak berpengaruh bagi resolver yang sudah menyimpan jawaban lama. TTL baru hanya berlaku untuk jawaban yang diambil setelah perubahan. ### Apa itu TTL negative caching, dan kapan berlakunya? Ketika resolver menanyakan nama yang tidak punya record, ia bisa menyimpan jawaban "tidak ada" (RFC 2308). Jawaban itu berlaku selama nilai yang lebih kecil antara TTL record SOA dan field minimum-nya. Ini hanya memengaruhi resolver yang pernah mencari nama tersebut sebelum Anda membuat record, misalnya selektor DKIM yang diuji terlalu cepat oleh seseorang. ### Mengapa pergantian nameserver butuh waktu selama ini? Record NS yang mengarah ke nameserver Anda berada di registry, dengan TTL yang tidak bisa Anda kendalikan. Untuk TLD besar seperti .com, TTL itu umumnya dua hari. Selama belum habis, sebagian resolver terus menanyakan nameserver lama Anda. ### Saya sudah melewati jendela waktu tapi masih melihat nilai lama. Apa yang harus dilakukan? Berhenti menyalahkan cache. Query nameserver otoritatif Anda langsung dan pastikan ia menyajikan nilai baru. Jika belum, edit masuk ke zona yang salah, nama host yang salah, atau memang tidak tersimpan. Jika sudah, uji dari resolver yang belum pernah Anda gunakan, dan periksa cache lokal di mesin atau jaringan Anda. ### Apakah ini berlaku untuk record SPF, DKIM, dan DMARC? Ya. Ketiganya adalah record TXT dan di-cache seperti record lain. Server penerima yang menyimpan record SPF lama Anda akan terus mengevaluasinya sampai TTL habis, sehingga pengiriman tepat setelah edit bisa dinilai dengan kebijakan lama. ## Pantau infrastruktur di balik pengiriman email Anda Alat ini hanya memperkirakan waktu tunggu. Notification Harbor mengurus pengiriman yang bisa Anda kendalikan: pemanasan domain, observabilitas tingkat trace, serta SPF, DKIM, dan DMARC yang disiapkan dengan benar sebelum pengiriman produksi pertama. *Call to action: Lihat cara kerja Notification Harbor* ## FAQ ### Apakah pengecek propagasi DNS ini gratis? Ya. Tanpa pendaftaran dan tanpa batas permintaan. Perhitungannya hanya aritmetika dari tiga angka yang Anda ketik, jadi berjalan di browser dan tidak ada yang dikirim ke server kami. ### Apakah alat ini menanyakan server DNS secara langsung? Tidak. Alat ini tidak mencari record Anda dari resolver di seluruh dunia. Alat ini menghitung waktu terlama jawaban cache bisa bertahan, dari TTL yang Anda masukkan. Untuk melihat apa yang dikembalikan resolver tertentu saat ini, jalankan dig ke resolver itu dan bandingkan dengan jendela waktu yang ditampilkan di sini. ### Mengapa estimasi memakai TTL lama, bukan TTL baru? Resolver menyimpan jawaban yang mereka ambil sebelum edit Anda, beserta TTL yang menyertainya. Menurunkan TTL dalam edit yang sama tidak berpengaruh bagi resolver yang sudah menyimpan jawaban lama. TTL baru hanya berlaku untuk jawaban yang diambil setelah perubahan. ### Apa itu TTL negative caching, dan kapan berlakunya? Ketika resolver menanyakan nama yang tidak punya record, ia bisa menyimpan jawaban "tidak ada" (RFC 2308). Jawaban itu berlaku selama nilai yang lebih kecil antara TTL record SOA dan field minimum-nya. Ini hanya memengaruhi resolver yang pernah mencari nama tersebut sebelum Anda membuat record, misalnya selektor DKIM yang diuji terlalu cepat oleh seseorang. ### Mengapa pergantian nameserver butuh waktu selama ini? Record NS yang mengarah ke nameserver Anda berada di registry, dengan TTL yang tidak bisa Anda kendalikan. Untuk TLD besar seperti .com, TTL itu umumnya dua hari. Selama belum habis, sebagian resolver terus menanyakan nameserver lama Anda. ### Saya sudah melewati jendela waktu tapi masih melihat nilai lama. Apa yang harus dilakukan? Berhenti menyalahkan cache. Query nameserver otoritatif Anda langsung dan pastikan ia menyajikan nilai baru. Jika belum, edit masuk ke zona yang salah, nama host yang salah, atau memang tidak tersimpan. Jika sudah, uji dari resolver yang belum pernah Anda gunakan, dan periksa cache lokal di mesin atau jaringan Anda. ### Apakah ini berlaku untuk record SPF, DKIM, dan DMARC? Ya. Ketiganya adalah record TXT dan di-cache seperti record lain. Server penerima yang menyimpan record SPF lama Anda akan terus mengevaluasinya sampai TTL habis, sehingga pengiriman tepat setelah edit bisa dinilai dengan kebijakan lama.