Cara Cek Record yang Hilang Saat Impor Zona DNS ke Provider Baru Lewat dig

Pindah ke provider DNS baru sering terasa cepat. Kamu klik impor atau scan otomatis, daftar record muncul, lalu nameserver di registrar diganti. Website utama tetap jalan, jadi semuanya terlihat aman. Masalahnya baru ketahuan belakangan: ada subdomain yang tidak resolve, verifikasi domain di layanan pihak ketiga gagal, atau klien email tidak bisa konfigurasi otomatis. Artikel ini membedah pola insiden itu dengan format post-mortem. Di bagian akhir ada cara membandingkan jawaban nameserver lama dan baru dengan dig sebelum kamu menekan tombol ganti nameserver.

Dampak awal: yang rusak justru bukan website utama

Record A di root domain dan www hampir selalu ikut terimpor, karena itu nama yang paling mudah ditebak. Record yang tertinggal biasanya bernama tidak umum. Contohnya subdomain internal seperti staging atau nama host server lama, TXT di bawah subdomain seperti selector DKIM namaselector._domainkey, TXT verifikasi yang diletakkan di nama khusus, dan record SRV (record yang memberi tahu klien host dan port sebuah layanan) seperti _autodiscover._tcp atau _sip._tls. Gejalanya tersebar dan jarang terlihat seperti masalah DNS. Email mulai gagal DKIM dan masuk spam. Dashboard layanan pihak ketiga menandai domain sebagai belum terverifikasi. Aplikasi internal tidak bisa konek ke API. Di meja support, keluhan seperti ini biasanya masuk sebagai tiket terpisah, sering dari orang yang berbeda, dan hampir tidak ada yang menyebut DNS. Karena website utama normal, dugaan pertama biasanya mengarah ke tempat lain.

Jejak investigasi: dari menunggu propagasi sampai bertanya langsung ke nameserver

Langkah pertama yang paling umum adalah menunggu propagasi. Masalahnya, propagasi bukan proses menyebarnya data ke seluruh internet. Yang terjadi adalah cache di resolver kedaluwarsa sesuai TTL, lalu resolver bertanya ulang ke nameserver yang sekarang didelegasikan. Kalau nameserver baru memang tidak punya record itu, menunggu tidak akan membantu. Setelah semua cache kedaluwarsa, hasilnya justru makin konsisten salah. Langkah kedua biasanya cek lewat resolver publik atau situs pengecek DNS. Hasilnya sering campur aduk. Sebagian lokasi masih menjawab dari cache lama, sebagian sudah bertanya ke nameserver baru. Situasi ini mudah disalahartikan sebagai propagasi yang belum selesai. Arah investigasi baru jelas ketika resolver dilewati dan pertanyaan dikirim langsung ke authoritative nameserver, yaitu server yang memang memegang zona. Di dig, caranya dengan menambahkan @ diikuti nama nameserver:

BASH

# Lihat delegasi yang berlaku dari root sampai TLD (tidak bergantung cache resolver)
dig +trace example.com NS

# Tanya langsung ke nameserver lama dan baru (ganti dengan nama NS milikmu)
dig @ns1.provider-lama.example selector1._domainkey.example.com TXT
dig @ns1.provider-baru.example selector1._domainkey.example.com TXT

Perhatikan baris header di setiap jawaban. Contoh format output dari nameserver baru untuk record yang tidak ikut terimpor:

TEXT

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Flag aa (authoritative answer) berarti kamu memang sedang bicara dengan pemegang zona, bukan dengan cache. Status NXDOMAIN berarti nama tersebut sama sekali tidak ada di zona. Status NOERROR dengan ANSWER: 0 berarti namanya ada, tetapi tidak punya record dengan tipe yang kamu tanyakan. Kalau statusnya REFUSED, nameserver itu tidak melayani zonamu. Ini bisa terjadi karena salah nama NS atau karena zona belum aktif di provider baru. Saat nameserver lama menjawab dengan nilai dan nameserver baru menjawab NXDOMAIN, penyebabnya sudah jelas. Record itu tidak pernah sampai ke zona baru.

Titik terang: fitur impor menebak, bukan menyalin

Akar masalahnya ada di cara kerja DNS itu sendiri. Tidak ada query publik untuk meminta daftar semua nama di sebuah zona. Mekanisme zone transfer (AXFR) memang ada, tetapi biasanya hanya diizinkan untuk secondary nameserver yang sudah diotorisasi. Pembatasan ini memang sengaja, supaya isi zona tidak bisa disedot siapa saja. Query ANY juga tidak bisa diandalkan, karena banyak authoritative server sekarang hanya memberi jawaban minimal untuk query jenis itu. Akibatnya, fitur impor di provider baru biasanya bekerja dengan salah satu dari dua cara. Cara pertama, ia mem-parse zone file yang kamu upload. Ini akurat, karena isinya memang salinan zona. Cara kedua, ia melakukan scan: bertanya ke DNS untuk daftar nama umum seperti www, mail, ftp, atau _dmarc dengan tipe-tipe umum, lalu menyimpan apa pun yang terjawab. Nama yang tidak ada di daftar tebakan itu tidak akan pernah ditemukan. Ada beberapa efek samping lain yang perlu diwaspadai. Kalau zona lama punya wildcard *.example.com, scanner bisa menganggap setiap nama tebakan itu ada dan menyalinnya sebagai record terpisah, atau malah melewatkan wildcard-nya sendiri. Perilaku ini tergantung tool-nya. Kalau provider lama memakai record khusus seperti ALIAS atau CNAME flattening di root domain, scanner hanya melihat hasil akhirnya berupa IP. Record itu lalu tersimpan sebagai A biasa, dan akan basi begitu IP tujuannya berubah. TTL juga sering di-reset ke nilai default provider baru.

