DNS privat untuk jaringan VPS: cara kerjanya dan kapan Anda membutuhkannya

Anda menjalankan server ketiga, ingin mesin-mesin saling menghubungi lewat nama alih-alih IP, lalu mencari "private DNS VPS". Tiga hasil muncul dan ketiganya tidak sejalan. Satu adalah pengaturan Android yang mengenkripsi kueri ponsel Anda. Satu adalah panduan cPanel untuk memberi merek pada nameserver sebuah domain. Satu lagi adalah dokumen AWS tentang private hosted zone. Pada 20 Juli 2026, Cloudflare merilis Internal DNS ke ketersediaan umum dan menyebutnya sebagai "terkadang juga disebut DNS privat", sehingga kini kerancuan itu datang dari vendor infrastruktur juga.

Istilah ini punya terlalu banyak makna. Artikel ini memisahkan berbagai maknanya, lalu berfokus pada makna jaringan VPS: zona DNS internal untuk komunikasi antarserver. Di akhir, Anda dapat mengenali sistem mana yang Anda butuhkan, memutuskan apakah armada server Anda memerlukan DNS privat, dan menghindari kesalahan desain yang umum.

TL;DR

• "DNS privat" menyebut setidaknya tiga sistem yang tidak berkaitan: zona DNS internal untuk jaringan server, fitur enkripsi DNS-over-TLS milik Android, dan nameserver bermerek dari cPanel. Artikel ini memakai istilah tersebut dalam makna pertama: zona DNS internal untuk jaringan VPS.
• Zona DNS privat VPS adalah namespace internal bercakupan jaringan yang memetakan nama host seperti db.internal.example.com ke IP privat. Rekamannya tidak dipublikasikan di DNS publik.
• Untuk beberapa server dengan IP yang stabil, /etc/hosts benar-benar cukup. Server DNS internal baru sepadan ketika armada bertambah, IP sering berganti, atau layanan memerlukan resolusi nama yang andal.
• Untuk sebagian besar jaringan VPS produksi, gunakan subdomain milik Anda sendiri, seperti internal.example.com. Gunakan namespace .internal hanya untuk penyiapan terisolasi yang dapat menerima tabrakan nama antarjaringan, pengelolaan sertifikat lewat CA privat, dan penanganan DNSSEC khusus. Hindari .local, yang dicadangkan oleh mDNS.

Apa yang Tidak Dibahas Artikel Ini

Tulisan ini terbatas pada makna jaringan VPS dari DNS privat. Tulisan ini tidak membahas penggunaan konsumen dan merek hosting yang tidak berkaitan:

• Mengonfigurasi pengaturan DNS privat atau DNS-over-TLS Android di ponsel.
• Menyiapkan nameserver privat cPanel untuk sebuah merek hosting.
• Panduan instalasi lengkap BIND 9, Unbound, dnsmasq, atau CoreDNS. Implementasi di sini tetap pada tingkat rujukan, bukan konfigurasi langkah demi langkah.
• Resolver terenkripsi untuk konsumen seperti 1.1.1.1 atau NextDNS, di luar membedakannya dari makna jaringan.

Apa Sebenarnya Arti "DNS Privat"?

"DNS privat" bukan satu sistem. Istilah ini menyebut setidaknya tiga sistem yang tidak berkaitan: zona DNS terbatas jaringan yang meresolusi nama host internal di dalam jaringan VPS atau VPC, fitur enkripsi DNS-over-TLS milik Android, dan nameserver otoritatif bermerek khusus dari cPanel. Artikel ini membahas yang pertama, yaitu zona internal yang dikueri server Anda untuk saling menemukan. Ada juga penggunaan keempat yang longgar: resolver publik terenkripsi yang dipasarkan sebagai "privat".

Keempat makna itu hanya berbagi nama, tidak lebih:

Pengumuman ketersediaan umum Internal DNS dari Cloudflare adalah contoh terkelola yang terkini untuk makna pertama, sekaligus satu alasan mengapa kerancuan ini kini terlihat: sebuah vendor infrastruktur kini memakai "DNS privat" sebagai sinonim DNS internal dalam salinan peluncurannya. Sistem yang digambarkannya, yaitu Gateway Resolver plus Internal Authoritative DNS untuk pelanggan Enterprise, termasuk kategori sistem yang sama dengan yang Anda bangun sendiri di armada VPS, hanya saja terkelola.

Inti bagian ini: sistem-sistem utama yang disebut "DNS privat" berbagi label, bukan fungsi. Pastikan dulu maknanya sebelum mengikuti panduan penyiapan.

Bagaimana Cara Kerja DNS Privat di Jaringan VPS?

Zona DNS privat VPS adalah namespace bercakupan jaringan yang dilayani oleh resolver yang dikonfigurasi untuk dipakai server Anda. Zona ini memetakan nama host internal seperti db.internal.example.com ke IP privat dalam rentang yang Anda kendalikan. Rekaman itu tidak dipublikasikan di DNS publik, meskipun kueri bisa melewati terowongan privat atau control plane DNS terkelola sebelum sampai ke resolver. Pemisahan itulah inti perbedaan antara DNS privat dan DNS publik: protokolnya sama, tetapi keterlihatan zona dan cakupan aksesnya berbeda.

Tiga bagian yang mengerjakannya. Server otoritatif atau sumber zona menyimpan zona internal beserta rekamannya. Resolver menjawab kueri yang dikirim server Anda. Dan rekaman A serta AAAA pada zona itu memetakan nama host internal ke alamat privat, sehingga app.internal.example.com mengarah ke lapisan aplikasi dan db.internal.example.com mengarah ke basis data. Jenis rekaman lain dapat menyediakan alias atau informasi layanan. Ketika zona dan jalur resolver dikonfigurasi dengan benar, resolver menjawab kueri internal secara lokal alih-alih mengirimkannya ke root DNS publik.

Platform cloud membatasi hal ini pada jaringan alih-alih pada mesin, dan itu model rujukan yang berguna. Private hosted zone AWS Route 53 hanya bekerja jika VPC menyetel enableDnsHostnames dan enableDnsSupport ke true, dan resolver menjawab dari zona privat untuk setiap VPC yang Anda kaitkan dengannya. Zona privat Google Cloud dibatasi pada jaringan VPC yang diotorisasi, dan dalam urutan resolusi VPC standar zona-zona itu diperiksa sebelum DNS publik, kecuali sebuah kebijakan server keluar mengubah jalurnya. Bacalah itu sebagai ilustrasi pola, bukan tutorial platform: server DNS internal yang Anda kelola sendiri adalah gagasan yang sama, hanya berjalan di VPS Anda sendiri.

Menjaga zona di luar DNS publik baru separuh pekerjaan. Ikat layanan DNS ke antarmuka privat atau batasi port 53 UDP dan TCP hanya ke jaringan privat atau VPN Anda. Jangan mengekspos layanan rekursif ke internet publik; sebab resolver terbuka bisa disalahgunakan dalam serangan amplifikasi DNS.

Zona privat dan publik memakai model rekaman dan caching DNS yang sama. Rekaman membawa TTL, dan resolver yang melakukan caching biasanya memakai ulang sebuah jawaban sampai TTL itu kedaluwarsa, meski pengaturan khusus resolver dapat mengubah waktu cache efektifnya. Perilaku itu dibahas dalam panduan kami tentang mengarahkan domain ke VPS, termasuk dasar-dasar propagasi DNS dan TTL, sehingga tidak dijelaskan ulang di sini.

Kapan Jaringan VPS Anda Benar-benar Memerlukan DNS Privat?

