Bitnesia
DHCP Server

Part of a series

Linux 102: Administrasi Server dengan Ubuntu

DHCP Server

Bitnesia • Aug 26, 2026 2 •EN

Seorang Sysadmin yang mengurus jaringan kantor dengan lima puluh laptop Developer, beberapa printer, dan puluhan perangkat User lain menghadapi kenyataan bahwa perangkat-perangkat itu terhubung dan terputus setiap hari. Memberi IP address ke masing-masing perangkat secara manual satu per satu bukan cuma melelahkan, tetapi juga rawan human error, misalnya dua perangkat kebagian IP address yang sama lalu saling bentrok di jaringan. Di sinilah DHCP (Dynamic Host Configuration Protocol) mengambil alih tugas tersebut secara otomatis dengan memberikan konfigurasi jaringan yang benar kepada setiap perangkat yang terhubung tanpa campur tangan manual sama sekali.

Bab ini melanjutkan pembahasan jaringan dari Bab 9 serta menutup rangkaian materi DNS-DHCP sebagai dua layanan inti yang hampir selalu berjalan berdampingan di jaringan mana pun. Kita akan mulai dari konsep DHCP dan lease, lanjut ke instalasi dan konfigurasi DHCP server modern, reservasi IP berdasarkan MAC address untuk perangkat yang butuh alamat tetap, dan menutup dengan konsep integrasi DHCP ke DNS lewat dynamic DNS update.

10.1 Konsep DHCP dan Lease

DHCP adalah protokol jaringan yang secara otomatis memberikan konfigurasi IP address, subnet mask, default gateway, dan DNS server ke perangkat yang baru terhubung ke jaringan. Alih-alih Sysadmin mengetik konfigurasi IP satu per satu pada tiap laptop Developer atau perangkat User, DHCP server menyimpan dan membagikan konfigurasi tersebut secara terpusat dari satu tempat.

Konsep paling penting yang perlu kita pahami di sini adalah lease. DHCP server tidak memberi client hak milik permanen atas IP address, melainkan hanya "meminjamkannya" untuk jangka waktu tertentu. Sebelum masa pinjam tersebut habis, client wajib memperbarui (renew) permintaannya jika masih ingin menggunakan IP address yang sama. Jika tidak, IP address tersebut kembali ke pool dan perangkat lain bisa memakainya lagi. Skema ini penting terutama pada jaringan dengan banyak perangkat yang terhubung dan terputus secara dinamis, seperti laptop User yang aktif dan nonaktif atau perangkat tamu di jaringan Wi-Fi kantor.

Proses pemberian IP address ini terjadi lewat empat tahap yang dikenal dengan singkatan DORA:

  • Discover: client yang baru menyala mengirimkan broadcast ke seluruh jaringan untuk mencari DHCP server yang aktif.
  • Offer: DHCP server yang menerima permintaan tersebut membalas dengan penawaran satu IP address dari pool yang tersedia.
  • Request: client memilih salah satu penawaran (biasanya yang pertama diterima) dan secara resmi memintanya.
  • Acknowledge: DHCP server mengonfirmasi pemberian IP address tersebut sekaligus mengirimkan parameter tambahan, seperti gateway dan DNS server.

Seluruh proses DORA ini berjalan di atas UDP, dengan DHCP server mendengarkan di port 67 dan client mendengarkan balasan di port 68. Menurut dokumentasi resmi Ubuntu Server, kita bisa mengombinasikan tiga skema alokasi alamat berikut sesuai kebutuhan jaringan:

  • Dynamic allocation: DHCP server memberikan IP address dari sebuah pool untuk jangka waktu lease tertentu, lalu menariknya kembali ke pool setelah lease habis atau client meninggalkan jaringan. Sysadmin paling sering memakai skema ini untuk laptop User dan perangkat tamu.
  • Manual allocation: DHCP server mengenali MAC address tiap perangkat dan selalu memberikan IP address yang sama untuk perangkat tersebut, meskipun tetap melalui mekanisme DHCP. Bagian 10.3 memakai skema ini untuk reservasi IP, cocok untuk printer atau server internal yang butuh alamat konsisten.
  • Automatic allocation: mirip dynamic allocation, tetapi begitu DHCP server memberi satu perangkat sebuah IP address, perangkat itu cenderung terus memakai IP address yang sama untuk jangka waktu sangat lama atau tanpa batas.