Mitigasi sementara saat nameserver sudah terlanjur pindah

Kalau delegasi sudah pindah dan ada record yang hilang, jalan tercepat biasanya adalah menambahkan record yang kurang di provider baru, bukan mengembalikan nameserver. Perubahan nameserver di registrar punya TTL sendiri di zona parent (TLD), dan resolver menyimpan delegasi itu di cache. Revert sama lambatnya dengan cutover, dan selama masa transisi hasilnya akan campur lagi. Ada satu hal yang sering membuat orang bingung setelah record ditambahkan: sebagian pengguna masih gagal. Penyebabnya negative caching. Resolver yang sudah menerima NXDOMAIN akan menyimpan jawaban negatif itu selama durasi yang diambil dari record SOA zona, yaitu nilai terkecil antara TTL record SOA dan field terakhir di SOA. Kamu bisa melihat nilainya dengan dig @ns1.provider-baru.example example.com SOA. Selama durasi itu belum habis, resolver tersebut tetap menjawab bahwa nama itu tidak ada. Selama mitigasi, jangan sentuh zona di provider lama. Zona lama adalah satu-satunya referensi lengkap yang kamu punya. Kalau akun hosting atau DNS lama dibatalkan terlalu cepat, sumber kebenaran ikut hilang dan kamu terpaksa menyusun ulang record dari ingatan dan email konfirmasi layanan.

Perbaikan yang permanen: bandingkan sebelum cutover

Perbaikan permanennya adalah mengubah urutan kerja. Impor bukan langkah terakhir. Impor adalah langkah yang hasilnya harus diverifikasi. Urutan yang aman:

Ambil sumber kebenaran dari provider lama. Idealnya berupa export zone file. Di server cPanel, zona biasanya bisa diambil lewat WHM atau dari file zona di server. Kalau tidak ada fitur export, salin isi dashboard DNS lama secara manual ke sebuah daftar.
Turunkan TTL record penting di zona lama, lalu tunggu sampai TTL lama habis, supaya koreksi setelah cutover cepat menyebar.
Impor ke provider baru. Upload zone file lebih aman daripada scan otomatis.
Bandingkan jawaban kedua nameserver untuk setiap record di daftar.
Setelah tidak ada perbedaan yang tidak disengaja, baru ganti nameserver di registrar dan cek delegasinya dengan dig +trace.

Untuk langkah keempat, buat file daftar-record.txt berisi satu record per baris dengan format nama lalu tipe, misalnya _dmarc.example.com TXT atau _autodiscover._tcp.example.com SRV. Lalu jalankan skrip berikut. Skrip ini hanya membaca dan tidak mengubah apa pun:

BASH

#!/usr/bin/env bash
# Bandingkan jawaban NS lama dan NS baru untuk tiap baris 'nama tipe'
OLD='ns1.provider-lama.example'
NEW='ns1.provider-baru.example'

while read -r name type; do
  [ -z "$name" ] && continue
  # sort karena urutan record dalam satu jawaban tidak dijamin sama
  lama=(dig @"OLD" "name" "type" +short | sort)
  baru=(dig @"NEW" "name" "type" +short | sort)
  if [ "lama" != "baru" ]; then
    printf 'BEDA: %s %s
  lama: %s
  baru: %s
' "name" "type" "lama" "baru"
  fi
done < daftar-record.txt

Baca hasilnya dengan konteks. Record NS dan SOA memang pasti berbeda, jadi jangan masukkan keduanya ke daftar. TXT panjang bisa dipecah menjadi beberapa string dengan cara berbeda antar provider, sehingga terlihat beda padahal nilainya sama. Opsi +short juga menyembunyikan TTL, jadi kalau TTL penting buatmu, cek manual record yang krusial tanpa +short. Yang perlu ditindaklanjuti adalah baris yang di nameserver lama berisi nilai, tetapi di nameserver baru kosong. Kalau kamu masih ragu apakah memang perlu memindahkan nameserver atau cukup mengubah A record di DNS lama, pertimbangannya dibahas di Ganti Nameserver atau Cukup Ubah A Record Saat Pindah Hosting?. Anggap hasil impor DNS sebagai draf, bukan salinan. Selama nameserver lama masih hidup, kamu bisa bertanya ke kedua sisi dengan dig dan melihat perbedaannya secara langsung. Lakukan perbandingan itu sebelum delegasi diganti, karena setelah resolver menyimpan NXDOMAIN di cache, memperbaiki record pun tidak langsung menyelesaikan masalah.