Bitnesia
DNS Server dengan BIND9

Part of a series

Linux 102: Administrasi Server dengan Ubuntu

DNS Server dengan BIND9

Bitnesia • Aug 26, 2026 99 •EN

Setiap kali Visitor mengetik nama domain di browser, ada satu proses yang terjadi di belakang layar sebelum satu byte pun dari halaman web sampai ke layar mereka: nama domain itu harus diterjemahkan dulu menjadi IP address. Proses penerjemahan ini adalah tugas DNS (Domain Name System), dan di banyak infrastruktur, baik untuk domain publik maupun jaringan internal kantor, Sysadmin sendiri yang bertanggung jawab menjalankan server DNS-nya. Developer butuh domain internal seperti db.internal.local untuk menunjuk ke database server tanpa harus menghafal IP, atau perusahaan butuh DNS server sendiri agar tidak bergantung penuh pada resolver pihak ketiga, sehingga di situlah BIND9 masuk sebagai salah satu software DNS server paling matang dan paling banyak dipakai di dunia.

Bab ini melanjutkan pembahasan jaringan dari Bab 8, dan mengasumsikan server sudah punya IP statis yang stabil, karena DNS server yang alamatnya berubah-ubah jelas bukan ide baik. Kita akan mulai dari review singkat konsep DNS, lanjut ke instalasi dan konfigurasi BIND9 sebagai authoritative server lengkap dengan zone forward dan reverse, mengenal skema primary-secondary untuk redundansi, menguji resolusi dengan dig dan nslookup, lalu menutup dengan konfigurasi caching DNS server sederhana.

9.1 Konsep DNS

DNS bekerja seperti buku telepon raksasa yang terdistribusi di seluruh dunia: manusia lebih mudah mengingat nama seperti example.com dibanding IP address seperti 93.184.216.34, sementara mesin dan router tetap butuh IP address untuk benar-benar mengirim paket data. DNS menjembatani dua kebutuhan itu. Tanpa DNS, internet tetap bisa berjalan secara teknis, tapi nyaris mustahil dipakai manusia sehari-hari.

Struktur DNS berbentuk hierarki, mirip struktur direktori dari akar ke daun. Paling atas ada root zone (disimbolkan titik kosong di akhir nama domain), di bawahnya ada TLD (Top-Level Domain) seperti .com, .id, atau .org, lalu di bawahnya lagi domain yang didaftarkan seperti example.com, dan bisa terus bercabang ke subdomain seperti www.example.com atau db.internal.example.com. Setiap segmen dalam hierarki ini dikelola oleh server yang disebut authoritative nameserver, yaitu server yang punya data asli dan sah untuk zone tersebut, berbeda dengan recursive resolver yang tugasnya mencari jawaban ke server lain atas nama client dan menyimpan hasilnya sementara di cache.

Saat sebuah aplikasi di komputer User meminta alamat www.example.com, resolver akan bertanya secara berurutan mulai dari root server, diarahkan ke server .com, lalu diarahkan lagi ke authoritative nameserver milik example.com, sampai akhirnya dapat jawaban IP address yang benar. Proses bertahap ini disebut iterative query, dan hasilnya disimpan sementara di cache resolver agar permintaan berikutnya untuk domain yang sama tidak perlu mengulang seluruh proses dari awal.

Data DNS sendiri disimpan dalam bentuk resource record, masing-masing dengan tipe yang punya fungsi berbeda. Tipe yang paling sering dipakai Sysadmin adalah:

  • A: memetakan nama domain ke IPv4 address.
  • AAAA: memetakan nama domain ke IPv6 address.
  • CNAME: alias, menunjuk satu nama domain ke nama domain lain.
  • MX: menunjuk server mail yang menangani email untuk domain tersebut.
  • NS: menunjuk authoritative nameserver yang mengelola zone.
  • PTR: kebalikan dari A, memetakan IP address kembali ke nama domain (reverse DNS).
  • SOA: Start of Authority, menyimpan metadata zone seperti nomor serial dan interval refresh.
  • TXT: menyimpan teks bebas, sering dipakai untuk verifikasi domain atau kebijakan email seperti SPF.

