Ganti Nameserver atau Cukup Ubah A Record Saat Pindah Hosting?

Pindah ke hosting baru biasanya diikuti satu pertanyaan yang sama: perlukah nameserver domain diganti ke provider baru, atau cukup ubah A record di DNS yang sekarang? Dua-duanya bisa membuat situs tampil dari server baru. Bedanya ada di apa saja yang ikut berubah. Di situlah email atau subdomain sering ikut putus tanpa ada yang sadar, sampai pengguna mulai komplain. Agar lebih jelas, kita bedah masalah ini dengan format post-mortem: dampak awal, jalur investigasi, titik temu penyebab, mitigasi sementara, lalu perbaikan yang lebih permanen. Ini bukan cerita satu kasus tertentu. Isinya rangkuman pola yang sering muncul saat migrasi.

Dampak awal: situs normal, tapi email dan subdomain hilang

Pola umumnya begini. Pemilik situs memindahkan file dan database ke hosting baru, lalu mengganti nameserver di registrar ke nameserver provider baru. Beberapa jam kemudian, situs utama sudah terbuka normal dari server baru. Lalu muncul laporan lain: email masuk berhenti, pengirim menerima bounce, form kontak tidak sampai, atau subdomain seperti shop atau mail tidak bisa diakses. Yang membuat bingung, tidak ada yang menyentuh pengaturan email. Mailbox masih ada di layanan yang sama dan password tidak berubah. Dari sudut pandang pemilik situs, yang dipindah cuma website. Untuk memahami kenapa ini terjadi, dua istilah perlu jelas dulu. Nameserver adalah server DNS otoritatif, yaitu server yang memegang jawaban resmi untuk semua record di satu domain. Kumpulan record itu disebut zone. A record hanya salah satu isi zone, yaitu record yang memetakan nama seperti contoh.com ke alamat IPv4. Di zone yang sama juga ada MX (tujuan pengiriman email), TXT (SPF, DKIM, DMARC, token verifikasi), CNAME, dan record lain. Mengubah A record berarti mengganti satu baris di zone yang sama. Mengganti nameserver berarti memindahkan seluruh zone ke server lain. Record apa pun yang tidak ada di zone baru dianggap tidak pernah ada oleh dunia luar.

Jalur investigasi: memastikan siapa yang sedang menjawab

Langkah pertama adalah mengecek nameserver mana yang sekarang aktif untuk domain itu. Setelah itu, bandingkan jawaban dari nameserver lama dan baru secara langsung. Query ke nameserver tertentu dengan @ tidak melewati cache resolver, jadi hasilnya mencerminkan isi zone di server itu, bukan sisa cache.

BASH

# Nameserver yang saat ini didelegasikan untuk domain
dig NS contoh.com +short

# Bandingkan record MX di zone lama dan zone baru
dig MX contoh.com @ns1.dns-lama.example +short
dig MX contoh.com @ns1.dns-baru.example +short

# Cek TXT (SPF, verifikasi) dan subdomain di zone baru
dig TXT contoh.com @ns1.dns-baru.example +short
dig CNAME shop.contoh.com @ns1.dns-baru.example +short

Ganti contoh.com dan nama nameserver dengan milikmu. Query ke nameserver lama hanya berguna selama zone di sana belum dihapus, jadi lakukan pengecekan ini sebelum akun hosting lama ditutup. Kalau perintah pertama sudah menunjukkan nameserver baru tapi sebagian resolver masih menjawab dengan data lama, itu wajar di masa transisi. Delegasi nameserver juga di-cache. Perubahan di registrar perlu waktu untuk diteruskan ke zone induk, misalnya zone .com atau .id, lalu ke cache resolver di berbagai ISP.

Titik temu: zone baru bukan salinan zone lama

Penyebabnya hampir selalu sama: zone di provider baru tidak berisi record yang sama dengan zone lama. Banyak control panel otomatis membuat zone default saat domain ditambahkan ke akun hosting. Isinya biasanya A record ke server baru dan www. Sering juga ada MX yang menunjuk ke mail server di hosting itu sendiri, ditambah SPF bawaan. Detailnya tergantung panel dan konfigurasi provider. Akibatnya bisa beberapa hal sekaligus:

MX sekarang mengarah ke server hosting baru, padahal mailbox sebenarnya ada di layanan email eksternal atau di server lama. Email masuk ke tempat yang salah atau ditolak karena mailbox tidak ditemukan.
TXT untuk SPF, DKIM, dan verifikasi layanan pihak ketiga hilang, sehingga email keluar mulai gagal autentikasi.
Subdomain yang dulu dibuat manual, misalnya CNAME ke layanan toko online atau landing page, tidak ikut dibuat.

