BIND9 Adalah: Fungsi, Versi & Struktur Konfigurasinya

Setiap kali Anda membuka sebuah situs, ada satu pertanyaan yang harus dijawab lebih dulu sebelum apa pun terjadi: nama domain itu menunjuk ke alamat mana. DNS adalah sistem yang menjawabnya, dan sistem itu bersifat terdistribusi — jawabannya tersebar di ribuan mesin di seluruh dunia.

Namun DNS hanyalah aturan main. Ia menetapkan bentuk pertanyaan, bentuk jawaban, dan siapa yang berhak menjawab apa. Di setiap mesin yang ikut menjawab, tetap harus ada program yang benar-benar berjalan, membaca data, dan membalas paket yang datang di port 53.

BIND9 adalah salah satu program tersebut, dan yang paling lama bertahan di antara semuanya.

BIND9 Adalah Perangkat Lunak DNS, Bukan Protokolnya

BIND9 adalah perangkat lunak DNS server yang bertugas menerima permintaan DNS lalu membalasnya, dikembangkan dan dirawat oleh Internet Systems Consortium (ISC). Namanya singkatan dari Berkeley Internet Name Domain, merujuk pada Universitas California, Berkeley, tempat perangkat lunak ini lahir. Angka 9 di belakangnya adalah nomor generasi mayor, bukan versi rilis.

Pembedaan ini penting dan sering kabur. DNS adalah protokol — sekumpulan aturan yang berlaku universal. BIND9 adalah satu implementasi dari aturan itu. Ada implementasi lain seperti Unbound, NSD, PowerDNS, dan Knot, dan semuanya berbicara protokol yang sama persis. Mengganti BIND9 dengan PowerDNS tidak mengubah cara DNS bekerja, sama seperti mengganti Nginx dengan Apache tidak mengubah cara HTTP bekerja.

Satu hal lagi yang membingungkan pendatang baru: nama programnya sendiri bukan bind9. Berkas yang benar-benar dijalankan bernama named (dibaca name-dee, dari name daemon), dan berada di /usr/sbin/named. Nama bind9 adalah nama paket dan nama proyeknya, dan keduanya sering dipakai bergantian.

BIND9 bersifat open source di bawah lisensi Mozilla Public License 2.0 sejak rilis 9.11, dan bebas dipakai termasuk untuk keperluan komersial.

Kenapa Angkanya Berhenti di 9

Cerita BIND dimulai di awal 1980-an di Computer Systems Research Group, Berkeley. Empat mahasiswa pascasarjana — Douglas Terry, Mark Painter, David Riggle, dan Songnian Zhou — mengerjakannya dengan pendanaan DARPA. Namanya muncul dari sebuah makalah teknis tahun 1984, dan perangkat lunaknya dikapalkan bersama 4.3BSD.

Pengembangannya kemudian berpindah tangan. Pada 1988 Paul Vixie, ketika itu di Digital Equipment Corporation, mengambil alih dan merilis versi 4.9. Vixie belakangan mendirikan Internet Systems Consortium, yang memegang proyek ini sampai sekarang. BIND 8 keluar Mei 1997, lalu BIND 9 dirilis 9 Oktober 2000 sebagai penulisan ulang arsitektur secara total, dikerjakan Nominum atas kontrak ISC.

Pertanyaannya wajar: kalau BIND 8 hanya bertahan tiga tahun, kenapa BIND 9 sudah 26 tahun dan angkanya tidak naik juga?

Jawabannya, penerusnya gugur. ISC memulai BIND 10 pada 2009 sebagai arsitektur baru yang sekaligus menangani DHCP. Pada April 2014, di rilis 1.2.0, ISC menghentikan keterlibatannya karena pertimbangan biaya. Kodenya diserahkan ke komunitas dengan nama baru, Bundy — penggantian nama yang disengaja supaya tidak lagi tertukar dengan BIND 9 yang tetap dirawat ISC. Komponen DHCP-nya dipisahkan menjadi proyek tersendiri bernama Kea, yang sampai hari ini masih aktif.

Perbandingan "BIND9 vs BIND 10" sudah tidak ada artinya sejak 2014. BIND 10 tidak pernah menggantikan siapa pun, dan pengembangannya sebagai Bundy lama berhenti.