Pemahaman konsep ini sudah cukup sebagai bekal untuk melangkah ke praktik instalasi. Satu hal penting yang perlu kita perjelas dulu adalah paket DHCP server mana yang relevan dipakai di Ubuntu Server 26.04 LTS.

10.2 Instalasi dan Konfigurasi DHCP Server dengan Kea

Banyak kursus dan tutorial DHCP di Linux masih mengarahkan pembaca langsung ke isc-dhcp-server. Selama bertahun-tahun, paket tersebut memang menjadi standar DHCP server di dunia Linux. Namun, Sysadmin wajib tahu satu perkembangan penting sebelum menginstal paket apa pun: ISC (Internet Systems Consortium) selaku pengembang isc-dhcp-server telah resmi menyatakan perangkat lunak tersebut end-of-life sejak Oktober 2022 dan tidak lagi dikembangkan. Menindaklanjuti keputusan tersebut, Ubuntu menandai paket isc-dhcp-server sebagai deprecated dan tidak lagi didukung sejak rilis Ubuntu 24.04 LTS, sehingga statusnya tetap sama pada versi 26.04 LTS.

Ubuntu merekomendasikan Kea, DHCP server buatan ISC sendiri, sebagai pengganti resminya. Kea didesain lebih modern: konfigurasi berbasis JSON, mendukung REST API untuk manajemen, dan mendukung rekonfigurasi tanpa perlu restart penuh. Oleh karena itu, bab ini memakai Kea sebagai DHCP server, bukan isc-dhcp-server yang masih banyak disebut di referensi lama. Sysadmin yang menemukan tutorial isc-dhcp-server di internet perlu menyadari bahwa panduan tersebut mengacu pada perangkat lunak yang sudah tidak dipelihara.

10.2.1 Instalasi Paket Kea

Pada Ubuntu Server, kea merupakan metapackage yang memuat seluruh komponen Kea sekaligus: kea-dhcp4-server untuk layanan DHCPv4, kea-dhcp6-server untuk DHCPv6, kea-ctrl-agent sebagai REST API manajemen, kea-dhcp-ddns-server untuk pembaruan DNS otomatis yang dibahas di Bagian 10.4, serta kea-admin sebagai alat administrasi database lease.

Langkah Praktik

  1. Perbarui daftar paket, lalu instal Kea.
    sudo apt update
sudo apt install kea
  2. Proses instalasi akan menampilkan dialog untuk membuat password autentikasi kea-ctrl-agent. Simpan password ini dengan baik karena kita akan memakainya setiap kali mengakses REST API Kea. Password tersimpan di /etc/kea/kea-api-password dengan permission ketat, hanya root dan group _kea yang bisa membacanya.
  3. Periksa versi Kea yang terpasang. Selalu verifikasi versi ini langsung di server karena versi paket dapat berbeda antar-rilis Ubuntu.
    kea-dhcp4 -v
dpkg -l kea
  4. Bab ini berfokus pada DHCPv4, sehingga pastikan kea-dhcp4-server berjalan otomatis dan aktif saat proses boot.
    sudo systemctl status kea-dhcp4-server
sudo systemctl enable kea-dhcp4-server
  5. Jika jaringan yang dikelola belum membutuhkan DHCPv6, nonaktifkan layanan tersebut agar tidak menambah attack surface tanpa manfaat.
    sudo systemctl disable --now kea-dhcp6-server

