Finally upgrading from isc-dhcp-server to isc-kea for my homelab

Broken down that way, the migration didn’t look very daunting – and it’s made easier by the fact that the default Kea configuration files are filled with descriptive comments and configuration examples to pull from. (And again, ISC has one excellent work with the documents for Kea. All versions, from legacy to advanced, have thorough and extensive online documentation if you’re curious about what a particular option does or where you can apply it. And, as mentioned above, there are also the included sample configuration files to take apart. if you want more detailed examples.)

Configuration time for DHCP

We need to configure two Kea applications, so we’ll do DHCP first and then move to the DDNS side. (Although the DHCP configuration file also contains a bunch of DDNS stuff, so if we’re being pedantic, I think we’ll set both at the same time.)

The first file you need to edit, if you installed Kea via package manager, is /etc/kea/kea-dhcp4.conf. The file should already contain some pretty reasonable defaults, and it’s worth taking a moment to look through the comments and see what those defaults are and what they mean.

Here is a slightly cleaned up version of my work kea-dhcp4.conf file:

{
  "Dhcp4": {
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/tmp/kea4-ctrl-socket"
    },
    "interfaces-config": {
      "interfaces": ["eth0"],
      "dhcp-socket-type": "raw"
    },
    "dhcp-ddns": {
      "enable-updates": true
    },
    "ddns-conflict-resolution-mode": "no-check-with-dhcid",
    "ddns-override-client-update": true,
    "ddns-override-no-update": true,
    "ddns-qualifying-suffix": "bigdinosaur.lan",
    "authoritative": true,
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "expired-leases-processing": {
      "reclaim-timer-wait-time": 3600,
      "hold-reclaimed-time": 3600,
      "max-reclaim-leases": 0,
      "max-reclaim-time": 0
    },
    "loggers": [
    {
      "name": "kea-dhcp4",
      "output_options": [
        {
          "output": "syslog",
          "pattern": "%-5p %m\n",
          "maxsize": 1048576,
          "maxver": 8
        }
      ],
      "severity": "INFO",
      "debuglevel": 0
      }
    ],
    "reservations-global": false,
    "reservations-in-subnet": true,
    "reservations-out-of-pool": true,
    "host-reservation-identifiers": [
      "hw-address"
    ],
    "subnet4": [
      {
        "id": 1,
        "subnet": "10.10.10.0/24",
        "pools": [
          {
            "pool": "10.10.10.170 - 10.10.10.254"
          }
        ],
        "option-data": [
          {
            "name": "subnet-mask",
            "data": "255.255.255.0"
          },
          {
            "name": "routers",
            "data": "10.10.10.1"
          },
          {
            "name": "broadcast-address",
            "data": "10.10.10.255"
          },
          {
            "name": "domain-name-servers",
            "data": "10.10.10.53"
          },
          {
            "name": "domain-name",
            "data": "bigdinosaur.lan"
          }
        ],
        "reservations": [
          {
            "hostname": "host1.bigdinosaur.lan",
            "hw-address": "aa:bb:cc:dd:ee:ff",
            "ip-address": "10.10.10.100"
          },
          {
            "hostname": "host2.bigdinosaur.lan",
            "hw-address": "ff:ee:dd:cc:bb:aa",
            "ip-address": "10.10.10.101"
          }
        ]
      }
    ]
  }
}

The first stanza sets up the control socket on which the DHCP process listens for management API commands (we’re not going to set up the management tool, which is overkill for a home lab, but this will ensure that the socket exists if you ever decide to go that way). They also set up the interface where Kea listens for DHCP requests, and they tell Kea to listen for those requests in raw socket mode. You almost certainly want that raw as your DHCP socket type (see why here), but this can also be set udp if necessary.