Jadi angka 9 bertahan bukan karena BIND berhenti berkembang. Di dalam cabang 9, perubahan justru datang sangat rutin — dan sebagian di antaranya cukup besar untuk mematahkan konfigurasi lama. Bagian berikutnya akan sampai ke sana.

Dua Peran yang Sering Tertukar: Otoritatif dan Resolver

Sebelum menyentuh berkas konfigurasi apa pun, ada satu konsep yang harus jelas: satu proses named bisa menjalankan dua peran yang sangat berbeda.

Sebagai server otoritatif (authoritative), named memegang data asli sebuah zona dan memberi jawaban definitif untuknya. Kalau Anda mengelola contoh.co.id, server otoritatiflah yang memberi tahu dunia bahwa nama itu menunjuk ke alamat tertentu. Data zonanya dibaca dari berkas di disk, atau diterima dari server lain lewat zone transfer. Server dengan peran ini tidak perlu mengejar jawaban ke mana-mana.

Sebagai resolver rekursif, tugasnya justru kebalikannya. Ia menerima pertanyaan tentang nama yang bukan miliknya, lalu mengejar jawabannya sendiri ke hierarki DNS. Perjalanannya dimulai dari root, turun ke server TLD, sampai ke server otoritatif yang tepat. Hasilnya disimpan di cache sampai TTL-nya habis, supaya pertanyaan yang sama tidak perlu diulang. Peran inilah yang orang maksud ketika menyebut caching DNS server.

Alur named: nama milik zona sendiri dijawab dari berkas zona, nama di luar zona dikejar ke hierarki DNS lalu di-cache.

Direktif yang mengatur peran ini ada beberapa. recursion menentukan apakah named mau mengejar jawaban untuk klien. allow-recursion membatasi siapa saja yang boleh meminta layanan itu. forwarders membuat named melempar pertanyaan ke resolver lain alih-alih mengejar sendiri, dan forward only memaksanya selalu melempar tanpa pernah mencoba jalur langsung.

Menggabungkan kedua peran dalam satu proses secara terbuka adalah kesalahan konfigurasi yang mahal. Server otoritatif Anda bisa dipakai orang asing sebagai resolver gratis, dan lebih buruk lagi, dijadikan alat amplifikasi serangan. Aturannya: kalau server itu otoritatif untuk sebuah zona, matikan rekursi dengan recursion no;.

Fungsi BIND9 dalam Pekerjaan Sehari-hari

Dari dua peran di atas, muncul empat pemakaian yang paling sering ditemui di lapangan.

1. Nameserver otoritatif untuk domain sendiri: Anda menjalankan ns1 dan ns2 sendiri, lalu mendaftarkannya di registrar. Semua record — A, MX, CNAME, TXT, sampai PTR — Anda kelola langsung tanpa perantara panel.
2. Resolver internal untuk kantor atau kampus: satu resolver melayani seluruh klien di jaringan lokal. Selain lebih cepat karena jawaban populer sudah tersimpan, ia memberi Anda catatan permintaan dan kemampuan memblokir nama tertentu.
3. DNS internal untuk lab dan homelab: nama seperti nas.rumah.lokal hanya berarti di jaringan Anda dan tidak boleh bocor ke internet. BIND9 melayaninya tanpa perlu mendaftarkan domain apa pun.
4. Jawaban berbeda untuk penanya berbeda: lewat direktif view, satu server memberi alamat internal kepada klien kantor dan alamat publik kepada klien luar, untuk nama yang sama persis. Praktik ini disebut split DNS.

Yang menyatukan keempatnya adalah alasan yang sama, yaitu kendali. Sebuah BIND9 DNS server yang Anda kelola sendiri berarti Anda memegang datanya, memegang lognya, dan tidak bergantung pada jadwal maupun kebijakan penyedia lain.

Paket dan Perintah: Apa yang Sebenarnya Terpasang

Di Debian dan Ubuntu, seluruh proses pemasangan berawal dari satu perintah:

sudo apt install bind9

Perintah tersebut memasang paket server BIND9 beserta ketergantungannya. Bentuk sudo apt-get install bind9 mengerjakan hal yang sama — apt-get adalah perkakas lama yang masih tersedia, sedangkan apt antarmuka yang lebih baru. Yang ikut secara otomatis adalah bind9-libs (pustaka), bind9-utils (perkakas pemeriksa dan pengendali), serta dns-root-data — paket terakhir inilah sumber berkas root.hints yang berisi daftar server root.