Faktor kedua yang membuat masalah terasa lebih lama adalah TTL. TTL (time to live) menentukan berapa lama resolver boleh menyimpan jawaban di cache sebelum bertanya lagi. TTL untuk record di dalam zone bisa kamu atur sendiri. TTL untuk delegasi nameserver ditentukan oleh zone induk, dan biasanya jauh lebih panjang. Nilainya sering dalam hitungan jam sampai sekitar dua hari, tergantung TLD. Jadi kalau penggantian nameserver ternyata keliru, mengembalikannya juga tidak instan. Selama masa itu, sebagian pengguna dijawab oleh zone lama dan sebagian lagi oleh zone baru. Bandingkan dengan perubahan A record. Kalau TTL record itu sudah diturunkan sehari sebelumnya, misalnya ke 300 detik (contoh), rollback cukup dengan mengembalikan IP lama. Dalam hitungan menit, sebagian besar resolver sudah mengikuti. Beberapa resolver memang punya batas minimum cache sendiri, tapi rentang waktunya tetap jauh lebih pendek dibanding delegasi nameserver.

Mitigasi sementara: lengkapi zone, jangan bolak-balik nameserver

Kalau nameserver sudah terlanjur diganti, refleks pertama biasanya mengembalikannya ke nameserver lama. Langkah ini sering memperpanjang masalah, karena resolver jadi menyimpan dua versi delegasi di waktu yang berbeda. Biasanya lebih cepat kalau zone baru dilengkapi supaya isinya sama dengan zone lama. Urutannya:

Ambil daftar record lengkap dari zone lama. Bisa lewat fitur export atau zone editor di panel lama, atau dengan query dig langsung ke nameserver lama untuk setiap nama yang kamu tahu.
Buat ulang MX, TXT, CNAME, SRV, dan subdomain yang hilang di zone baru. Hapus MX default yang tidak dipakai.
Kalau email dikelola di luar hosting baru, pastikan server hosting baru tidak menganggap dirinya sebagai tujuan email untuk domain itu. Di cPanel, ini biasanya diatur lewat menu Email Routing dengan memilih opsi remote mail exchanger. Di panel lain, nama menunya berbeda.
Verifikasi dengan query langsung ke nameserver baru sebelum menganggap masalah selesai.

Email yang sempat ditolak dengan bounce permanen tidak akan dikirim ulang otomatis, jadi kabari pengirim penting agar mengirim ulang. Email yang hanya tertunda biasanya dicoba ulang oleh server pengirim selama beberapa waktu, tergantung konfigurasi mereka. Kalau yang kamu ubah hanya A record, mitigasinya lebih sederhana: kembalikan IP lama, lalu tunggu TTL habis.

Perbaikan arsitektural: putuskan dari siapa yang memegang zone

Pertanyaan ganti nameserver atau ubah A record sebenarnya adalah pertanyaan di mana sebaiknya zone DNS domain ini disimpan. Beberapa aturan praktis berikut bisa membantu. Pilih ubah A record kalau DNS saat ini dikelola di tempat netral, seperti DNS registrar atau layanan DNS terpisah, dan email atau layanan lain tetap memakai record di sana. Kamu cukup mengubah A untuk domain utama, www kalau berupa A record, dan subdomain lain yang memang ikut pindah. Jangan lupa cek AAAA. Kalau zone lama punya AAAA yang mengarah ke server lama, pengunjung IPv6 tetap diarahkan ke sana walaupun A record sudah benar. Pilih ganti nameserver kalau semua layanan, termasuk email, memang ikut pindah ke provider baru. Opsi ini juga perlu dipilih kalau DNS lama melekat pada akun hosting lama yang akan ditutup. Kasus terakhir ini sering terlewat. Kalau zone ada di hosting lama dan kamu hanya mengubah A record di sana, semuanya tetap berjalan sampai akun lama dihentikan. Begitu akun dihentikan, zone ikut hilang dan seluruh domain berhenti resolve. Apa pun pilihannya, persiapan sebelum migrasi kurang lebih sama:

Inventaris semua record di zone saat ini dan catat layanan apa yang memakai tiap record.
Turunkan TTL record yang akan diubah, satu sampai dua hari sebelumnya.
Kalau akan ganti nameserver, lengkapi zone di provider baru lebih dulu dan cek dengan query langsung ke nameserver baru. Setelah itu baru ubah delegasi di registrar.
Biarkan hosting lama tetap aktif sampai TTL terlama terlewati dan email sudah dipastikan normal.

Di chat support, pertanyaan yang sering muncul adalah kenapa provider menyarankan ganti nameserver kalau ubah A record terlihat lebih aman. Jawabannya bukan soal mana yang lebih benar. Ganti nameserver memudahkan provider mengatur semua record untukmu, tapi itu hanya aman kalau zone baru benar-benar mencakup semua layanan yang kamu pakai. Jadi sebelum memilih, buka zone DNS saat ini dan periksa MX serta TXT-nya. Kalau ada record yang mengarah ke layanan di luar hosting yang dipindah, cukup ubah A record, atau salin semua record itu ke zone baru sebelum ganti nameserver. Perubahan nameserver adalah langkah yang paling sulit dibatalkan, jadi jadikan itu langkah terakhir setelah zone baru terbukti lengkap.