Propagasi DNS: pengertian dan cara meminimalkan dampaknya

Propagasi DNS adalah periode ketika sebagian resolver masih terus menyajikan nilai lama sebuah record setelah record itu diubah di name server otoritatif. Sebenarnya tidak ada yang disebarkan ke seluruh internet: setiap resolver menyimpan jawabannya di cache sampai TTL habis. Jedanya berkisar dari beberapa menit hingga 24 atau 48 jam pada pergantian name server, bergantung pada TTL record sebelum perubahan dan, untuk name server, pada TTL delegasi yang ditetapkan registri. Berikut cara kerjanya dan cara meminimalkan dampaknya.

Poin utama

• Perubahan Anda terlihat seketika di server otoritatif. Jeda hanya berasal dari cache resolver, yang menyimpan nilai lama sampai TTL-nya habis.
• Berapa lama nilai lama bertahan ditentukan oleh TTL yang berlaku sebelum perubahan, bukan TTL yang baru Anda isi. Turunkan TTL jauh-jauh hari.
• Pergantian name server adalah yang paling lambat, karena bergantung pada TTL delegasi registri yang tidak Anda kendalikan.
• Galat "nama ini tidak ada" juga disimpan di cache: mengakses sebuah nama sebelum record dibuat dapat memperpanjang galat tersebut.

Apa yang bukan propagasi DNS: sebuah siaran

Istilah ini menyesatkan. Tidak ada server yang mengirim perubahan Anda ke server lain. Saat Anda menyimpan perubahan di penyedia DNS, name server otoritatif untuk zona itu langsung menyajikan nilai baru. Jedanya terjadi di tempat lain, yaitu di cache.

Ketika sebuah perangkat mencari alamat dari nama domain, permintaan melewati beberapa lapisan, dan masing-masing dapat mengingat jawabannya:

• browser, yang cache-nya biasanya bertahan sekitar satu menit dan tidak selalu mematuhi TTL;
• sistem operasi, yang menyimpan jawaban terbaru;
• resolver rekursif milik penyedia internet atau layanan publik (misalnya 8.8.8.8 di Google, 1.1.1.1 di Cloudflare), yang menelusuri hierarki DNS lalu menyimpan hasilnya.

Setiap resolver menerapkan TTL yang diberikan server otoritatif pada saat resolver itu menyimpan jawaban. Karena tidak semuanya bertanya pada waktu yang sama, salinan mereka kedaluwarsa pada saat yang berbeda. Record dengan TTL 3.600 detik yang disimpan 5 menit lalu akan diperbarui dalam 55 menit. Itu sebabnya muncul laporan yang saling bertentangan: satu orang melihat situs baru, yang lain situs lama, orang ketiga mendapat galat.

Berapa lama propagasi DNS berlangsung

Durasinya bergantung pada jenis perubahan. TTL satu hari (86.400 detik) umum digunakan, dan nilainya lebih tinggi untuk record yang jarang berubah, seperti name server.

Tiga faktor yang menentukan jeda

TTL dari sebelum perubahan

Misalkan sebuah record punya TTL 86.400 detik dan hari ini Anda mengaturnya menjadi 300. Resolver yang menyimpannya kemarin akan menahan nilai lama hingga 24 jam, apa pun nilai barunya: TTL 300 detik baru berlaku setelah salinannya diperbarui. Pada CNAME, setiap nama dalam rantai punya TTL sendiri, dan yang terpanjang menentukan total jeda.

Delegasi di registri

Saat mengganti name server, perubahan dilakukan di registrar, yang meneruskannya ke registri domain tingkat atas. Resolver yang masih mengetahui daftar name server lama akan terus menanyainya sampai delegasi kedaluwarsa. TTL ini milik registri: Anda tidak dapat mempersingkatnya.

Resolver yang tidak mengikuti TTL secara harfiah

Sebagian resolver membatasi atau menaikkan nilai TTL, dan browser memiliki cache sendiri yang berumur pendek. Jadi durasi yang sama tidak dapat dijamin di semua tempat. TTL adalah batas teoretis, bukan janji dari setiap cache.

Jebakan cache negatif