Yang tidak ikut justru sering mengejutkan. Paket bind9-dnsutils hanya terdaftar sebagai saran (Suggests), bukan ketergantungan wajib. Padahal di sanalah dig dan nslookup berada. Karena itu banyak orang memasang BIND9 lalu langsung disambut dig: command not found saat hendak mengujinya. Pasang terpisah:

sudo apt install bind9-dnsutils

Berikut isi tiap paket, supaya Anda tahu harus mencari perkakas di mana:

Satu perkakas di paket terakhir layak dicatat: nsupdate mengubah isi zona selagi server berjalan, mekanisme yang dikenal sebagai dynamic DNS atau DDNS.

Kalau Anda menemukan panduan lama yang menyebut bind9utils atau dnsutils tanpa tanda hubung, keduanya adalah nama sebelum penggantian nama besar-besaran di seri 9.13. Sejak Februari 2025, kedua nama lama itu dipasang kembali sebagai penunjuk (Provides), sehingga apt install dnsutils tetap bekerja dan mengarah ke bind9-dnsutils.

Struktur Berkas Konfigurasi di Debian dan Ubuntu

File konfigurasi utama BIND9 adalah /etc/bind/named.conf. Letak ini khas Debian dan turunannya. Dokumentasi resmi ISC menyebut lokasi yang berbeda, dan keluarga Red Hat memakai /etc/named.conf tanpa subdirektori. Untuk melihat seluruh isi direktorinya, jalankan ls /etc/bind.

Isi named.conf sendiri hampir kosong. Ia hanya menarik tiga berkas lain, dan baris ketiganya berbeda antara Debian 13 dan Ubuntu 24.04.

Pada Ubuntu 24.04 LTS, ketiga barisnya adalah:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Pada Debian 13, baris ketiganya sudah berbeda:

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.root-hints";

Berkas named.conf.default-zones dihapus dari paket Debian pada 27 Juli 2025 dan digantikan named.conf.root-hints yang isinya jauh lebih ringkas — hanya definisi zona root. Bersamaan dengan itu, berkas db.local, db.127, db.255, db.empty, dan zones.rfc1918 ikut dilepas. Catatan resmi paketnya menyebutkan alasannya: zona kosong dan zona localhost kini ditangani direktif bawaan BIND 9 sendiri, empty-zones, yang memang aktif tanpa perlu dinyalakan.

Pembagian tugas ketiga berkas itu sendiri tidak berubah:

Isi named.conf: dua include pertama sama, baris ketiga menunjuk default-zones di Ubuntu 24.04 dan root-hints di Debian 13.

• named.conf.options — perilaku umum server: direktori kerja, forwarders, recursion, listen-on, dan pembatasan akses.
• named.conf.local — tempat Anda mendefinisikan zona sendiri. Semua penambahan zona seharusnya masuk ke sini, bukan ke named.conf.
• named.conf.root-hints atau named.conf.default-zones — zona bawaan. Berkas ini milik paket, jadi jangan disunting.

Isi bawaan named.conf.options juga berbeda antara keduanya. Ubuntu 24.04 mengirimkannya dengan contoh forwarders yang dikomentari, ditambah dnssec-validation auto; dan listen-on-v6 { any; };. Debian 13 mengirimnya nyaris kosong — hanya satu baris directory "/var/cache/bind";. Kalau Anda memerlukan validasi DNSSEC di Debian 13, direktifnya harus Anda tulis sendiri.

Baris listen-on-v6 itu sumber kebingungan yang sering muncul. Kalau mesin Anda punya alamat IPv6 lokal tetapi jalurnya ke internet belum melayaninya, log named akan dipenuhi baris network unreachable resolving — ia mencoba menghubungi server root lewat IPv6 dan selalu gagal. Perbaikannya bukan menghapus direktif itu, melainkan menambahkan -4 ke baris OPTIONS di /etc/default/named sehingga berbunyi OPTIONS="-u bind -4". ISC menganjurkan cara ini ketimbang server ::/0 { bogus yes; };, karena pendekatan kedua kadang memunculkan SERVFAIL yang datang dan pergi.

