DNS: Dasar yang Sering Disalahpahami

Setiap kali saya bantu tim ops atau developer junior yang baru pertama kali mengelola domain sendiri, ada satu kalimat yang hampir pasti muncul: "coba tunggu, mungkin masih propagasi DNS." Kalimat ini sudah jadi semacam mantra pamungkas untuk segala masalah yang berbau domain, padahal dalam banyak kasus, penyebab sebenarnya bukan propagasi sama sekali. Sebagai orang yang sehari-hari bergelut dengan infrastruktur untuk aplikasi seperti pujamalca.my.id dan medcoder.pujamalca.my.id, saya rasa penting untuk membedah ulang dasar-dasar DNS ini, karena kesalahpahaman di level fundamental sering bikin troubleshooting jadi jauh lebih lama dari seharusnya.

Jenis Record yang Wajib Dipahami

DNS pada dasarnya adalah sistem pemetaan nama ke informasi lain, dan setiap jenis record punya tugas spesifik.

A record memetakan nama domain ke alamat IPv4. Ini record paling dasar yang dipakai browser untuk tahu ke server mana harus konek.
AAAA record adalah versi IPv6 dari A record. Kalau infrastruktur sudah mendukung IPv6, biasanya kedua record ini berjalan berdampingan.
CNAME record tidak menunjuk ke IP, melainkan ke nama domain lain. Ini berguna misalnya untuk subdomain yang ikut mengarah ke domain utama layanan pihak ketiga, tanpa perlu tahu IP-nya berubah-ubah atau tidak.
TXT record menyimpan teks bebas, sering dipakai untuk verifikasi kepemilikan domain, konfigurasi email seperti SPF/DKIM, atau catatan lain yang dibaca sistem otomatis, bukan manusia.

Satu aturan yang sering dilupakan: sebuah nama tidak boleh punya CNAME sekaligus record lain (misalnya A) di level yang sama. Ini alasan kenapa CNAME biasanya dipasang di subdomain, bukan di root domain.

Kenapa "Propagasi" Sering Jadi Kambing Hitam

Istilah propagasi DNS sebenarnya menggambarkan waktu yang dibutuhkan perubahan record untuk tersebar ke seluruh resolver di dunia. Tapi dalam praktik, mekanisme sebenarnya bukan "menyebar" secara aktif — resolver di luar hanya akan mengambil data baru kalau cache lama mereka sudah kedaluwarsa, sesuai nilai TTL (Time To Live) yang kita set di record.

Kalau TTL sebuah record diset 86400 detik (satu hari), maka resolver yang sudah sempat menyimpan cache record lama itu memang wajar masih menampilkan nilai lama sampai TTL habis. Ini bukan "propagasi lambat", ini cache yang belum expired. Sebaliknya, kalau kita baru pertama kali membuat record atau resolver belum pernah query nama itu sebelumnya, perubahan biasanya sudah bisa terlihat dalam hitungan detik hingga menit.

Masalah yang sering saya temui justru bukan soal waktu tunggu, tapi soal kesalahan konfigurasi yang murni human error: salah target IP, lupa hapus record lama yang konflik, TTL yang terlalu tinggi diset sejak awal sehingga menyulitkan rollback cepat, atau nameserver domain yang ternyata masih menunjuk ke provider lama padahal DNS zone sudah dipindah ke provider baru. Semua ini terlihat seperti "propagasi lambat" dari luar, padahal akar masalahnya berbeda sama sekali.

Cara Diagnosis yang Lebih Tepat

Kalau ragu, jangan cuma menebak dan menunggu. Pakai tools seperti dig atau nslookup untuk cek record langsung ke authoritative nameserver domain, bukan ke resolver lokal yang mungkin masih cache. Misalnya, dig @ns1.provider.com domain.com A akan menunjukkan apa yang sebenarnya terdaftar di server otoritatif, terlepas dari cache di sisi kita. Kalau hasil dari authoritative server sudah benar tapi klien tertentu masih dapat hasil lama, barulah itu memang soal cache/TTL yang tinggal ditunggu atau di-flush di sisi client.

Sebagai ilustrasi praktik yang saya pegang: sebelum melakukan migrasi domain atau pindah server, saya biasa menurunkan TTL record terkait jauh-jauh hari — sehingga saat migrasi benar-benar terjadi, cache lama sudah expired lebih cepat dan proses cutover jadi jauh lebih mulus.

Takeaway

DNS itu sistem cache berjenjang dengan aturan TTL yang jelas, bukan proses "penyebaran" yang misterius. Sebelum menyalahkan propagasi, cek dulu apakah record di authoritative server sudah benar, lalu pahami TTL yang sedang berlaku. Kebiasaan kecil ini akan menghemat banyak waktu troubleshooting di masa depan.