Sebagian besar panduan membahas TTL record dan melupakan jawaban negatif. Ketika sebuah resolver mengetahui bahwa suatu nama tidak ada (respons NXDOMAIN) atau tidak memiliki record bertipe yang diminta, ia dapat mengingat ketiadaan itu. RFC 2308 menetapkan durasi cache negatif sebagai nilai yang lebih kecil dari dua hal: TTL SOA zona dan kolom MINIMUM-nya. RFC menilai durasi satu sampai tiga jam wajar dan memperingatkan bahwa nilai di atas satu hari menimbulkan masalah.

Skenario yang khas: Anda mencoba baru.example.com sebelum membuat record, mendapat galat, lalu membuat record. Bagi resolver Anda, nama itu "tidak ada" sampai cache negatif berakhir, meskipun record sudah aktif selama satu menit. Cara menghindarinya:

• buat record sebelum menguji atau mengumumkan nama;
• jika penyedia DNS Anda mengizinkan penyesuaian SOA, jaga kolom MINIMUM tetap sedang;
• kosongkan cache lokal sebelum menyimpulkan bahwa "tidak berfungsi": Microsoft menyatakan bahwa ipconfig /flushdns juga membuang entri cache negatif.

Metode meminimalkan dampak migrasi

1. Catat TTL saat ini dari setiap record yang terlibat (lihat perintah di bawah). TTL itulah yang menentukan jeda.
2. Turunkan TTL menjadi 300 detik, setidaknya sejauh durasi TTL lama sebelum pengalihan. Dengan 86.400 detik, lakukan 24 sampai 48 jam sebelum pengalihan. Periksa batas minimum yang diterima penyedia Anda.
3. Siapkan tujuan baru: situs web, server surel, atau CDN yang siap menjawab dengan konten yang sama seperti yang lama. Keduanya harus berfungsi selama masa transisi.
4. Alihkan record, satu perubahan dalam satu waktu agar Anda tahu apa yang perlu diperiksa.
5. Verifikasi server otoritatif lebih dulu, lalu resolver publik.
6. Biarkan server lama tetap berjalan setidaknya sampai TTL lama terpanjang berlalu, baru kemudian matikan.
7. Naikkan TTL kembali (3.600 detik atau lebih) setelah semuanya stabil.

Untuk pergantian name server, buat ulang dulu seluruh zona di penyedia baru (A, CNAME, MX, TXT termasuk SPF dan DKIM, serta semua yang lain), pastikan zona itu menjawab dengan benar, baru ganti name server di registrar. Biarkan zona di penyedia lama tetap aktif dan identik selama 48 jam: resolver yang masih mengetahui delegasi lama terus menanyainya.

Memeriksa apa yang dilihat setiap resolver

Perintah dig (macOS, Linux) atau nslookup (Windows) memungkinkan Anda membandingkan jawaban server otoritatif dan beberapa resolver publik.

# Nilai dan sisa TTL yang dilihat resolver publik
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Name server yang dideklarasikan untuk domain
dig +short NS example.com

# Nilai yang disajikan server otoritatif (ganti dengan name server Anda)
dig +noall +answer example.com A @ns1.penyedia-dns.example

# Nomor seri SOA, untuk dibandingkan antar name server
dig +short SOA example.com @ns1.penyedia-dns.example
dig +short SOA example.com @ns2.penyedia-dns.example

# Padanan di Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

Pada jawaban sebuah resolver, TTL yang ditampilkan menurun dari satu kueri ke kueri berikutnya: itulah sisa waktu sebelum salinannya kedaluwarsa. Jika resolver mengembalikan nilai lama dengan TTL yang terus menghitung mundur sementara server otoritatif sudah mengembalikan nilai baru, Anda tinggal menunggu.

Bandingkan juga nomor seri SOA di antara name server Anda. Jika berbeda, ada server yang menyajikan data usang: masalahnya ada pada penyedia DNS Anda, bukan pada propagasi. Halaman dns.google memungkinkan Anda menanyakan tipe record tertentu, termasuk SOA, dan panduan pemecahan masalah Google Public DNS menjelaskan pemeriksaan ini.

Mengosongkan cache yang Anda kendalikan

Mengosongkan cache Anda sendiri tidak mengubah apa pun bagi pengunjung lain, tetapi menunjukkan apa yang sebenarnya Anda lihat.

# Windows (command prompt)
ipconfig /flushdns

# macOS terbaru
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux dengan systemd-resolved
resolvectl flush-caches