Bekal konsep ini cukup untuk masuk ke praktik. Bagian selanjutnya akan menunjukkan bagaimana seluruh istilah di atas benar-benar muncul dalam file konfigurasi BIND9 yang sesungguhnya.

9.2 Instalasi dan Konfigurasi BIND9

BIND9 (Berkeley Internet Name Domain, versi 9) adalah software DNS server yang dikembangkan Internet Systems Consortium (ISC) dan menjadi implementasi DNS server paling dominan di lingkungan Linux, termasuk menjadi paket DNS server standar di repository Ubuntu. Sysadmin memakainya baik untuk melayani zone publik yang bisa diakses Visitor dari internet, maupun untuk zone internal yang hanya dipakai Developer dan aplikasi di dalam jaringan kantor.

9.2.1 Instalasi Paket BIND9

Instalasi BIND9 di Ubuntu Server melibatkan beberapa paket pelengkap: bind9 sebagai daemon utama, bind9utils untuk tool bantu seperti validasi konfigurasi, dan bind9-dnsutils yang menyediakan dig serta nslookup untuk pengujian nanti di Bagian 9.3.

Langkah Praktik

  1. Perbarui daftar paket, lalu instal BIND9 beserta tool pendukungnya.
    sudo apt update
sudo apt install bind9 bind9utils bind9-dnsutils
  2. Cek versi BIND9 yang benar-benar terpasang. Selalu verifikasi versi ini secara langsung di server, karena versi paket bisa berbeda antar rilis Ubuntu.
    named -v
dpkg -l bind9
  3. Pastikan service bind9 otomatis berjalan dan aktif saat boot setelah instalasi.
    sudo systemctl status bind9
sudo systemctl enable bind9

Verifikasi dan Troubleshooting

  • Pastikan BIND9 benar-benar mendengarkan di port 53, baik untuk protokol UDP (query DNS biasa) maupun TCP (dipakai untuk zone transfer dan response berukuran besar).
    sudo ss -lntup | grep named
  • Buka port 53 jika server memakai UFW agar client lain di jaringan bisa mengirim query ke server DNS ini.
    sudo ufw allow 53
  • Di lapangan, BIND9 di Ubuntu berjalan di bawah profil AppArmor (lihat Bab 33) yang membatasi direktori mana saja yang boleh diakses proses named. Jika nanti zone file diletakkan di luar /etc/bind/ atau /var/cache/bind/, BIND9 bisa gagal membaca file tersebut dengan pesan permission denied di log meskipun permission Linux biasa sudah benar. Cek journalctl -u bind9 dan /var/log/syslog untuk pesan yang mengarah ke AppArmor jika hal ini terjadi.

9.2.2 Struktur Konfigurasi named.conf

Seluruh konfigurasi BIND9 di Ubuntu berpusat di direktori /etc/bind/. File utamanya adalah named.conf, tetapi isinya hanya berupa tiga baris include yang memecah konfigurasi menjadi tiga file terpisah agar lebih rapi dikelola.

Langkah Praktik

  1. Lihat isi named.conf untuk memahami pembagian filenya.
    cat /etc/bind/named.conf
  2. named.conf.options menyimpan pengaturan global seperti direktori kerja dan forwarder. Buka file ini untuk melihat konfigurasi default-nya.
    sudo nano /etc/bind/named.conf.options
  3. named.conf.local adalah tempat kita mendefinisikan zone milik sendiri, dan biasanya masih kosong (hanya komentar) setelah instalasi baru. File inilah yang paling sering diedit Sysadmin.
    sudo nano /etc/bind/named.conf.local
  4. named.conf.default-zones berisi zone bawaan seperti localhost dan zone reverse untuk 127.0.0.1. Biarkan file ini apa adanya, karena isinya dibutuhkan BIND9 untuk berjalan normal.
    cat /etc/bind/named.conf.default-zones