Direktori /var/cache/bind adalah direktori kerja named. Berkas zona yang diterima dari server lain dan berkas sementara ditulis di sana, bukan di /etc/bind.

Membaca Nomor Versi BIND9 dengan Benar

Penomoran BIND 9 mengikuti aturan ganjil-genap. Cabang bernomor genap adalah cabang stabil yang ditujukan untuk produksi. Cabang bernomor ganjil adalah cabang pengembangan, tempat fitur baru diuji sebelum dilabeli stabil. Jadi 9.20 adalah cabang produksi, sementara 9.21 belum.

Setiap cabang stabil didukung sekitar empat tahun, lalu berstatus Extended Support Version (ESV) sebelum akhirnya berhenti dirawat — kondisi yang disebut end of life atau EOL. Berikut kondisinya saat artikel ini ditulis, Agustus 2026:

Cabang stabil berikutnya, 9.22, semula dijadwalkan lebih awal tetapi ditunda hingga setidaknya akhir 2026.

Garis waktu cabang BIND 9: 9.16 EOL Maret 2024, 9.18 EOL 30 Juni 2026, 9.20 stabil sampai Q2 2028, 9.21 pengembangan.

Sekarang bagian yang membingungkan. Debian 13 mengirimkan paket bind9 versi 1:9.20.26, artinya cabang yang masih dirawat hulu. Ubuntu 24.04 LTS mengirimkan 1:9.18.39, cabang yang secara resmi sudah berhenti dirawat sejak Juni 2026. Apakah berarti pengguna Ubuntu 24.04 memakai perangkat lunak tanpa tambalan?

Tidak. Canonical memindahkan perbaikan keamanan ke versi yang sudah mereka kirimkan, praktik yang disebut backport. Perhatikan akhiran nomor paketnya, -0ubuntu0.24.04.6 — angka terakhir itu naik setiap ada tambalan, sementara 9.18.39 di depannya tetap. Jadi nomor versi hulu bukan penanda keamanan yang bisa dibaca begitu saja pada distribusi Linux yang menyediakan dukungan jangka panjang.

Untuk memeriksa versi yang benar-benar terpasang, gunakan dua perintah ini:

named -v
dpkg -l bind9

Perintah pertama menampilkan versi hulu, misalnya BIND 9.18.39-0ubuntu0.24.04.6-Ubuntu. Perintah kedua menampilkan versi paket lengkap dengan akhiran distribusinya.

Tiga Perubahan yang Mematahkan Konfigurasi Lama

Tiga perubahan berikut cukup besar untuk menghentikan konfigurasi yang selama ini berjalan. Ketiganya patut Anda periksa lebih dulu, terutama saat menaikkan versi server yang sudah dipakai.

Tiga perubahan BIND9: allow-transfer wajib eksplisit, zona bawaan jadi empty-zones, unit systemd bernama named.service.

Pertama, izin zone transfer berubah dari terbuka menjadi tertutup. Catatan rilis BIND 9.20 menyatakan bahwa ACL allow-transfer kini harus ditulis eksplisit — di tingkat zona, view, atau options — supaya transfer keluar diizinkan. Sebelumnya, tanpa direktif apa pun, transfer diizinkan secara bawaan. Akibatnya nyata: server sekunder (secondary) yang selama ini menerima zona bisa mendadak berhenti disinkronkan setelah server primernya naik ke 9.20.

Kedua, zona kosong dan zona localhost tidak lagi berupa berkas. Seperti dijelaskan di bagian sebelumnya, definisinya pindah ke direktif bawaan. Menyalin include "/etc/bind/named.conf.default-zones"; ke Debian 13 akan membuat named gagal dimuat, karena berkas yang dirujuk memang tidak ada.

Ketiga, unit systemd bernama named, bukan bind9. Nama unit diselaraskan dengan nama daemonnya sejak seri 9.13, dan bind9.service dipertahankan sebagai alias. Karena itu, di Debian dan Ubuntu kedua bentuk perintah berikut sama-sama bekerja:

sudo systemctl restart named
sudo systemctl restart bind9

Bentuk lama /etc/init.d/bind9 restart berasal dari era SysV init dan sebaiknya ditinggalkan; pada sistem modern ia hanya diteruskan ke systemd. Perlu diperhatikan juga bahwa alias bind9 hanya ada di Debian dan turunannya. Pada AlmaLinux, Rocky Linux, dan keluarga Red Hat lain, satu-satunya nama yang dikenal adalah named — di sanalah pesan Unit bind9.service not found biasanya muncul.