Untuk dua atau tiga server statis, /etc/hosts benar-benar cukup. Server DNS internal baru sepadan ketika armada bertambah, IP berubah secara berkala, atau aplikasi memerlukan service discovery yang andal. Pemicu sebenarnya adalah kompleksitas operasional, bukan jumlah server yang tetap.

/etc/hosts adalah peta statis nama host ke IP yang sudah ada di setiap mesin Linux. Ia tidak memerlukan daemon maupun berkas zona, tetapi salinan yang usang atau tidak konsisten adalah mode kegagalan yang nyata. Tambahkan IP privat setiap server ke berkas itu, jaga agar salinannya tetap sinkron, dan mesin-mesin pun bisa saling menemukan lewat nama. Untuk armada kecil dan stabil, itulah jawaban yang benar, sedangkan beralih ke BIND 9 hanya menambah satu daemon untuk dirawat tanpa keuntungan apa pun.

Pendekatan itu berhenti sepadan dalam tiga situasi. Ketika Anda sering menambah dan melepas server, menjaga sebuah berkas statis tetap konsisten di setiap host berubah jadi kerja manual yang melelahkan. Ketika IP berubah, lewat autoscaling, pembangunan ulang, atau realokasi dari penyedia, berkas itu jadi usang tanpa suara. Dan ketika kontainer atau runtime terisolasi tidak mewarisi entri milik host, pemetaan itu berhenti bersifat universal. Salah satu saja dari semua itu sudah jadi pemicu sebenarnya. Jumlah server semata hanyalah perkiraan kasar, bukan sinyal yang sesungguhnya.

Inti bagian ini: pemicunya adalah gejolak operasional, bukan jumlah server. Armada sepuluh mesin yang tidak pernah berubah bisa hidup dengan /etc/hosts; sedangkan armada tiga mesin yang dibangun ulang tiap malam sebaiknya tidak.

Bangun di VPS Linux dengan akses root, NVMe, dan tenaga AMD EPYC.

Lihat Paket Linux

Server DNS Mana yang Sebaiknya Anda Jalankan: BIND 9, Unbound, dnsmasq, atau CoreDNS?

Pilih berdasarkan bentuk armada Anda. dnsmasq cocok untuk jaringan kecil yang ingin DNS ringan dan, bila relevan, DHCP dari daemon yang sama. Unbound adalah resolver rekursif ramping dengan validasi, yang juga bisa menjawab zona lokal sederhana. BIND 9 menyediakan kemampuan otoritatif dan rekursif yang luas dengan permukaan konfigurasi terlebar. CoreDNS pas untuk armada kontainer dan Kubernetes di mana DNS menjadi bagian dari service discovery.

Logika pemilihannya singkat. Jika Anda butuh resolver kecil yang bersandar pada berkas bergaya hosts, atau sudah membagikan sewa DHCP, dnsmasq menghapus satu bagian bergerak. Jika yang Anda perlukan terutama resolver dengan validasi yang meneruskan ke luar dan menjawab zona internal sederhana, Unbound menyediakan rangkaian fitur yang lebih sempit itu tanpa penerapan BIND 9 secara penuh. Jika Anda butuh kendali otoritatif penuh, pendelegasian, dan kumpulan dokumentasi terbesar untuk bersandar pukul tiga pagi, BIND 9 tetap pilihan konservatif meski permukaan konfigurasinya lebih luas. Jika DNS memang sudah bagian dari tumpukan service discovery berbasis kontainer atau Kubernetes, CoreDNS menemuinya di sana. Aturan praktisnya: jalankan hal terkecil yang menutupi bentuk armada Anda.

Untuk armada produksi, jangan jadikan satu instans DNS sebagai satu-satunya jalur menuju setiap nama internal. Jalankan setidaknya dua instans DNS yang bisa menjawab zona itu, tempatkan pada domain kegagalan terpisah bila memungkinkan, dan konfigurasikan klien agar dapat menjangkau keduanya. Kalau tidak, satu gangguan DNS bisa membuat layanan yang sehat tampak mati.