Selanjutnya kita akan menambahkan zone milik sendiri lewat named.conf.local, dilengkapi zone file yang isinya benar-benar memuat record DNS.

9.2.3 Zone File: Forward dan Reverse

Ada dua arah pemetaan yang perlu dikonfigurasi terpisah. Forward zone memetakan nama domain ke IP address, inilah yang dipakai browser Visitor setiap hari. Reverse zone justru sebaliknya, memetakan IP address kembali ke nama domain lewat record PTR, sering dibutuhkan untuk verifikasi server mail atau keperluan audit jaringan.

Langkah Praktik

  1. Daftarkan forward zone dan reverse zone di named.conf.local. Contoh berikut memakai domain internal example.local dan network 192.168.1.0/24, sesuaikan dengan skema jaringan yang sebenarnya dipakai.
    zone "example.local" {
	type primary;
	file "/etc/bind/db.example.local";
};

zone "1.168.192.in-addr.arpa" {
	type primary;
	file "/etc/bind/db.192";
};
  2. Buat zone file forward dengan menyalin template zone lokal bawaan BIND9 sebagai titik awal.
    sudo cp /etc/bind/db.local /etc/bind/db.example.local
sudo nano /etc/bind/db.example.local
  3. Sesuaikan isinya dengan record yang benar-benar dibutuhkan. Perhatikan tanda titik di akhir nama domain lengkap (Fully Qualified Domain Name/FQDN), penanda penting yang membedakan nama absolut dari nama relatif dalam zone file.
    ;
