DNS (Domain Name System) merupakan salah satu layanan paling kritis dalam infrastruktur jaringan modern. Hampir seluruh aplikasi, website, layanan cloud, sistem monitoring, email server, hingga layanan internal perusahaan bergantung pada DNS untuk melakukan resolusi nama menjadi alamat IP.
Masalah akan muncul ketika hanya terdapat satu DNS Server yang berfungsi sebagai sumber informasi. Jika server tersebut mengalami gangguan, kegagalan perangkat keras, kerusakan sistem operasi, atau gangguan jaringan, maka seluruh layanan yang bergantung pada DNS dapat ikut terdampak.
Karena itulah implementasi DNS Redundancy menjadi kebutuhan penting pada lingkungan produksi. Salah satu metode yang paling umum digunakan adalah membangun arsitektur Primary DNS dan Secondary DNS menggunakan Bind9 dengan mekanisme Zone Transfer AXFR dan IXFR.
Pada Ubuntu Server 26.04 LTS “Resolute Raccoon”, Bind9 tetap menjadi salah satu DNS Server paling stabil, fleksibel, dan banyak digunakan di lingkungan enterprise, data center, kampus, cloud infrastructure, hingga ISP.
Artikel ini membahas tips dan best practice membangun DNS Server redundant menggunakan Bind9 berdasarkan pengalaman implementasi pada lingkungan server berskala besar yang mengelola ribuan virtual machine, layanan akademik, cluster aplikasi, dan berbagai sistem kritikal lainnya.
Mengapa DNS Redundancy Sangat Penting?
Bayangkan DNS sebagai buku telepon internet.
Ketika pengguna mengakses:
portal.kampus.ac.id
DNS akan menerjemahkan nama tersebut menjadi alamat IP server tujuan.
Jika DNS tidak tersedia maka:
- Website tidak dapat diakses
- Email gagal dikirim
- Sistem monitoring mengalami error
- Aplikasi internal tidak dapat melakukan komunikasi
- Kubernetes dan container service mengalami gangguan discovery
Oleh karena itu DNS harus memiliki:
- High Availability
- Redundancy
- Konsistensi data
- Sinkronisasi otomatis
Mengenal Arsitektur Primary dan Secondary DNS
Primary DNS Server
Primary DNS merupakan server utama yang menyimpan dan mengelola file zona secara langsung.
Contoh:
ns1.domain.local
192.168.10.10
Fungsi:
- Menyimpan file zona
- Menjadi sumber perubahan DNS
- Melayani query DNS
Secondary DNS Server
Secondary DNS memperoleh salinan zona dari Primary melalui mekanisme Zone Transfer.
Contoh:
ns2.domain.local
192.168.10.11
Fungsi:
- Backup DNS
- Melayani query ketika Primary gagal
- Mengurangi beban query Primary
Apa Itu Zone Transfer?
Zone Transfer adalah proses sinkronisasi data zona DNS dari Primary ke Secondary.
Tujuan utamanya:
- Menjaga konsistensi data
- Menghindari konfigurasi manual berulang
- Memastikan seluruh server DNS memiliki informasi yang sama
Pada Bind9 terdapat dua metode utama:
AXFR
Authoritative Zone Transfer
Transfer seluruh isi zona.
IXFR
Incremental Zone Transfer
Transfer hanya perubahan yang terjadi.
Perbedaan AXFR dan IXFR
| Parameter | AXFR | IXFR |
|---|---|---|
| Data Transfer | Full Zone | Incremental |
| Bandwidth | Lebih besar | Lebih kecil |
| Kecepatan | Lebih lambat | Lebih cepat |
| Efisiensi | Rendah | Tinggi |
| Cocok untuk | Zona kecil | Zona besar |
Pada lingkungan kampus dengan ribuan record DNS, IXFR jauh lebih efisien dibandingkan AXFR.
Topologi DNS Redundant
Infrastruktur
Primary DNS
192.168.10.10
Secondary DNS
192.168.10.11
Zona:
kampus.local
Client:
DNS1 = 192.168.10.10
DNS2 = 192.168.10.11
Instalasi Bind9 Ubuntu Server 26.04 LTS
Update Sistem
sudo apt update
sudo apt upgrade -y
Install Bind9
sudo apt install bind9 bind9utils bind9-doc -y
Verifikasi:
named -v
Konfigurasi Primary DNS
Edit:
sudo nano /etc/bind/named.conf.local
Tambahkan:
zone "kampus.local" {
type master;
file "/etc/bind/db.kampus.local";
allow-transfer {
192.168.10.11;
};
also-notify {
192.168.10.11;
};
};
Membuat File Zona
sudo cp /etc/bind/db.local /etc/bind/db.kampus.local
Edit:
sudo nano /etc/bind/db.kampus.local
Contoh:
$TTL 86400
@ IN SOA ns1.kampus.local. admin.kampus.local. (
2026070301
3600
1800
604800
86400
)
@ IN NS ns1.kampus.local.
@ IN NS ns2.kampus.local.
ns1 IN A 192.168.10.10
ns2 IN A 192.168.10.11
www IN A 192.168.10.100
mail IN A 192.168.10.101
Konfigurasi Secondary DNS
Edit:
sudo nano /etc/bind/named.conf.local
Tambahkan:
zone "kampus.local" {
type slave;
file "/var/cache/bind/db.kampus.local";
masters {
192.168.10.10;
};
};
Restart:
sudo systemctl restart bind9
Cara Kerja AXFR
Ketika Secondary pertama kali aktif:
ns2 → meminta zona
ns1 → mengirim seluruh file zona
Proses:
PRIMARY
|
| AXFR
|
SECONDARY
Seluruh record DNS dikirim ulang.
Cara Kerja IXFR
Ketika terdapat perubahan:
Misalnya:
vpn IN A 192.168.10.200
Administrator hanya menaikkan serial number:
2026070302
Secondary akan meminta perubahan:
ns2 → IXFR Request
ns1 → hanya kirim perubahan
Hasil:
- Sinkronisasi lebih cepat
- Hemat bandwidth
- Beban server lebih rendah
Best Practice Penggunaan Serial Number
Kesalahan paling umum adalah lupa menaikkan serial number.
Gunakan format:
YYYYMMDDNN
Contoh:
2026070301
2026070302
2026070303
Keuntungan:
- Mudah dilacak
- Mudah diaudit
- Menghindari konflik replikasi
Mengamankan Zone Transfer
Jangan pernah membuka transfer untuk semua host.
Salah:
allow-transfer { any; };
Benar:
allow-transfer {
192.168.10.11;
};
Lebih aman lagi menggunakan TSIG.
Menggunakan TSIG Authentication
Generate key:
tsig-keygen dns-transfer
Contoh hasil:
key "dns-transfer" {
algorithm hmac-sha256;
secret "xxxxxxxx";
};
Tambahkan pada kedua server.
Keuntungan:
- Transfer terenkripsi
- Hanya server yang memiliki key dapat melakukan transfer
- Mencegah pencurian informasi DNS
Monitoring Sinkronisasi DNS
Verifikasi zona:
rndc zonestatus kampus.local
Melihat log:
journalctl -u bind9 -f
Verifikasi transfer:
grep transfer /var/log/syslog
Studi Kasus Lingkungan Kampus
Pada lingkungan kampus besar biasanya terdapat:
- Portal Akademik
- LMS Moodle
- Email Server
- Repository
- Sistem Keuangan
- Cluster Kubernetes
- Sistem Monitoring
Jumlah record DNS bisa mencapai ribuan.
Jika menggunakan AXFR penuh setiap perubahan:
- Bandwidth meningkat
- Sinkronisasi lebih lambat
Solusi:
- Aktifkan IXFR
- Gunakan TSIG
- Tambahkan Secondary DNS berbeda lokasi
- Monitoring status transfer
Kesalahan yang Sering Terjadi
Tidak Menaikkan Serial Number
Dampak:
- Zona tidak tersinkronisasi
Solusi:
- Selalu update serial setiap perubahan
Firewall Memblokir TCP 53
Dampak:
- AXFR gagal
Solusi:
sudo ufw allow 53/tcp
sudo ufw allow 53/udp
Salah Konfigurasi Allow Transfer
Dampak:
- Secondary gagal menerima zona
Solusi:
- Verifikasi IP Secondary
Zona Terlalu Besar Menggunakan AXFR
Dampak:
- Transfer lambat
Solusi:
- Gunakan IXFR
Tips Profesional untuk Infrastruktur Produksi
Minimal Dua DNS Authoritative
Ideal:
DNS Primary
DNS Secondary
Lebih baik:
DNS Primary
DNS Secondary Site A
DNS Secondary Site B
Pisahkan Lokasi Fisik
Jangan menempatkan seluruh DNS pada satu rack atau satu hypervisor.
Gunakan Monitoring
Implementasikan:
- Prometheus
- Grafana
- Zabbix
- Icinga2
Untuk memonitor:
- Query rate
- Transfer status
- Resource server
Backup Zona Otomatis
Contoh:
rsync
git repository
snapshot VM
Audit Berkala
Periksa:
- Record usang
- Zona tidak digunakan
- NS record invalid
- Transfer error
Kesimpulan
Membangun DNS Server redundant menggunakan Bind9 pada Ubuntu Server 26.04 LTS merupakan langkah penting untuk meningkatkan ketersediaan layanan jaringan. Dengan menerapkan arsitektur Primary-Secondary dan memanfaatkan mekanisme AXFR maupun IXFR, administrator dapat menjaga konsistensi data DNS secara otomatis sekaligus meningkatkan ketahanan infrastruktur terhadap kegagalan server.
Untuk lingkungan kecil, AXFR masih cukup memadai. Namun pada lingkungan enterprise, kampus, ISP, data center, maupun cluster cloud yang memiliki ribuan record DNS, IXFR menjadi pilihan yang jauh lebih efisien karena hanya mengirim perubahan data yang diperlukan.
Kombinasikan implementasi tersebut dengan TSIG Authentication, monitoring berkelanjutan, backup berkala, dan penempatan server pada lokasi berbeda agar sistem DNS tetap aman, cepat, dan andal dalam jangka panjang.
FAQ
Pertanyaan: Apa perbedaan utama AXFR dan IXFR?
Jawaban: AXFR mentransfer seluruh zona DNS, sedangkan IXFR hanya mentransfer perubahan yang terjadi sejak sinkronisasi terakhir.
Pertanyaan: Apakah Secondary DNS dapat melayani query ketika Primary DNS mati?
Jawaban: Ya. Secondary DNS tetap dapat menjawab query karena memiliki salinan zona yang lengkap.
Pertanyaan: Mengapa serial number SOA harus dinaikkan?
Jawaban: Karena Secondary DNS menggunakan serial number untuk mendeteksi adanya perubahan zona.
Pertanyaan: Apakah zone transfer perlu diamankan?
Jawaban: Sangat perlu. Gunakan allow-transfer yang spesifik dan TSIG Authentication untuk mencegah akses tidak sah.
Pertanyaan: Kapan sebaiknya menggunakan IXFR?
Jawaban: Saat jumlah record DNS besar dan perubahan zona cukup sering sehingga sinkronisasi menjadi lebih efisien.
Pertanyaan: Port apa yang digunakan untuk zone transfer?
Jawaban: Zone transfer menggunakan protokol TCP port 53, berbeda dengan sebagian besar query DNS yang menggunakan UDP port 53.
Tertarik menerapkan DNS Server redundant menggunakan Bind9 di Ubuntu Server 26.04 LTS? Bagikan pengalaman, kendala, atau strategi yang Anda gunakan pada kolom komentar.
Jika artikel ini bermanfaat, jangan lupa membagikannya kepada rekan sysadmin, network administrator, maupun praktisi infrastruktur IT lainnya. Kunjungi juga artikel terkait seputar Linux Server, High Availability, Cloud Computing, Cybersecurity, dan Administrasi Jaringan untuk mendapatkan panduan teknis terbaru dan praktik terbaik di lingkungan produksi.