Verifikasi dan Troubleshooting

  • Pastikan kea-dhcp4-server mendengarkan permintaan DHCP di port 67/UDP.
    sudo ss -lnup | grep kea-dhcp4
  • Buka port 67/UDP pada UFW agar client di jaringan dapat mengirimkan permintaan DHCP ke server ini.
    sudo ufw allow 67/udp
  • Di lapangan, kesalahan yang paling sering terjadi pada tahap ini bukan mengenai instalasi, melainkan mengenai topologi jaringan. Jangan pernah mengaktifkan DHCP server baru secara langsung di jaringan produksi yang telah memiliki DHCP server aktif lainnya (misalnya router rumah atau kantor). Dua DHCP server yang aktif bersamaan dalam satu broadcast domain akan merespons permintaan client secara bersamaan, sehingga memicu konflik IP address yang membingungkan dan sulit dilacak. Uji dulu di jaringan laboratorium atau VLAN terisolasi sebelum memakainya di lingkungan produksi.

10.2.2 Struktur Konfigurasi kea-dhcp4.conf

Berbeda dengan BIND9 yang menggunakan sintaks konfigurasi khasnya sendiri, Kea menggunakan format JSON untuk seluruh file konfigurasinya. File utama layanan DHCPv4 berada di /etc/kea/kea-dhcp4.conf, dan seluruh konfigurasi berada di dalam satu objek besar bernama Dhcp4.

Langkah Praktik

  1. Lihat isi bawaan (default) kea-dhcp4.conf sebelum diubah untuk memahami kerangka dasarnya.
    cat /etc/kea/kea-dhcp4.conf
  2. Perhatikan beberapa key penting yang telah ada secara default:
    {
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth0" ]
    },
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
      "type": "memfile",
      "lfc-interval": 3600
    },
    "valid-lifetime": 600,
    "max-valid-lifetime": 7200
  }
}
    interfaces-config menentukan interface jaringan tempat Kea mendengarkan permintaan DHCP. Sesuaikan nilainya dengan nama interface server yang sebenarnya (periksa menggunakan ip a). lease-database bertipe memfile berarti Kea menyimpan data lease sebagai file CSV lokal, cukup untuk sebagian besar jaringan skala kecil hingga menengah tanpa perlu database eksternal. valid-lifetime merupakan durasi lease dalam satuan detik. Nilai 600 detik pada contoh ini hanya cocok untuk pengujian, sedangkan jaringan produksi biasanya menggunakan nilai yang jauh lebih panjang, seperti 43200 (12 jam) atau 86400 (24 jam).

Verifikasi dan Troubleshooting

  • Kesalahan yang paling umum terjadi pada file JSON adalah ketidakseimbangan tanda kurung kurawal atau tanda koma. Kea menolak konfigurasi yang salah sintaks, dan kita akan memvalidasinya secara eksplisit di Bagian 10.2.3 sebelum menerapkannya.
  • Kita bisa melihat langsung data lease yang tersimpan untuk audit siapa saja yang pernah mendapat IP address dari server ini.
    cat /var/lib/kea/kea-leases4.csv

10.2.3 Subnet, Pool, dan Opsi Jaringan

Konfigurasi default belum mendefinisikan jaringan yang akan dilayani. Bagian subnet4 merupakan tempat untuk mendefinisikan network, rentang IP address yang dapat dibagikan (pool), serta opsi tambahan seperti gateway dan DNS server yang dikirimkan ke client.

