Nameserver ns1 Milik Sendiri Tidak Bisa Di-resolve? Cek Glue Record Pakai dig

Domain yang memakai nameserver sendiri, misalnya ns1.domainanda.com dan ns2.domainanda.com, tiba-tiba tidak bisa di-resolve setelah pindah VPS atau ganti IP. Record A untuk ns1 di zona sudah diubah ke IP baru dan service DNS di server baru sudah jalan, tapi browser tetap bilang domain tidak ditemukan. Penyebabnya sering tidak ada di server kamu. Masalahnya ada di glue record yang masih tersimpan di server registry dengan IP lama. Di meja support, kalimat yang sering muncul adalah 'record A ns1 sudah saya ganti, tinggal tunggu propagasi'. Kadang menunggu memang membantu. Tapi kalau yang salah adalah data di level TLD, menunggu berapa lama pun hasilnya tetap sama. Artikel ini menelusuri gejalanya dari atas ke bawah pakai dig sampai ketemu titik yang perlu diperbaiki.

Gejala yang biasanya muncul

Pola yang paling umum: dig domainanda.com lewat resolver publik memberi status SERVFAIL atau berakhir dengan timeout. Situs tidak terbuka, dan email ikut terganggu karena MX domain juga tidak bisa di-resolve. Domain lain di server yang sama tetap normal kalau domain itu memakai nameserver pihak ketiga. Gejalanya sering campuran. Dari satu jaringan domain masih terbuka, dari jaringan lain tidak. Ini mudah dikira propagasi, padahal biasanya itu cache resolver yang pelan-pelan kedaluwarsa. Resolver yang masih menyimpan jawaban lama masih bisa melayani. Resolver yang harus bertanya ulang dari awal yang gagal. Ada variasi lain kalau server lama masih menyala dan masih menjawab DNS. Domain tidak gagal total, tapi mengarah ke data lama, misalnya IP website lama. Ini membingungkan karena tampak berhasil. Padahal akar masalahnya sama: resolver masih diarahkan ke server DNS lama.

Pastikan dulu server DNS baru memang menjawab

Sebelum menyalahkan glue, singkirkan dulu tersangka yang lebih dekat. Mungkin service DNS di VPS baru (BIND, PowerDNS, atau yang dipakai panel) belum jalan. Mungkin port 53 UDP dan TCP terblokir firewall. Mungkin juga zona domainnya belum termuat. Cara paling jujur untuk mengeceknya adalah bertanya langsung ke IP server baru tanpa rekursi.

BASH

# Ganti 203.0.113.10 dengan IP server DNS baru
dig @203.0.113.10 domainanda.com A +norec
dig @203.0.113.10 ns1.domainanda.com A +norec

Jawaban yang sehat berstatus NOERROR, punya flag aa (authoritative answer, artinya server ini mengaku pemilik zona), dan berisi IP yang benar. Kalau perintah timeout, cek service dan firewall. Kalau hasilnya REFUSED atau SERVFAIL, biasanya zona belum termuat atau server belum dikonfigurasi sebagai authoritative untuk domain itu. Jalankan perintah ini dari jaringan lain juga, jangan cuma dari VPS itu sendiri. Query dari dalam server bisa lolos walaupun firewall di depan server memblokir akses dari luar. Kalau dari luar pun jawabannya benar, server baru sudah beres, dan masalahnya ada di cara resolver menemukan server ini.

Kenapa ganti record A ns1 di zona sendiri tidak cukup

Resolver yang ingin tahu IP domainanda.com harus bertanya ke nameserver domain itu, yaitu ns1.domainanda.com. Masalahnya, untuk tahu IP ns1.domainanda.com, resolver harus bertanya ke nameserver domainanda.com juga. Lingkarannya tidak putus. Glue record memutus lingkaran itu. Glue adalah record A (dan AAAA kalau ada IPv6) untuk hostname nameserver, tapi tidak disimpan di zona kamu. Glue disimpan di zona induk milik registry TLD. Saat resolver bertanya ke server TLD tentang domainanda.com, TLD tidak memberi jawaban akhir. TLD memberi referral, yaitu daftar NS beserta IP glue di bagian ADDITIONAL. Resolver lalu langsung menghubungi IP glue tersebut. Artinya, record A ns1 di zona kamu tidak dipakai untuk menemukan nameserver pertama kali. Glue didaftarkan lewat registrar dan disimpan di registry. Ganti IP VPS, edit zona, atau ubah IP server di WHM tidak menyentuh glue sama sekali. Kalau butuh latar belakang soal kenapa nameserver sendiri wajib punya glue, pembahasannya ada di artikel tentang custom nameserver dan glue record. Glue hanya relevan kalau hostname nameserver berada di bawah domain yang dilayaninya, seperti ns1.domainanda.com untuk domainanda.com. Kalau domain kamu memakai ns1.hostinglain.net, yang perlu dicek adalah glue milik hostinglain.net, bukan domain kamu.

Membaca jalur resolusi dengan dig +trace