Satu detail terakhir soal unit ini. ExecReload di dalamnya memanggil rndc reload, bukan mengirim sinyal langsung ke proses. Kalau rndc tidak bisa berkomunikasi dengan named, perintah systemctl reload named ikut gagal meskipun prosesnya sendiri sehat.

Kenapa Tambalan Keamanan BIND9 Sekarang Datang Tiap Bulan

Pada 12 Mei 2026, ISC mengumumkan perubahan cara mereka merilis perbaikan keamanan. Sebelumnya perbaikan dikumpulkan dan dirilis sekitar sekali per triwulan. Sejak pengumuman itu, perbaikan keamanan keluar di setiap rilis pemeliharaan bulanan.

Alasannya disebutkan terus terang. Laporan kerentanan yang masuk ke ISC kini melaju pada tingkat yang melampaui sepuluh kali lipat kadar historis, karena model bahasa besar (large language model) mempermudah pencarian celah. ISC bahkan mulai mempertimbangkan penerbitan CVE untuk isu tingkat menengah, padahal sebelumnya hanya untuk skor CVSS di atas 7,0.

Angka berikut menunjukkan bahwa nomor cabang punya konsekuensi yang bisa diukur. Pada 22 Juli 2026, ISC menambal sembilan kerentanan sekaligus. Kesembilannya diperbaiki di rilis 9.20.26, dan tidak satu pun mendapat perbaikan di cabang 9.18 — yang memang sudah berhenti dirawat tiga minggu sebelumnya. Pada gelombang Mei 2026 pun, dua dari enam kerentanan hanya diperbaiki di cabang 9.20.

Sebagai gambaran, ambil CVE-2025-40778 dengan skor CVSS 8,6. Celahnya membuat BIND terlalu longgar menerima record di dalam jawaban, sehingga penyerang dapat menyisipkan data palsu ke dalam cache. Akibatnya, klien Anda bisa diarahkan ke server yang salah. Tidak ada solusi sementara untuk celah ini; satu-satunya jalan adalah menaikkan versi.

Beberapa langkah pengamanan dasar yang layak dikerjakan sejak hari pertama:

1. Matikan rekursi pada server otoritatif: recursion no; menutup pintu bagi resolver terbuka.
2. Batasi siapa yang boleh bertanya: allow-query untuk zona publik, allow-recursion untuk resolver internal yang cukup melayani jaringan sendiri.
3. Nyalakan pembatasan laju: direktif rate-limit menahan lonjakan permintaan yang dipakai untuk amplifikasi serangan.
4. Tutup port 53 dari sisi jaringan: aturan firewall hanya mengizinkan sumber yang memang perlu. Paket bind9 bahkan mencantumkan ufw sebagai saran pemasangan.

Memasang dan Memastikan BIND9 Benar-benar Jalan

Bagian ini berhenti pada memastikan layanannya hidup dan menjawab. Pembuatan berkas zona dan pengaturan primer-sekunder membutuhkan panduan tersendiri.

Langkah #1: Pasang paket beserta perkakas ujinya

Pasang server sekaligus perkakas klien dalam satu perintah, supaya Anda tidak kehilangan dig di langkah terakhir:

sudo apt update
sudo apt install bind9 bind9-dnsutils

Langkah #2: Periksa sintaks sebelum menyalakan

Memeriksa konfigurasi lebih dulu menghemat banyak waktu. Perintah berikut membaca named.conf beserta seluruh berkas yang di-include, lalu diam kalau semuanya benar:

sudo named-checkconf

Tidak ada keluaran berarti tidak ada kesalahan. Kalau ada, pesannya menyebut nama berkas dan nomor baris. Untuk memeriksa berkas zona, perkakasnya named-checkzone dengan nama zona dan berkasnya sebagai argumen.

Langkah #3: Nyalakan layanan dan periksa statusnya

Aktifkan supaya ikut hidup saat server dinyalakan ulang, lalu jalankan:

sudo systemctl enable --now named
sudo systemctl status named

Yang Anda cari adalah baris Active: active (running). Kalau statusnya failed, jangan berhenti di situ — baca lognya:

sudo journalctl -u named -n 50 --no-pager

Di sinilah pesan yang sebenarnya berada. Kesalahan yang paling sering muncul adalah titik koma yang hilang, berkas include yang tidak ada, dan port 53 yang sudah dipakai proses lain seperti systemd-resolved.

Langkah #4: Uji dengan bertanya ke server itu sendiri

Terakhir, buktikan bahwa named benar-benar menjawab:

dig @127.0.0.1 indowebsite.co.id

Yang perlu Anda periksa ada dua: baris status: NOERROR di bagian header, dan bagian ANSWER SECTION yang berisi jawaban. Kalau muncul SERVFAIL, named menerima pertanyaannya tetapi gagal menyelesaikannya — biasanya karena rekursi dimatikan sementara zonanya bukan milik server itu, atau karena server tidak bisa menjangkau internet. Catatan log named sendiri bisa diarahkan ke berkas tersendiri lewat blok logging.

Setelah layanannya jalan, tiga perintah rndc akan sering Anda pakai. rndc status menampilkan kondisi server beserta jumlah zona yang dimuat. rndc reload memuat ulang konfigurasi dan berkas zona tanpa memutus layanan, jadi lebih halus daripada me-restart. Sementara rndc flush mengosongkan seluruh cache resolver — berguna ketika sebuah record baru saja berubah dan Anda ingin memaksa jawaban segar. Untuk satu nama saja, pakai rndc flushname contoh.co.id.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

BIND9 memberi kendali penuh, dan kendali itu datang dengan beberapa konsekuensi.

1. Tidak ada antarmuka grafis bawaan: tidak ada GUI maupun panel web resmi, seluruh pengaturan berupa berkas teks. Ada panel pihak ketiga seperti Webmin, tetapi semuanya di luar proyek resmi dan justru menambah permukaan serangan pada server yang seharusnya sederhana.
2. Satu kesalahan ketik menjatuhkan seluruh zona: sintaksnya ketat, dan titik di akhir nama domain punya arti. Menulis contoh.co.id alih-alih contoh.co.id. di berkas zona menghasilkan nama yang sama sekali berbeda. Kebiasaan menjalankan named-checkconf sebelum memuat ulang bukan formalitas.
3. Tidak ada dukungan Windows: rilis terakhir yang membawa dukungan Windows adalah 9.17.14 pada Juni 2021, dan cabang stabil terakhir yang mendukungnya, 9.16, berhenti dirawat Maret 2024. Sejak itu tidak ada rilis BIND resmi untuk Windows yang masih ditambal; berkas pemasang yang beredar adalah rilis usang. Kalau server Anda berbasis Windows, layanan DNS bawaan Windows Server adalah pilihan yang wajar.
4. Pemeliharaan menjadi pekerjaan rutin: dengan tambalan keamanan yang keluar bulanan, memasang lalu meninggalkannya bukan pilihan. Anda membutuhkan jadwal pembaruan yang berjalan, atau pemantauan yang memberi tahu ketika versinya tertinggal.

Kapan Sebaiknya Anda Tidak Memakai BIND9

BIND9 dirancang untuk mengerjakan hampir semua hal di ranah DNS. Justru karena itu, untuk kebutuhan yang sempit sering ada pilihan yang lebih ringan dan lebih sedikit bagian yang bisa salah.

Lalu kapan BIND9 justru pilihan yang paling masuk akal? Ketika Anda membutuhkan satu perangkat lunak yang menangani peran otoritatif dan resolver sekaligus. Juga ketika Anda memerlukan fitur lanjutan seperti view atau response policy zone (RPZ). Ketersediaan rujukan ikut bernilai: hampir setiap masalah DNS yang pernah ada sudah terdokumentasi dalam istilah BIND, dan dokumentasi resmi ISC memuat seluruh direktif beserta contohnya.

Kebutuhan Sumber Daya dan Cara Menjalankannya

Kabar baiknya, BIND9 tidak rakus. Untuk resolver internal yang melayani sekitar 50 sampai 100 klien kantor, 1 vCPU dan RAM 1 GB sudah memadai. Untuk nameserver otoritatif yang melayani beberapa puluh zona dengan lalu lintas wajar, 2 vCPU dan RAM 2 GB memberi ruang lega. Kebutuhan RAM naik seiring besarnya cache pada resolver, dan itu diatur lewat max-cache-size.