Bagaimana Sebaiknya Menamai Domain Internal Anda: .internal, .local, atau Subdomain?

Untuk sebagian besar jaringan VPS produksi, gunakan subdomain milik Anda sendiri, seperti internal.example.com. Gunakan namespace .internal hanya untuk penyiapan terisolasi yang dapat menerima tabrakan nama antarjaringan, pengelolaan sertifikat lewat CA privat, dan penanganan DNSSEC khusus. Hindari .local, yang dicadangkan oleh mDNS.

Masalah .local itu konkret. RFC 6762 memberi nama yang berakhiran .local penanganan khusus untuk Multicast DNS, sehingga zona unicast BIND 9 atau Unbound yang memakai akhiran sama bisa berbenturan dengan perilaku mDNS di perangkat Apple dan sistem lain yang mendukung mDNS. Pakailah namespace lain alih-alih mengandalkan akal-akalan khusus per klien.

Tips: Kalau Anda mewarisi zona internal .local, perlakukan itu sebagai utang teknis. Sebagian klien mengirim kueri .local ke mDNS alih-alih ke server DNS unicast Anda, yang bisa menghasilkan kegagalan yang bergantung pada klien atau tampak muncul sesekali.

Dewan ICANN secara permanen mencadangkan .internal dari pendelegasian di root DNS publik pada Juli 2024, menyusul rekomendasi SSAC sebelumnya. Nama di bawahnya memang dirancang untuk tidak dapat diresolusi lewat DNS global. Itu datang dengan konsekuensi: nama .internal tidak unik secara global, otoritas sertifikat publik tidak diharapkan menerbitkan sertifikat untuknya, dan resolver yang memvalidasi DNSSEC dengan bersandar pada trust anchor global akan gagal meresolusinya. Jika Anda perlu HTTPS di .internal, rencanakan untuk mengoperasikan CA privat.

Bedakan dua hal di sini. Pencadangan oleh ICANN bersifat final. Terpisah dari itu, ada Internet-Draft aktif, draft-davies-internal-tld-06, diterbitkan pada 6 Mei 2026 untuk mendokumentasikan namespace ini dan membandingkannya dengan pengalamatan privat RFC 1918. Dokumen itu masih berupa Internet-Draft yang sedang berjalan, bukan RFC yang sudah terbit, jadi gambarkan .internal sebagai TLD penggunaan privat yang dicadangkan ICANN, bukan standar IETF.

Untuk sebagian besar armada VPS, subdomain dari domain yang Anda kendalikan adalah pilihan bawaan yang lebih aman. ISC merekomendasikan hierarki subdomain, misalnya subdomain internal dari domain Anda sendiri, ketimbang memelihara dua versi terpisah dan tidak lengkap, internal dan publik, dari zona induk yang sama. Preferensi itu bukan soal gaya; ia mencegah kegagalan yang dibahas di bagian berikutnya.

Inti bagian ini: keputusan soal namespace berumur panjang. Subdomain yang Anda kendalikan adalah pilihan bawaan untuk sebagian besar lingkungan produksi karena menjaga keunikan global dan bekerja dengan PKI publik. Gunakan .internal ketika namespace privat yang terisolasi lebih cocok dan Anda menerima konsekuensinya pada DNSSEC, sertifikat, dan tabrakan nama.

Split-Horizon DNS dan Kesalahan yang Merusaknya

Split-horizon DNS memberi jawaban berbeda untuk nama host yang sama tergantung siapa yang bertanya: IP privat dari dalam, IP publik dari luar. Ia paling sering rusak karena jebakan NXDOMAIN pada domain yang sama, resolver alternatif yang melewati tampilan yang dimaksud, dan jalur DNS kontainer yang tidak mencapai hulu yang diharapkan. Membuatnya benar bergantung pada tiga hal sekaligus, bukan satu.