Microsoft menjelaskan /flushdns dan /displaydns di halaman perintah ipconfig. Setelah itu tutup browser sepenuhnya, karena browser menyimpan memori jangka pendeknya sendiri.

Dua resolver publik juga menawarkan pembersihan, berguna setelah pergantian name server atau bagi pengguna layanan tersebut: alat Flush Cache Google Public DNS (Google menyarankan membersihkan baik domain terdaftar maupun nama persis yang mengembalikan jawaban usang) dan alat pembersih cache 1.1.1.1 dari Cloudflare, tempat Anda memilih domain dan tipe record. Resolver milik penyedia internet tidak dapat dibersihkan: Anda harus menunggu salinannya kedaluwarsa.

Kesalahan yang sering terjadi

• Menurunkan TTL pada saat pengalihan. Sudah terlambat: resolver menyimpan salinan yang dibuat dengan TTL lama.
• Menguji nama sebelum membuat record. Cache negatif dapat memperpanjang galat.
• Mengganti name server sebelum membuat ulang seluruh zona. Record surel atau subdomain yang terlupa berhenti berfungsi bagi resolver yang sudah menanyai penyedia baru.
• Mematikan server lama terlalu cepat. Pengunjung yang cache-nya belum kedaluwarsa tiba di server yang tidak lagi menjawab.
• Menyimpulkan propagasi selesai hanya dari komputer sendiri. Cache lokal Anda tidak mewakili resolver lain.
• Membiarkan TTL yang sangat rendah secara permanen. Ini melipatgandakan kueri ke name server Anda. Naikkan kembali setelah migrasi selesai.

Pertanyaan yang sering diajukan

Berapa lama propagasi DNS berlangsung?

Untuk record yang diubah, paling lama sepanjang TTL lama: satu jam dengan TTL 3.600 detik, 24 jam dengan 86.400 detik. Untuk pergantian name server, beberapa jam hingga 48 jam. Sebagian besar resolver memperbarui diri jauh sebelum batas maksimum. Yang tersisa hanyalah beberapa cache yang terlambat.

Bisakah propagasi DNS dipercepat?

Tidak di seluruh internet: cache milik orang lain tidak dapat dipaksa. Anda dapat menurunkan TTL sebelum perubahan, membersihkan resolver publik Google dan Cloudflare, dan mengosongkan cache Anda sendiri. Resolver milik penyedia internet tidak dapat dibersihkan.

TTL apa yang sebaiknya dipilih sebelum migrasi?

Nilai singkat seperti 300 detik (5 menit), diterapkan setidaknya selama durasi TTL lama sebelum pengalihan. Setelah migrasi stabil, naikkan kembali ke 3.600 detik atau lebih: TTL yang sangat rendah secara permanen melipatgandakan kueri. Periksa batas minimum yang diterima penyedia DNS Anda.

Mengapa rekan saya melihat situs baru sedangkan saya tidak?

Anda berdua melewati resolver yang berbeda, yang menyimpan jawaban pada waktu yang berbeda. Tanyai resolver publik yang sama dari kedua komputer untuk membandingkan, lalu kosongkan cache lokal di komputer yang masih melihat versi lama.

Apa yang terjadi pada surel saya selama propagasi?

Perubahan record MX mengikuti aturan yang sama: selama jeda, sebagian pengirim masih menulis ke server surel lama. Biarkan server itu tetap aktif sampai transisi selesai. Jika sebuah server tidak tersedia, server pengirim umumnya menyimpan pesan dan mencoba lagi selama beberapa hari.

Apakah saya perlu mengosongkan cache komputer?

Ya, untuk memeriksa apa yang Anda lihat, tetapi itu tidak mengubah apa pun bagi pengunjung lain. Gunakan perintah untuk sistem Anda, lalu tutup browser sepenuhnya. Jika nilainya masih lama, salinannya ada di resolver penyedia internet Anda.

Mengapa alat pemeriksa propagasi online menunjukkan hasil yang berbeda?

Masing-masing menanyai resolver di negara yang berbeda, yang menyimpan jawaban pada waktu yang berbeda. Hasil campuran itu normal selama TTL belum kedaluwarsa di mana-mana. Jika name server otoritatif sendiri menjawab berbeda, bandingkan nomor seri SOA mereka: masalahnya kemudian ada pada zona, bukan pada propagasi.