; BIND data file for example.local
;
$TTL	604800
@	IN	SOA	ns1.example.local. admin.example.local. (
			      3	; Serial
			 604800	; Refresh
			  86400	; Retry
			2419200	; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	ns1.example.local.
@	IN	A	192.168.1.10
ns1	IN	A	192.168.1.10
www	IN	A	192.168.1.20
mail	IN	A	192.168.1.30
	IN	MX	10 mail.example.local.
  4. Buat zone file reverse dengan cara serupa.
    sudo cp /etc/bind/db.127 /etc/bind/db.192
sudo nano /etc/bind/db.192
  5. Isi zone file reverse hanya berisi record PTR, memetakan oktet terakhir IP address ke nama domain.
    ;
; BIND reverse data file for 192.168.1.0/24
;
$TTL	604800
@	IN	SOA	ns1.example.local. admin.example.local. (
			      1	; Serial
			 604800	; Refresh
			  86400	; Retry
			2419200	; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	ns1.example.local.
10	IN	PTR	ns1.example.local.
20	IN	PTR	www.example.local.

Verifikasi dan Troubleshooting

  • Selalu validasi sintaks konfigurasi utama dan zone file sebelum reload, sama seperti kebiasaan netplan generate di Bab 8. Perintah ini menangkap kesalahan sintaks sebelum benar-benar diterapkan.
    sudo named-checkconf
sudo named-checkzone example.local /etc/bind/db.example.local
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192
  • Setelah validasi lolos, reload BIND9 agar zone baru terbaca.
    sudo systemctl reload bind9
  • Kesalahan paling sering di sini adalah lupa mengetik titik di akhir FQDN pada field seperti NS dan MX. BIND9 akan menganggapnya nama relatif dan otomatis menambahkan nama zone di belakangnya jika tanpa titik, sehingga menghasilkan nama domain yang salah tanpa memunculkan error yang jelas.
  • Nomor Serial di record SOA wajib dinaikkan setiap kali zone file diubah. BIND9 memakai nomor ini untuk mendeteksi apakah ada perubahan yang perlu disebarkan ke secondary server, topik yang akan dibahas di bagian berikutnya.

9.2.4 Primary dan Secondary DNS Server

Mengandalkan satu DNS server saja adalah single point of failure: seluruh resolusi nama domain di jaringan ikut lumpuh begitu server itu mati, meskipun server dan aplikasi lain baik-baik saja. Solusinya adalah menjalankan minimal dua server, satu berperan sebagai primary (dulu disebut master) yang menyimpan zone file asli dan menjadi satu-satunya tempat perubahan dilakukan, dan satu lagi sebagai secondary (dulu disebut slave) yang otomatis menyalin data dari primary lewat proses bernama zone transfer.

Langkah Praktik

  1. Di server primary, tambahkan allow-transfer untuk membatasi siapa saja yang boleh menarik salinan zone, dan also-notify agar primary otomatis memberi tahu secondary setiap kali ada perubahan.
    zone "example.local" {
	type primary;
	file "/etc/bind/db.example.local";
	allow-transfer { 192.168.1.11; };
	also-notify { 192.168.1.11; };
};
  2. Instal BIND9 di server kedua dengan langkah yang sama seperti Bagian 9.2.1, lalu definisikan zone yang sama dengan tipe secondary, mengarah ke IP address server primary.
    zone "example.local" {
	type secondary;
	file "/var/cache/bind/db.example.local";
	masters { 192.168.1.10; };
};
  3. Validasi dan reload konfigurasi di server secondary.
    sudo named-checkconf
sudo systemctl reload bind9

Verifikasi dan Troubleshooting

  • Cek apakah zone transfer berhasil dengan melihat file zone yang otomatis dibuat BIND9 di direktori cache server secondary.
    ls -la /var/cache/bind/
sudo named-checkzone example.local /var/cache/bind/db.example.local
  • Jika transfer tidak terjadi, cek log untuk pesan error zone transfer. Hal ini biasanya disebabkan allow-transfer yang salah menuliskan IP secondary, atau firewall yang memblokir port 53 TCP di antara kedua server.
    journalctl -u bind9 -b --no-pager | grep -i transfer
  • Setiap perubahan zone file di primary wajib menaikkan nomor Serial di SOA, lalu jalankan rndc notify example.local di primary jika ingin memaksa secondary segera menarik update tanpa menunggu interval refresh di SOA habis.
  • Di lapangan, pola primary-secondary ini juga yang dipakai penyedia domain publik untuk menjaga DNS tetap terjangkau meski satu datacenter mengalami gangguan. Semakin kritis sebuah zone, semakin penting menempatkan secondary di lokasi jaringan yang benar-benar terpisah dari primary.

9.3 Menguji Resolusi DNS: dig dan nslookup

Konfigurasi zone yang terlihat benar di file belum tentu benar-benar bekerja seperti yang diharapkan. dig (Domain Information Groper) adalah tool andalan Sysadmin untuk menguji resolusi DNS secara detail, sementara nslookup jadi alternatif yang lebih sederhana dan sudah dikenal luas sejak era DNS server lama.

Langkah Praktik

  1. Query domain langsung ke server DNS yang baru dikonfigurasi, tanpa bergantung pada resolver default sistem.
    dig @192.168.1.10 example.local
  2. Pakai opsi +short untuk output yang lebih ringkas saat hanya butuh IP address-nya saja.
    dig @192.168.1.10 example.local +short
  3. Uji resolusi reverse DNS dengan opsi -x, memakai IP address sebagai input.
    dig @192.168.1.10 -x 192.168.1.20
  4. Query tipe record tertentu, misalnya MX untuk mengecek konfigurasi server mail.
    dig @192.168.1.10 example.local MX
  5. Sebagai alternatif, nslookup juga bisa dipakai dengan menyebutkan server DNS secara eksplisit.
    nslookup example.local 192.168.1.10

Verifikasi dan Troubleshooting

  • Perhatikan bagian ANSWER SECTION pada output dig, di situlah record yang benar-benar dikembalikan server ditampilkan. Bagian flags di header juga penting, kemunculan flag aa (authoritative answer) menandakan jawaban datang langsung dari authoritative server, bukan hasil cache resolver lain.
  • Jika dig mengembalikan status NXDOMAIN, domain yang ditanyakan memang tidak terdaftar di zone tersebut, sering disebabkan salah ketik nama domain atau zone belum di-reload setelah diedit.
  • Jika dig mengembalikan status SERVFAIL, biasanya ada masalah di sisi server, misalnya zone file gagal dimuat karena error sintaks yang lolos dari pengecekan awal, atau server tujuan memang tidak menjalankan BIND9 sama sekali. Cek ulang dengan named-checkconf dan named-checkzone di server yang dituju.
  • Bandingkan hasil dig ke server sendiri dengan dig ke resolver publik seperti dig @1.1.1.1 example.com untuk domain publik, sehingga jelas apakah masalah ada di konfigurasi zone sendiri atau memang di sisi jaringan luar.

9.4 Caching DNS Server Sederhana

Tidak semua server DNS perlu menyimpan zone sendiri. Banyak kantor atau jaringan internal hanya butuh satu server DNS lokal yang tugasnya meneruskan query ke resolver publik seperti Cloudflare atau Google, sambil menyimpan hasilnya sementara di cache agar query berikutnya untuk domain yang sama jauh lebih cepat dijawab tanpa perlu keluar jaringan lagi. Konfigurasi seperti ini disebut caching-only server, dan BIND9 bisa menjalankan peran ini tanpa perlu satu zone pun didefinisikan sendiri.

Langkah Praktik

  1. Edit named.conf.options, aktifkan recursion, dan tambahkan forwarder, yaitu resolver lain yang akan diteruskan setiap query yang bukan untuk zone milik sendiri.
    options {
	directory "/var/cache/bind";

	recursion yes;
	allow-recursion { 192.168.1.0/24; localhost; };

	forwarders {
		1.1.1.1;
		8.8.8.8;
	};

	dnssec-validation auto;
	listen-on-v6 { any; };
};
  2. Validasi dan reload konfigurasi seperti biasa.
    sudo named-checkconf
sudo systemctl reload bind9

Verifikasi dan Troubleshooting

  • Bandingkan waktu respons query yang sama dijalankan dua kali berturut-turut. Query pertama harus menempuh proses penuh ke forwarder, sementara query kedua dijawab langsung dari cache lokal dan jauh lebih cepat.
    dig @192.168.1.10 ubuntu.com +noall +stats
dig @192.168.1.10 ubuntu.com +noall +stats
  • Perhatikan nilai Query time di kedua output, penurunan drastis pada query kedua menandakan cache bekerja sebagaimana mestinya.
  • Gunakan rndc flush alih-alih menunggu TTL record habis dengan sendirinya kalau perlu mengosongkan cache secara manual, misalnya saat menguji perubahan DNS di sisi domain publik.
    sudo rndc flush
  • Batasi allow-recursion hanya untuk network internal, jangan pernah dibuka untuk any di server yang juga bisa diakses dari internet. DNS server dengan recursion terbuka ke publik (open resolver) rentan disalahgunakan Attacker sebagai bagian dari serangan DNS amplification, di mana query kecil dipalsukan seolah datang dari korban lalu server ikut membanjiri korban dengan response berukuran jauh lebih besar. Ini salah satu kesalahan konfigurasi DNS paling berbahaya yang wajib dihindari Sysadmin.

Sampai di sini, kita sudah menguasai BIND9 dari konsep dasar DNS, instalasi dan konfigurasi zone forward maupun reverse, skema primary-secondary untuk redundansi, cara menguji resolusi dengan dig dan nslookup, hingga konfigurasi caching server yang aman. Bab 10 akan melanjutkan pembahasan jaringan dengan DHCP server, termasuk cara mengintegrasikannya dengan DNS yang baru saja kita bangun di bab ini.

Share

Previous

Konfigurasi Jaringan dengan Netplan

Next

DHCP Server