Langkah Praktik

  1. Tambahkan blok subnet4 ke dalam kea-dhcp4.conf. Contoh berikut menggunakan network 192.168.1.0/24 dengan pool dinamis dari .100 hingga .200. Sesuaikan konfigurasi tersebut dengan skema jaringan yang digunakan.
    sudo nano /etc/kea/kea-dhcp4.conf
    {
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth0" ]
    },
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
      "type": "memfile",
      "lfc-interval": 3600
    },
    "valid-lifetime": 43200,
    "max-valid-lifetime": 86400,
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.1.0/24",
        "pools": [
          { "pool": "192.168.1.100 - 192.168.1.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.1.1" },
          { "name": "domain-name-servers", "data": "192.168.1.10" },
          { "name": "domain-name", "data": "example.local" }
        ]
      }
    ]
  }
}
    Opsi routers menentukan default gateway, sedangkan domain-name-servers mengarah ke DNS server internal yang telah dibangun pada Bab 9. Hal ini membuat client secara otomatis menggunakan DNS server internal, bukan resolver publik.
  2. Validasi sintaks konfigurasi ini sebelum kita terapkan. Kebiasaan ini sama pentingnya dengan menjalankan named-checkconf pada BIND9 atau netplan generate pada Bab 8.
    sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
  3. Setelah validasi berhasil tanpa muncul baris Error encountered, restart kea-dhcp4-server agar Kea menerapkan konfigurasi barunya.
    sudo systemctl restart kea-dhcp4-server

Verifikasi dan Troubleshooting

  • Pantau log Kea saat client mulai meminta IP address untuk memastikan proses DORA berjalan dengan benar.
    journalctl -u kea-dhcp4-server -f
  • Dari sisi client (misalnya laptop Developer yang dihubungkan ke jaringan uji), perbarui permintaan lease DHCP dan periksa IP address yang diperoleh.
    sudo dhclient -r eth0
sudo dhclient eth0
ip a show eth0
  • Periksa lease yang tercatat pada server untuk memastikan IP address berasal dari pool yang baru dikonfigurasi.
    cat /var/lib/kea/kea-leases4.csv
  • Jika client tidak kunjung mendapatkan IP address, penyebab yang paling sering terjadi adalah kesalahan penulisan nama interface pada interfaces-config, ketidaksesuaian dengan interface fisik server, atau port 67/UDP pada UFW belum dibuka seperti yang dijelaskan pada Bagian 10.2.1.

10.3 Reservasi IP Berdasarkan MAC Address

Pool dinamis cocok untuk laptop User yang bisa berganti IP address kapan saja. Namun, sejumlah perangkat justru butuh IP address tetap setiap kali dinyalakan, seperti printer kantor, server internal, atau perangkat Network Attached Storage. Daripada mengonfigurasi IP static secara manual pada setiap perangkat tersebut, Sysadmin bisa membuat reservasi pada DHCP server. Perangkat tetap meminta IP melalui DHCP seperti biasa, tetapi server selalu merespons dengan IP address yang sama berdasarkan MAC address perangkat tersebut.

Langkah Praktik

  1. Cari tahu MAC address perangkat yang ingin direservasi dengan menjalankan perintah langsung pada perangkat tersebut.
    ip link show eth0
  2. Tambahkan array reservations di dalam blok subnet4 yang relevan. Pilih IP address di luar rentang pool dinamis (misalnya 192.168.1.50 di luar rentang 100-200 yang telah didefinisikan sebelumnya) agar tidak terjadi konflik dengan alokasi dinamis.
    {
  "Dhcp4": {
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.1.0/24",
        "pools": [
          { "pool": "192.168.1.100 - 192.168.1.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.168.1.1" },
          { "name": "domain-name-servers", "data": "192.168.1.10" }
        ],
        "reservations": [
          {
            "hw-address": "aa:bb:cc:dd:ee:01",
            "ip-address": "192.168.1.50",
            "hostname": "printer-lantai2"
          }
        ]
      }
    ]
  }
}
  3. Lakukan validasi, lalu restart Kea seperti biasa.
    sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl restart kea-dhcp4-server

Verifikasi dan Troubleshooting

  • Minta perangkat dengan MAC address tersebut memperbarui lease, lalu pastikan IP address yang diperoleh sesuai dengan reservasi.
    sudo dhclient -r eth0