dig +trace meniru kerja resolver dari nol. Dig bertanya ke root, lalu ke server TLD, lalu ke nameserver domain, tanpa memakai cache resolver lokal. Setiap blok output diakhiri baris Received ... from yang menyebut server mana yang menjawab tahap itu. Perhatikan tahap terakhir. Kalau dig gagal menghubungi nameserver domain, biasanya muncul pesan timeout atau error yang menyebut IP tujuan. Kalau IP itu adalah IP server lama, kamu sudah punya petunjuk kuat bahwa referral dari TLD masih membawa glue lama. Tampilan output berbeda antar versi dig. Ada versi yang menampilkan NS di tiap tahap tapi tidak menampilkan glue-nya, jadi jangan berhenti di sini. +trace juga berguna untuk tahu server mana yang memberi referral, yaitu blok tepat sebelum nameserver kamu muncul. Ini membantu untuk domain second-level seperti .co.id, karena kamu tidak perlu menebak zona induknya.

Bertanya langsung ke server TLD

Cara paling pasti untuk melihat glue adalah meminta referral langsung dari server TLD dengan +norec. Contoh di bawah memakai .com. Untuk TLD lain, ganti nama TLD dan servernya sesuai hasil perintah pertama atau hasil +trace.

BASH

# Daftar nameserver TLD (ganti 'com' sesuai TLD domain)
dig NS com +short

# Minta referral untuk domain, tanpa rekursi
dig @a.gtld-servers.net domainanda.com NS +norec

# Cek glue IPv4 dan IPv6 untuk host nameserver
dig @a.gtld-servers.net ns1.domainanda.com A +norec
dig @a.gtld-servers.net ns1.domainanda.com AAAA +norec

Jawaban dari server TLD tidak punya flag aa dan bagian ANSWER-nya kosong. Itu normal karena ini referral. Yang dibaca adalah AUTHORITY SECTION (daftar NS) dan ADDITIONAL SECTION (glue). Berikut contoh format output. IP dan TTL di sini hanya ilustrasi:

TEXT

;; AUTHORITY SECTION:
domainanda.com.      172800  IN  NS  ns1.domainanda.com.
domainanda.com.      172800  IN  NS  ns2.domainanda.com.

;; ADDITIONAL SECTION:
ns1.domainanda.com.  172800  IN  A   192.0.2.10
ns2.domainanda.com.  172800  IN  A   192.0.2.11

Bandingkan IP di ADDITIONAL dengan IP server baru yang tadi dicek langsung. Kalau ADDITIONAL masih menunjukkan 192.0.2.10 padahal server baru ada di 203.0.113.10, akar masalahnya sudah ketemu. Kalau ADDITIONAL kosong padahal nameserver berada di bawah domain itu sendiri, glue belum pernah didaftarkan atau sudah terhapus. Akibatnya sama, resolver tidak bisa menemukan nameserver kamu. Jangan lewatkan cek AAAA. Kalau glue IPv4 sudah benar tapi glue IPv6 masih mengarah ke server lama, gejalanya jadi kadang-kadang gagal. Resolver yang memilih jalur IPv6 menabrak alamat mati, sedangkan yang memakai IPv4 lancar. Pola ini paling sering bikin orang yakin masalahnya cuma propagasi.

Memperbarui glue dan memastikan hasilnya

Glue diperbarui lewat panel registrar, bukan lewat server kamu. Nama menunya berbeda-beda, misalnya child nameserver, host record, register nameserver, atau kelola glue. Ubah IP pada host yang sudah ada untuk ns1 dan ns2, termasuk IPv6 kalau dipakai. Hindari menghapus lalu membuat ulang host. Banyak registry menolak penghapusan host yang masih dipakai domain, dan proses hapus-buat ulang membuka jeda tanpa glue. Setelah disimpan, verifikasi dengan mengulang query +norec ke server TLD, bukan lewat resolver publik. Resolver publik bisa masih menyimpan cache lama dan memberi kesan perubahan belum masuk. Lama perubahan sampai di server TLD tergantung registry dan registrar. Kalau server TLD sudah menunjukkan IP baru, sisanya adalah cache. Resolver yang sempat menyimpan referral lama memegangnya sampai TTL habis. Nilai TTL bisa kamu baca di kolom kedua output tadi, dan di beberapa TLD nilainya cukup panjang. Selama masa ini, akan sangat membantu kalau server lama masih menyala dan menjawab dengan data yang benar, atau setidaknya tidak dimatikan dulu. Kalau pindah server sekaligus pindah penyedia DNS dan domainnya memakai DNSSEC, ada lapisan lain yang perlu dicek, yaitu DS record di registrar. Pembahasannya ada di artikel tentang SERVFAIL setelah pindah DNS provider dengan DNSSEC. Untuk migrasi berikutnya, urutannya bisa dibalik supaya masalah ini tidak muncul. Siapkan DNS di server baru, pastikan server itu menjawab dengan benar dari luar, perbarui glue di registrar, konfirmasi lewat server TLD, tunggu TTL delegasi lewat, baru matikan server lama. Kalau keluhan seperti ini datang ke support, urutan cek yang paling cepat adalah query langsung ke IP server baru, lalu dig +trace, lalu query +norec ke server TLD. Biasanya tiga langkah itu sudah cukup untuk membedakan masalah di server, masalah cache, atau glue yang masih tertinggal.