Setiap kali membeli hosting, Anda diminta melakukan hal yang sama: membuka panel domain, lalu mengisi kolom nameserver dengan ns1.namapenyedia.com dan ns2.namapenyedia.com. Dua baris teks itu adalah pengumuman resmi ke seluruh internet. Isinya: siapa yang berhak menjawab pertanyaan DNS untuk domain Anda. Selama nama di kolom itu milik penyedia hosting, siapa pun yang memeriksanya tahu di mana situs Anda dititipkan.
Dari sinilah pertanyaan pokok artikel ini muncul: bagaimana kalau dua baris itu memakai nama domain Anda sendiri? Private nameserver adalah jawabannya. Sebelum masuk ke cara membuatnya, ada baiknya kita luruskan dulu apa itu private nameserver — karena ia mengubah lebih sedikit hal daripada yang biasanya dibayangkan.
Private Nameserver Adalah Lapisan Nama, Bukan Lapisan Mesin
Private nameserver adalah nameserver yang memakai nama domain Anda sendiri, misalnya ns1.domainanda.com dan ns2.domainanda.com, menggantikan nameserver bawaan penyedia hosting. Nameserver sendiri adalah server yang menyimpan dan menjawab data DNS sebuah domain. Dari sanalah pengunjung menemukan alamat IP tempat situs Anda berjalan.
Bagian yang paling sering disalahpahami ada pada kata "private". Istilah itu tidak menjanjikan server terpisah, isolasi, maupun performa. Yang berubah hanyalah nama yang tampil di hasil pemeriksaan. Mesin yang menjawab query di baliknya bisa saja tetap mesin yang melayani ratusan pelanggan lain.
Mengganti nameserver ke ns1.domainanda.com hanya mengubah namanya; server DNS di baliknya tetap mesin dan IP yang sama.
Ini bukan spekulasi, dan Anda dapat membuktikannya sendiri. Ambil nama domain penyedia hosting mana pun yang nameserver-nya bernama domain sendiri. Lalu tanyakan ke server top level domain (TLD, pengelola akhiran seperti .com atau .id) siapa pemilik alamat IP di baliknya:
dig +noall +authority +additional \
ns namapenyedia.com @a.gtld-servers.net
whois <alamat-ip> | grep -i orgnamePada sebagian penyedia, alamat IP yang muncul justru terdaftar atas nama perusahaan CDN atau penyedia DNS global, bukan atas nama penyedia hosting itu sendiri. Namanya milik mereka, mesinnya milik pihak lain. Itulah arti "lapisan penamaan" secara harfiah.
Membuat private nameserver dan menjalankan server DNS sendiri adalah dua pekerjaan berbeda. Yang pertama urusan pendaftaran nama, yang kedua urusan infrastruktur. Anda bisa melakukan yang pertama tanpa pernah menyentuh yang kedua.
Tiga Istilah Berbeda untuk Satu Hal yang Sama
Kebingungan berikutnya datang dari menu panel yang namanya berbeda-beda. Anda mungkin menemukan istilah child nameserver, vanity nameserver, atau white-label nameserver, lalu bertanya-tanya mana yang sebenarnya dibutuhkan. Jawabannya: ketiganya menunjuk hal yang sama, hanya dinamai berbeda oleh masing-masing registrar. Child nameserver adalah nama lain untuk private nameserver, begitu pula vanity nameserver.
- Private nameserver: istilah paling umum di kalangan penyedia hosting Indonesia, menekankan bahwa nameserver-nya "milik sendiri".
- Child nameserver: menekankan hubungan hierarkis. Secara teknis
ns1.domainanda.commemang sebuah subdomain daridomainanda.com, sekaligus sebuah FQDN yang utuh. - Vanity nameserver: istilah sebagian registrar besar, menekankan sisi tampilan dan merek.
Sebagian panel Indonesia menuliskannya terpisah menjadi name server, dan sebagian lagi tidak memakai satu pun dari ketiganya — menamai menunya Host Records, Register a Nameserver, atau langsung Glue Records. Kalau menu di panel Anda bernama salah satu dari itu, Anda sudah berada di tempat yang benar.
Glue Record dan Lingkaran yang Harus Diputus
Di sinilah persoalan teknis yang sesungguhnya. Bagian ini menjelaskan kenapa private nameserver tidak cukup dibuat dengan menambah record DNS biasa.
Bayangkan sebuah resolver ingin membuka domainanda.com. Ia bertanya ke server TLD .com, dan mendapat jawaban: "domain itu dikelola oleh ns1.domainanda.com". Resolver lalu perlu tahu alamat IP nama tersebut. Untuk mengetahuinya, ia harus bertanya kepada pengelola zona domainanda.com — yaitu ns1.domainanda.com itu sendiri, yang alamatnya justru sedang ia cari.
Lingkaran ini tidak bisa diputus dari dalam. Pemutusnya adalah glue record, yakni A record berisi alamat IP nameserver yang disimpan di zona induk, bukan di zona Anda. Server TLD mengirimkannya bersama jawaban rujukan, sehingga resolver langsung memegang alamat yang dibutuhkan.
Tanpa glue record pencarian IP ns1.domainanda.com berputar; dengan glue di zona TLD resolver langsung menghubunginya.
RFC 1912 (Common DNS Operational and Configuration Errors, Februari 1996) menyatakan glue record hanya diperlukan untuk nameserver yang berada di dalam zona yang sedang didelegasikan. Konsekuensinya praktis. Kalau nameserver Anda bernama ns1.domainanda.com dan melayani domainanda.com, glue wajib ada. Kalau namanya memakai domain lain, glue tidak diperlukan karena alamatnya dapat dicari lewat jalur normal.
RFC 9471 (DNS Glue Requirements in Referral Responses, September 2023) mempertegasnya. Glue untuk nameserver in-domain bersifat wajib, bukan opsional. Bila balasan terlalu besar untuk memuat semuanya, server harus menyalakan flag TC (truncated) dan memaksa resolver mengulang lewat TCP.
Ada satu kejanggalan yang bisa Anda temukan sendiri di lapangan. Sejumlah nameserver bergaya private ternyata tidak punya A record di zonanya sendiri — pertanyaan langsung ke server otoritatifnya membalas NOERROR dengan ANSWER: 0. Nama itu tetap bekerja, semata-mata karena glue-nya terdaftar di registry.
Syarat yang Perlu Disiapkan Sebelum Memulai
Sebelum menyentuh panel mana pun, empat hal berikut harus sudah tersedia. Melewatkan salah satunya adalah penyebab paling umum private nameserver gagal bekerja.
- Domain yang Anda kendalikan penuh: glue record didaftarkan di sisi registrar. Anda membutuhkan akses ke panel tempat domain itu terdaftar, bukan sekadar akses ke pengelolaan DNS-nya.
- Server dengan alamat IP publik yang tetap: alamat inilah yang akan tertanam di zona TLD. IP yang berubah-ubah membuat glue basi dalam hitungan hari, sehingga shared hosting biasa tidak memenuhi syarat ini. Praktiknya private nameserver lahir bersama VPS atau server khusus. Paket seperti VPS Indonesia sudah menyertakan IP tetap dan akses root yang dibutuhkan.
- Layanan DNS otoritatif yang benar-benar menjawab: sebuah proses harus mendengarkan di port 53 dan siap menjawab pertanyaan tentang zona Anda. Tanpa itu, delegasi Anda menjadi apa yang RFC 1912 sebut lame delegation — nameserver terdaftar sebagai penanggung jawab zona, tetapi tidak melayaninya.
- Minimal dua nameserver: RFC 1912 §2.8 menyebutnya kewajiban, bukan saran, dan menganjurkan server sekunder berada di luar jaringan Anda. Batas wajarnya tujuh nameserver; lebih dari itu hanya menyulitkan pengelolaan.
Poin keempat paling sering dikerjakan setengah hati. Banyak orang mendaftarkan ns1 dan ns2 dengan alamat IP yang sama persis. Syarat "dua nameserver" terpenuhi secara formal, tetapi redundansinya nol: saat satu mesin itu mati, kedua nameserver mati bersamaan.
Dua nameserver di satu server mati bersamaan, sedangkan empat nameserver di tiga jaringan tetap menjawab.
Sebagai pembanding yang bisa Anda periksa sendiri, indowebsite.net mendelegasikan zonanya ke empat nameserver ns01 sampai ns04. Keempatnya memakai alamat IP berbeda yang tersebar di tiga jaringan — sebagian di luar negeri, sebagian di blok IP Indonesia. Susunan semacam inilah yang dimaksud RFC 1912.
Fungsi Private Nameserver: Tiga Alasan yang Bertahan
Setelah semua syarat di atas, wajar bila Anda bertanya apa yang sebenarnya didapat. Fungsi private nameserver menyusut menjadi tiga alasan yang bertahan diuji, ditambah satu alasan populer yang tidak.
- Menyembunyikan penyedia di balik layanan reseller: bila Anda menjual hosting atas nama sendiri, nameserver bernama penyedia asal membocorkan siapa mitra Anda pada pemeriksaan pertama. Ini alasan paling kuat, dan satu-satunya yang benar-benar bersifat bisnis.
- Berpindah server tanpa merepotkan pelanggan: selama nameserver tetap bernama
ns1.domainanda.com, memindahkan seluruh pelanggan cukup dilakukan dengan memperbarui glue record di satu tempat. Pelanggan tidak perlu menyentuh panel domain mereka. - Kendali penuh atas zona: Anda menentukan sendiri nilai TTL, jenis record yang diizinkan, dan kebijakan pembaruan, tanpa menunggu antrean dukungan penyedia.
Alasan yang tidak bertahan adalah SEO. Mesin pencari menilai kecepatan respons, keamanan, dan kualitas halaman. Nama yang tertulis di kolom nameserver tidak termasuk di dalamnya.
Cara Membuat Private Nameserver: Urutan yang Menentukan
Langkah-langkahnya tidak rumit. Yang menentukan berhasil atau tidaknya justru urutan. Mendaftarkan glue sebelum server siap menjawab menghasilkan lame delegation yang telanjur tersimpan di cache resolver selama berjam-jam.
Langkah #1: Siapkan Layanan DNS di Server Terlebih Dahulu
Aktifkan layanan DNS otoritatif sebelum apa pun didaftarkan ke luar. Pada server berbasis WHM, pilihannya ada di menu Nameserver Selection: PowerDNS, BIND, atau dinonaktifkan. PowerDNS adalah pilihan bawaan sistem, sementara BIND9 tidak tersedia pada server yang menjalankan Ubuntu.
Pastikan layanannya hidup dan menjawab pertanyaan tentang zona Anda sebelum melanjutkan.
Langkah #2: Buat A Record untuk ns1 dan ns2 di Zona Anda
Di dalam zona domainanda.com, tambahkan A record ns1 dan ns2 yang mengarah ke alamat IP server. Pada WHM, langkah ini disediakan lewat tombol Configure Address Records di halaman Basic WebHost Manager Setup. Dokumentasi cPanel menegaskan nameserver membutuhkan A record agar bekerja pada IPv4, dan AAAA record bila Anda juga melayani IPv6.
Record ini terpisah dari glue. Keduanya sebaiknya berisi alamat yang sama supaya tidak terjadi ketidakcocokan data.
Langkah #3: Daftarkan Nameserver di Sisi Registrar
Inilah langkah yang membuat glue record masuk ke zona TLD. Buka panel tempat domain Anda terdaftar, lalu cari menu bernama Private Nameserver, Child Nameserver, Host Records, atau Register a Nameserver. Daftarkan pasangan nama dan alamat IP:
ns1.domainanda.com -> 203.0.113.10
ns2.domainanda.com -> 198.51.100.20Perubahan ini dikirim ke registry lewat protokol yang terpisah dari pengelolaan DNS biasa, sehingga tidak muncul di menu DNS management mana pun.
Langkah #4: Setel Nameserver Bawaan di Panel Server
Agar setiap akun baru langsung memakai nameserver Anda, ubah nilai bawaannya di Basic WebHost Manager Setup. Dokumentasi cPanel menyatakan akun baru tidak dapat dibuat sama sekali bila kolom nameserver dibiarkan kosong. Langkah ini memastikan zona pelanggan baru dibuat dengan NS record yang benar sejak awal.
Langkah #5: Arahkan Domain ke Nameserver Baru
Terakhir, ubah nameserver domain Anda sendiri — dan domain pelanggan bila ada — menjadi ns1.domainanda.com dan ns2.domainanda.com. Untuk domain yang dikelola lewat Client Area Indowebsite, langkahnya tersedia pada panduan cara mengubah nameserver domain.
Jangan mengarahkan domain produksi ke nameserver baru sebelum Langkah #1 sampai #4 selesai dan terverifikasi. Kesalahan pada tahap ini tidak berakibat "situs lambat", melainkan situs dan email berhenti dapat diakses.
Cara Cek Nameserver Langsung ke Server TLD
Kebanyakan orang memeriksa hasilnya dengan membuka situsnya. Cara itu menyesatkan, karena yang Anda lihat bisa jadi hanya cache resolver. Pemeriksaan yang benar dilakukan dengan bertanya langsung ke server TLD, sehingga yang terbaca adalah isi registry apa adanya.
Untuk domain berakhiran .com atau .net:
dig +noall +authority +additional \
ns domainanda.com @a.gtld-servers.netUntuk domain berakhiran .id, servernya berbeda:
dig +noall +authority +additional \
ns domainanda.id @b.dns.idYang Anda cari adalah baris A record ns1 dan ns2 pada bagian tambahan. Kalau baris NS muncul tetapi baris A tidak ada, glue record belum terdaftar dan Langkah #3 perlu diulang.
Pengguna Windows yang tidak memiliki dig dapat memakai nslookup dengan menyebut server TLD sebagai argumen terakhir:
nslookup -type=ns domainanda.id b.dns.idUntuk domain .com, ganti server tujuannya menjadi a.gtld-servers.net. Setelah alamat IP-nya terlihat, WHOIS dapat memberi tahu jaringan siapa yang sebenarnya memegang alamat tersebut.
Perhatikan juga angka TTL pada baris NS. Angka itu menentukan berapa lama kesalahan Anda bertahan di cache resolver dunia, dan nilainya ditentukan registry, bukan oleh Anda:
| Akhiran domain | TTL delegasi | Setara |
|---|---|---|
.com dan .net | 172.800 detik | 48 jam |
.id dan turunannya | 3.600 detik | 1 jam |
TTL delegasi nameserver di .com dan .net 172.800 detik (48 jam), sementara di .id hanya 3.600 detik (1 jam).
Artinya salah mendaftarkan glue pada domain .com dapat bertahan hingga dua hari penuh di sebagian resolver. Kesalahan serupa pada domain .id umumnya pulih dalam satu jam. Perilaku ini berbeda dari propagasi DNS pada record biasa, yang TTL-nya masih dapat Anda atur sendiri.
Kelemahan dan Hal yang Perlu Anda Pertimbangkan
Memindahkan nameserver ke nama sendiri berarti memindahkan tanggung jawabnya juga. Empat konsekuensi berikut melekat pada keputusan itu.
- Beban operasional berpindah ke Anda: setiap gangguan DNS kini menjadi tanggung jawab Anda, termasuk pada akhir pekan dan tengah malam. Sebelumnya bagian ini ditangani penyedia tanpa Anda sadari.
- Satu titik kegagalan menjatuhkan semua sekaligus: bila kedua nameserver berada di mesin atau jaringan yang sama, satu gangguan membuat seluruh domain pelanggan menghilang bersamaan — bukan hanya situsnya, tetapi juga emailnya.
- Perbaikan di sisi registry lebih lambat: mengubah glue tidak seperti mengubah A record. Prosesnya melewati registrar dan registry, lalu terkunci oleh TTL delegasi yang tidak dapat Anda turunkan.
- Glue tidak ikut ditandatangani: data glue di zona induk tidak dilindungi tanda tangan DNSSEC. Ketepatan isinya bergantung sepenuhnya pada kedisiplinan Anda memeliharanya.
Bahaya Glue Record yang Ditinggalkan
Risiko terbesar private nameserver justru muncul saat Anda berhenti memakainya. Skenarionya sederhana. Anda melepas VPS lama, alamat IP-nya kembali ke kolam penyedia dan diberikan kepada orang lain, tetapi glue ns1.domainanda.com masih menunjuk ke sana. Siapa pun yang kemudian menempati alamat itu berada dalam posisi menjawab pertanyaan DNS atas nama domain Anda.
Penelitian Rethinking the Security Threats of Stale DNS Glue Records pada 33rd USENIX Security Symposium (Agustus 2024) mengukur seberapa lazim keadaan ini. Hasilnya: 23,18% glue record di 1.096 TLD sudah kedaluwarsa namun tetap disajikan, dengan 193.558 record yang dapat dieksploitasi. Lebih dari 6 juta domain berada dalam risiko pengambilalihan atau penolakan layanan, dan 90% open resolver global memakai glue yang tidak divalidasi.
VPS lama dilepas dan IP-nya dipakai penyewa baru, tetapi glue ns1.domainanda.com masih menunjuk ke alamat itu.
Pencegahannya menuntut urutan yang benar saat membongkar, bukan hanya saat memasang:
- Pindahkan dahulu domain-domain yang memakai nameserver Anda ke nameserver lain, lalu tunggu selama TTL delegasi berlalu.
- Hapus pendaftaran nameserver di sisi registrar sehingga glue tercabut dari zona TLD.
- Baru setelah itu lepaskan atau kembalikan alamat IP-nya.
Urutan terbalik — melepas IP lebih dahulu — meninggalkan glue menggantung persis seperti temuan di atas. Bila sebuah nameserver masih dipakai domain lain, registrar umumnya menolak permintaan penghapusan. Penolakan itu sebaiknya dibaca sebagai peringatan yang benar.
Kapan Sebaiknya Anda Tidak Membuatnya
Private nameserver menuntut biaya perhatian yang nyata, sehingga tidak setiap orang pantas membuatnya. Tiga keadaan berikut sebaiknya menjadi tanda untuk berhenti.
Anda mengelola kurang dari sepuluh domain dan tidak menjual hosting. Manfaat penyembunyian merek tidak relevan, sementara risiko operasionalnya penuh Anda tanggung. Nameserver bawaan penyedia adalah pilihan yang lebih tenang.
Anda hanya punya satu server. Dua nameserver di satu mesin memberi ilusi redundansi tanpa isinya. Bila memaksakannya, minimal letakkan nameserver kedua di jaringan berbeda — lewat VPS kecil terpisah atau layanan DNS sekunder.
Anda menginginkan tampilan bermerek tanpa mengelola server DNS. Sejumlah penyedia DNS terkelola menawarkan nameserver bermerek sendiri. Cloudflare, misalnya, menyediakannya pada paket Business ke atas dengan dua sampai lima nama per set.
Pertanyaan yang Sering Muncul
Apakah private nameserver bisa dibuat di shared hosting?
Umumnya tidak, karena Anda tidak memegang alamat IP tetap dan tidak dapat mengubah pengaturan DNS tingkat server. Sebagian penyedia memberikan pengecualian untuk paket reseller. Untuk kendali penuh, VPS atau server khusus adalah titik masuk yang wajar.
Haruskah ns1 dan ns2 memakai alamat IP yang berbeda?
Banyak registrar menerima alamat yang sama, sehingga pendaftarannya tetap berhasil. Namun tujuan memiliki dua nameserver adalah bertahan saat satu gagal, dan itu hanya tercapai bila keduanya berbeda mesin. RFC 1912 menganjurkan keduanya berada di jaringan berbeda.
Apa bedanya dengan mengarahkan A record ke server saya?
A record mengatur ke mana pengunjung sebuah nama dikirim. Nameserver menentukan siapa yang berhak menjawab seluruh pertanyaan tentang domain itu. Mengubah A record memindahkan satu alamat; mengubah nameserver memindahkan kendali atas seluruh zona.
Kenapa nameserver baru saya belum terbaca?
Tiga sebab paling umum: glue record belum terdaftar di registrar, layanan DNS di server belum menjawab, atau TTL delegasi lama belum habis. Periksa langsung ke server TLD untuk memisahkan sebab pertama dari dua lainnya.
Berapa nameserver yang ideal untuk bisnis reseller?
Dua adalah batas minimum, empat sudah lebih dari memadai bila tersebar di jaringan berbeda. RFC 1912 menyebut tujuh sebagai batas wajar, dan angka di atasnya hanya menambah kerumitan tanpa menambah ketahanan.
Kesimpulan
Private nameserver adalah lapisan penamaan. Ia mengganti nama yang tampil pada delegasi domain Anda, tanpa dengan sendirinya mengganti mesin yang menjawab di baliknya. Bagian yang benar-benar menentukan adalah glue record di zona TLD, satu-satunya tempat alamat IP nameserver Anda dicatat. Bagian itu pula yang paling sering terlupakan, baik saat memasang maupun saat membongkar.
Bila Anda menjual hosting atas nama sendiri atau mengelola puluhan domain pelanggan, private nameserver sepadan dengan kerepotannya. Bila tidak, nameserver bawaan penyedia menyelesaikan pekerjaan yang sama dengan risiko jauh lebih kecil. Semoga artikel ini membantu.