Jebakan NXDOMAIN adalah kegagalan yang diperingatkan langsung oleh ISC. Jika server internal Anda otoritatif untuk domain induk, tetapi versi zona di sana tidak memuat rekaman publik seperti host www, klien internal yang mengueri nama itu akan menerima NXDOMAIN meskipun zona publik memilikinya. Zona internal itu otoritatif dan tidak jatuh kembali ke DNS publik untuk domain induk. Persis inilah alasan pendekatan hierarki subdomain dari bagian penamaan menjadi rancangan yang dipilih ISC.

Tips: Sebelum mengarahkan server Anda ke penyiapan split-horizon pada domain yang sama, coba resolusi sebuah nama publik yang dikenal di domain itu dari dalam jaringan. Jawaban NXDOMAIN untuk nama yang dari luar teresolusi baik-baik saja adalah ciri khas jebakan ini.

Tiga jebakan lain mudah terlewat. Resolver alternatif yang dikonfigurasi pada host atau kontainer bisa melewati pemisahan ini; tergantung implementasi resolvernya, ia mungkin dikueri setelah waktu habis atau secara paralel, sehingga jawabannya bisa berbeda-beda. Kontainer pada bridge bawaan Docker menerima salinan konfigurasi DNS host saat mulai berjalan, sedangkan kontainer pada jaringan kustom mengueri resolver bawaan Docker di 127.0.0.11. Resolver itu meneruskan pencarian eksternal ke server DNS yang dikonfigurasi untuk host atau kontainer, sehingga perilaku split-DNS bergantung pada konfigurasi Docker dan host, bukan hanya pada berkas resolver milik kontainer itu sendiri. Jika sebuah layanan internal berada di balik reverse proxy seperti Pengelola Proxy Nginx, validasi sertifikat bisa gagal ketika sertifikat itu tidak mencakup nama host yang diminta atau CA penerbitnya tidak dipercaya oleh klien. Sekadar memakai sertifikat berbeda di sisi internal bukanlah kesalahan. Ini celah konfigurasi, bukan bug pada alatnya.

Klien jarak jauh bisa mengalami kegagalan yang sama ketika sebuah VPN swakelola tidak mendorong atau merutekan kueri DNS ke resolver internal yang dimaksud.

Ada juga dimensi keamanan. Kalau nama host internal dan IP privat bocor ke rekaman DNS publik, Anda telah membuka sebagian skema penamaan dan pengalamatan internal kepada siapa pun yang mengueri. Split-horizon sebagian ada untuk menjaga peta itu tetap di dalam, dan zona publik yang salah konfigurasi diam-diam membatalkannya.

Inti bagian ini: kegagalan split-horizon adalah jebakan konfigurasi, bukan cacat alat. Kebenarannya bergantung pada disiplin penamaan, mengetahui resolver mana yang sebenarnya dikueri tiap klien, dan menetapkan cakupan zona dengan benar, bukan pada satu setelan tunggal.

BACA

Cara Mengarahkan Domain ke VPS: Panduan Singkat

Kesimpulan: Memilih Rancangan DNS Privat yang Tepat

Sekarang Anda bisa mengenali sistem "DNS privat" mana yang sebenarnya Anda maksud. Untuk jaringan VPS, itu adalah zona DNS internal, bukan pengaturan DNS-over-TLS Android atau nameserver otoritatif bermerek. Kalau armada Anda kecil dan stabil, /etc/hosts adalah pilihan yang bisa dipertanggungjawabkan. Kalau tidak, pakailah subdomain milik Anda sendiri sebagai namespace bawaan, pilih server DNS terkecil yang cocok dengan armada, serta buat akses, redundansi, dan cakupan zona internal versus publik menjadi eksplisit. Gunakan .internal hanya bila namespace terisolasi lebih cocok dan Anda menerima konsekuensinya pada sertifikat, DNSSEC, dan tabrakan nama.

Pertanyaan yang Sering Diajukan