Kenapa Hasil dig Berubah-ubah Setelah Ganti Nameserver Domain

Kamu baru saja mengganti nameserver domain di panel registrar, lalu menjalankan dig beberapa kali untuk memastikan. Hasil pertama menunjuk ke IP server baru, beberapa menit kemudian kembali ke IP lama, lalu berubah lagi. Ini biasanya bukan tanda perubahannya gagal. Ada beberapa lapis otoritas dan cache yang bekerja bersamaan, dan dig tanpa opsi tambahan hanya menampilkan jawaban akhirnya, bukan dari mana jawaban itu berasal. Di meja support, keluhan seperti ini hampir selalu datang dengan kalimat DNS-nya belum propagasi. Kata propagasi sebenarnya kurang tepat, karena DNS tidak mendorong perubahan ke seluruh dunia. Yang terjadi adalah resolver di berbagai tempat menyimpan jawaban lama sampai masa berlakunya habis, lalu bertanya ulang. Kalau kita paham urutan pertanyaannya, kita bisa menunjuk dengan tepat lapis mana yang masih memberi jawaban lama.

Apa yang sebenarnya berubah saat nameserver diganti

Saat sebuah resolver rekursif (server DNS yang mencarikan jawaban untuk klien, misalnya resolver ISP atau resolver publik) belum punya data apa pun soal example.com, ia berjalan bertahap. Pertama ia bertanya ke root server, yang menjawab dengan referral (rujukan) ke server TLD .com. Server TLD tidak tahu IP website kamu. Ia hanya tahu nameserver mana yang bertanggung jawab atas example.com, lalu menjawab dengan referral berisi record NS tersebut. Baru setelah itu resolver bertanya ke nameserver otoritatif domain kamu dan mendapat record A yang sebenarnya. Ganti nameserver di registrar hanya mengubah satu titik di rantai itu, yaitu record NS untuk domain kamu di zona TLD. Registrar meneruskan perubahan ke registry (pengelola TLD), lalu server TLD mulai memberikan referral ke nameserver baru. Berapa lama proses ini tergantung registrar dan TLD-nya. Yang sering terlupa, nameserver lama tidak diberi tahu apa-apa. Zona domain kamu masih tersimpan di sana, lengkap dengan record A yang mengarah ke server lama, dan server itu tetap menjawab secara otoritatif kalau ada yang bertanya. Jadi selama masa transisi ada dua sumber yang sama-sama sah menurut protokol DNS. Resolver mana yang bertanya ke sumber mana tergantung isi cache-nya masing-masing.

TTL record NS di TLD dan NS yang masih tersimpan di cache

Setiap record DNS punya TTL (time to live), yaitu berapa detik sebuah jawaban boleh disimpan di cache. Referral dari server TLD juga punya TTL. Untuk .com dan .net, record NS di zona TLD umumnya memakai TTL 172800 detik atau sekitar dua hari. TLD lain bisa berbeda, jadi sebaiknya kamu cek langsung ke server TLD-nya. Selama record NS lama masih ada di cache, resolver tidak perlu bertanya lagi ke server TLD. Ia langsung mengirim query ke nameserver lama, dan nameserver lama dengan senang hati menjawab IP lama. Dari sisi resolver tidak ada yang salah, karena ia sedang memakai data yang masih berlaku. Ada satu mekanisme lagi yang bisa memperpanjang masalah. Zona di server lama biasanya masih berisi record NS yang menunjuk ke nameserver lama itu sendiri. Saat resolver menerima jawaban dari server lama, jawaban otoritatif itu bisa ikut membawa record NS di bagian authority. Banyak resolver menilai data NS dari jawaban otoritatif zona anak lebih tinggi kredibilitasnya dibanding data referral dari parent. Akibatnya, ada resolver yang terus memperbarui cache NS-nya dari server lama dan baru kembali bertanya ke TLD jauh lebih lambat dari perkiraan. Perilaku persisnya berbeda antar software resolver dan konfigurasinya, tapi efeknya cukup sering terlihat kalau zona lama dibiarkan apa adanya. Di atas itu masih ada TTL record A. Resolver yang sudah pindah ke nameserver baru pun bisa masih menyimpan record A lama sampai TTL-nya habis.

Kenapa jawabannya bisa bolak-balik dalam hitungan menit

Kalau hanya ada satu resolver, kamu akan melihat jawaban lama sampai cache-nya habis, lalu jawaban baru seterusnya. Kenyataannya, dari satu laptop pun kamu bisa sedang berbicara dengan beberapa cache sekaligus. Resolver publik besar biasanya berjalan di banyak node di belakang satu alamat anycast, dan tiap node atau instance bisa punya cache sendiri. Query pertama bisa mendarat di instance yang cache-nya sudah kosong dan bertanya ulang ke TLD, query berikutnya mendarat di instance lain yang masih menyimpan NS lama. Di sisi klien, /etc/resolv.conf sering berisi lebih dari satu baris nameserver, router rumah atau kantor punya cache sendiri, dan di banyak distro modern ada systemd-resolved yang juga menyimpan cache. Setiap lapis berada di tahap yang berbeda. Penyebab lain yang sering terlewat adalah daftar nameserver campuran di registrar, misalnya ns1 sudah diganti ke penyedia baru tapi ns2 masih menunjuk ke penyedia lama. Resolver memilih nameserver dari daftar itu secara bergantian atau berdasarkan waktu respons, sehingga jawaban akan terus bolak-balik bahkan setelah semua cache kedaluwarsa. Kasus ini tidak akan selesai dengan menunggu.