sudo dhclient eth0
ip a show eth0
  • Jika IP address yang diperoleh masih berasal dari pool dinamis dan bukan dari reservasi, periksa kembali penulisan hw-address. Format MAC address yang salah (seperti kesalahan tanda pemisah atau ketidaksesuaian penggunaan huruf besar dan kecil dengan pencatatan Kea) menyebabkan reservasi tidak cocok. Akibatnya, Kea secara otomatis memberikan IP address dari pool seolah-olah tidak ada reservasi.
  • Selalu tempatkan IP address hasil reservasi di luar rentang pool dinamis seperti pada contoh di atas. Jika reservasi berada di dalam rentang pool, Kea berisiko lebih dulu meminjamkan IP address itu ke perangkat lain sebelum perangkat pemilik reservasi sempat terhubung, terutama di jaringan dengan lalu lintas padat.

10.4 Integrasi DHCP dengan DNS: Konsep Dynamic DNS Update

Hingga bagian ini, DHCP dan DNS masih berjalan sebagai dua layanan terpisah: DHCP membagikan IP address, sedangkan Sysadmin masih mengisi zone file DNS di Bab 9 secara manual. Masalahnya, kalau ada laptop Developer yang IP address-nya berubah lewat pool dinamis, catatan DNS untuk perangkat itu cepat basi kalau Sysadmin harus memperbaruinya manual setiap kali lease berganti.

Dynamic DNS update (didefinisikan dalam RFC 2136) mengatasi masalah ini dengan membiarkan DHCP server otomatis memberi tahu DNS server setiap kali ia memberikan atau mencabut sebuah lease, sehingga record A dan PTR di zone DNS ikut ter-update otomatis tanpa campur tangan manual. Pada ekosistem Kea, komponen yang menjalankan peran ini disebut kea-dhcp-ddns-server (sering disingkat D2), yang sudah ikut terpasang sebagai bagian dari metapackage kea pada Bagian 10.2.1.

Secara garis besar, alurnya adalah sebagai berikut: setiap kali kea-dhcp4-server memberikan atau mencabut lease, layanan tersebut mengirimkan permintaan perubahan (disebut NameChangeRequest) ke D2. D2 kemudian menyusun pembaruan DNS yang sesuai dan mengirimkannya ke BIND9 dari Bab 9. Supaya BIND9 tidak menerima pembaruan dari pihak yang tidak berhak, Sysadmin mengamankan komunikasi ini dengan TSIG (Transaction Signature), kunci rahasia bersama yang membuat BIND9 hanya memercayai pembaruan yang benar-benar datang dari D2 yang sah.

Di sisi Kea, kita bisa mengaktifkan pengiriman pembaruan ini dan menentukan akhiran domain yang dipakai dengan menambahkan blok berikut ke kea-dhcp4.conf:

{
  "Dhcp4": {
    "dhcp-ddns": {
      "enable-updates": true
    },
    "ddns-qualifying-suffix": "example.local"
  }
}

Konfigurasi lengkap melibatkan pembuatan TSIG key, penyesuaian named.conf pada sisi BIND9 agar mengizinkan pembaruan dari key tersebut, serta konfigurasi kea-dhcp-ddns-server itu sendiri. Topik ini cukup panjang dan berada di luar cakupan bab ini. Poin terpenting yang perlu kita pahami di level konsep: integrasi DHCP-DNS bukan proses otomatis tanpa syarat, melainkan hasil dari dua layanan yang saling percaya lewat mekanisme autentikasi yang jelas. Pemahaman mengenai trust relationship semacam ini sangat berguna saat Sysadmin berurusan dengan otomasi infrastruktur yang lebih luas.

Sampai di sini, kita sudah menguasai DHCP dari konsep dasar dan proses DORA, alasan pemilihan Kea menggantikan isc-dhcp-server yang sudah deprecated, instalasi dan konfigurasi subnet beserta pool, reservasi IP berdasarkan MAC address, hingga gambaran konsep integrasi dengan DNS lewat dynamic update. Bab 11 akan membahas topik jaringan lain yang sering luput dari perhatian tetapi krusial bagi layanan seperti DHCP dan DNS, yaitu sinkronisasi waktu menggunakan chrony.

Share

Previous

DNS Server dengan BIND9

Next

Sinkronisasi Waktu