Yang lebih menentukan justru bukan spesifikasi perangkat kerasnya. Sebuah nameserver otoritatif membutuhkan alamat IP publik yang tetap dan port 53 yang benar-benar terbuka pada UDP maupun TCP. Banyak koneksi rumahan dan sebagian penyedia awan memblokir port ini secara bawaan, dan itu menggagalkan semuanya sebelum konfigurasi apa pun sempat diuji. Karena alasan tersebut, VPS dengan akses root dan IP publik — misalnya VPS Indonesia — adalah tempat paling umum untuk menjalankannya.

Selain pemasangan langsung di sistem, ada dua cara lain yang banyak dipakai:

• Di dalam container: praktis untuk lingkungan uji dan mudah diulang lewat Docker Compose. Perlu diperhatikan bahwa port 53 harus dipetakan pada UDP dan TCP sekaligus, dan berkas zona sebaiknya diletakkan di volume supaya tidak ikut hilang saat container diganti.
• Di dalam LXC pada Proxmox: lebih ringan daripada mesin virtual penuh dan cocok untuk homelab. Beban named yang kecil membuatnya nyaman berbagi host dengan layanan lain.

Untuk nameserver produksi, pemasangan langsung di sistem masih paling sederhana; tiap lapisan tambahan berarti satu tempat lagi yang bisa salah ketika DNS Anda mati.

Pertanyaan yang Sering Muncul

Apa singkatan dari BIND? Berkeley Internet Name Domain. Namanya merujuk pada Universitas California, Berkeley, tempat perangkat lunak ini dikerjakan sejak awal 1980-an dan namanya muncul lewat sebuah makalah teknis tahun 1984.

Apa beda BIND dan BIND9? Keduanya perangkat lunak yang sama. BIND nama proyeknya, angka 9 menandai generasi mayor yang dirilis 9 Oktober 2000 dan masih dipakai sampai sekarang.

Apakah BIND9 masih bisa dijalankan di Windows? Tidak dengan rilis yang masih didukung. Dukungan Windows berakhir di rilis 9.17.14 bulan Juni 2021, dan cabang stabil terakhir yang membawanya berhenti dirawat Maret 2024.

Perintah apa yang dipakai untuk me-restart BIND9? Pada Debian dan Ubuntu modern, gunakan sudo systemctl restart named. Bentuk sudo systemctl restart bind9 juga bekerja karena bind9.service dipertahankan sebagai alias. Bentuk lama /etc/init.d/bind9 restart berasal dari era SysV init dan sebaiknya tidak dipakai lagi.

Apakah BIND9 gratis? Ya. BIND9 dirilis di bawah lisensi Mozilla Public License 2.0 sejak rilis 9.11, dan bebas dipakai termasuk untuk keperluan komersial tanpa biaya lisensi. ISC menjual dukungan berbayar secara terpisah, tetapi perangkat lunaknya sendiri tetap terbuka.

Port berapa yang dipakai BIND9? Layanan DNS-nya berjalan di port 53, pada UDP maupun TCP — keduanya perlu terbuka, karena jawaban berukuran besar dan zone transfer memakai TCP. Selain itu ada port 953 untuk kanal kendali rndc, yang seharusnya hanya dapat diakses dari mesin itu sendiri.

Kesimpulan

BIND9 adalah perangkat lunak DNS server yang menjalankan dua peran berbeda: otoritatif untuk zona miliknya sendiri, dan resolver untuk nama di luar itu. Memisahkan keduanya dengan benar adalah keputusan konfigurasi paling penting yang akan Anda ambil. Kendali penuh yang ditawarkannya sepadan kalau Anda mengelola zona sendiri atau membutuhkan fitur lanjutan. Untuk kebutuhan yang lebih sempit, Unbound, NSD, atau dnsmasq sering menyelesaikannya dengan bagian yang jauh lebih sedikit.

Satu hal yang tidak bisa ditawar kalau Anda memilih menjalankannya sendiri: perhatikan nomor cabangnya. Dengan tambalan keamanan yang kini keluar setiap bulan, memasang BIND9 lalu melupakannya adalah cara paling pasti untuk menjalankan layanan yang berlubang.

Semoga artikel ini membantu.