Membaca dig +trace untuk menemukan sumber jawaban lama

dig biasa mengirim query ke resolver yang tercantum di sistem kamu, jadi hasilnya sudah melewati cache. Opsi +trace membuat dig berjalan sendiri dari root, persis seperti resolver yang cache-nya kosong, dan mencetak setiap referral beserta server yang memberikannya. Hanya langkah awal untuk mendapatkan daftar root server yang memakai resolver lokal.

TEXT

# contoh format output, bukan hasil nyata
$ dig +trace example.com A

.                       518400  IN  NS  a.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

com.                    172800  IN  NS  a.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 20 ms

example.com.            172800  IN  NS  ns1.example.net.
example.com.            172800  IN  NS  ns2.example.net.
;; Received 300 bytes from 192.5.6.30#53(a.gtld-servers.net) in 30 ms

example.com.            300     IN  A   203.0.113.20
;; Received 56 bytes from 198.51.100.10#53(ns1.example.net) in 15 ms

Baca dari atas ke bawah. Blok ketiga adalah delegasi yang sekarang dipublikasikan server TLD, dan baris Received ... from menunjukkan server mana yang mengirimkannya. Kalau di blok ini masih muncul nameserver lama, perubahan di registrar belum sampai ke registry, atau daftar NS-nya campuran. Blok terakhir menunjukkan nameserver mana yang akhirnya memberi record A dan IP berapa yang dijawabnya. Aturan praktisnya begini. Kalau +trace sudah konsisten menunjuk nameserver baru dan IP baru, tapi dig biasa masih memberi IP lama, sumbernya cache resolver dan solusinya menunggu TTL habis. Kalau +trace sendiri sesekali berakhir di nameserver lama, masalahnya ada di delegasi. Perlu diingat juga, +trace memilih satu server di setiap tahap, jadi jalankan beberapa kali kalau curiga daftarnya campuran. Untuk memastikan, tanya setiap sumber secara langsung dengan +norecurse supaya server tidak mencarikan jawaban ke tempat lain:

BASH

# Delegasi di server TLD .com; NS muncul di AUTHORITY SECTION, perhatikan TTL-nya
dig @a.gtld-servers.net example.com NS +norecurse

# Untuk TLD lain, cari dulu server TLD-nya
dig id. NS +short

# Jawaban langsung dari nameserver baru dan lama
dig @ns1.example.net example.com A +norecurse
dig @ns1.example.org example.com A +norecurse

# Record NS apa yang masih diumumkan zona di server lama
dig @ns1.example.org example.com NS +norecurse

Pada jawaban dari nameserver otoritatif, flag aa (authoritative answer) akan muncul di header. Pada jawaban dari server TLD, flag itu tidak ada karena TLD hanya memberi referral. Kalau server lama masih menjawab dengan flag aa dan IP lama, berarti setiap resolver yang masih menyimpan NS lama akan terus mendapat jawaban lama dari sana. Terakhir, bandingkan beberapa resolver dan perhatikan angka TTL di kolom kedua:

BASH

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
dig example.com A +noall +answer

Jawaban dari cache menampilkan TTL yang terus berkurang setiap kali kamu ulangi. Kalau TTL-nya sama dengan nilai penuh yang tertulis di zona, resolver itu kemungkinan baru saja mengambil jawaban segar. Angka sisa TTL ini memberi gambaran kasar kapan resolver tersebut akan bertanya ulang.

Yang bisa dilakukan selama masa transisi

Kita tidak bisa menghapus cache resolver milik orang lain, jadi strateginya adalah membuat kedua sumber memberi jawaban yang benar. Jangan langsung menghapus zona di nameserver lama begitu NS diganti. Kalau masih punya akses, samakan record di zona lama dengan zona baru, atau minimal arahkan record A dan MX-nya ke server baru. Dengan begitu resolver yang masih bertanya ke server lama tetap mendapat IP yang benar. Kalau memungkinkan, ubah juga record NS di zona lama agar menunjuk ke nameserver baru. Resolver yang membaca NS dari jawaban zona anak akan ikut berpindah, dan efek NS lengket tadi berkurang. Pastikan juga daftar nameserver di registrar tidak campuran. Setelah itu, perkiraan waktu tunggu yang wajar adalah TTL NS di TLD ditambah TTL record terbesar di zona, dan zona lama baru aman dihapus setelah periode itu lewat. Beberapa resolver publik menyediakan halaman untuk meminta cache sebuah domain dihapus; cek dokumentasi resolver tersebut kalau ingin mempercepat pengujian. Kalau domain memakai DNSSEC, perpindahan nameserver juga menyangkut record DS di registry. DS yang tidak cocok dengan kunci di penyedia baru menghasilkan SERVFAIL, bukan jawaban lama, dan cara memeriksanya dibahas di Using dig to Confirm If DNSSEC Validation Failures Cause SERVFAIL. Jadi saat hasil dig berubah-ubah, jangan langsung menyimpulkan perubahan gagal atau sekadar menyuruh menunggu. Jalankan dig +trace untuk melihat delegasi yang dipublikasikan TLD, tanya nameserver lama dan baru secara langsung, lalu bandingkan TTL di beberapa resolver. Tiga langkah itu biasanya cukup untuk mengetahui apakah yang tersisa hanya cache yang akan habis sendiri, atau ada delegasi dan zona lama yang memang perlu diperbaiki.