When analyzed this way, the transition wasn’t so scary. Kea’s default configuration files are filled with explanatory comments and helpful configuration examples, making migration easier. (And again, ISC has done a great job with Kea’s documentation. If you want to know what a particular option does or where it applies, check out all versions, from deprecated to the latest.) We have thorough and extensive online documentation, and as mentioned above, we also provide a sample configuration file that you can disassemble if you need a more detailed example).
DHCP configuration time
There are two Kea applications to configure, so we’ll run DHCP first and then move on to the DDNS side. (However, the DHCP configuration file also includes a lot of stuff for DDNS, so if you’re being pedantic, you’re probably configuring both at once.)
If you installed Kea via a package manager, the first file to edit is /etc/kea/kea-dhcp4.conf. The file should already contain some reasonable defaults. It’s worth looking through the comments to see what those defaults are and what they mean.
This is a lightly sanitized version of the working 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 , “Reservation within subnet”: true, “Reservation outside pool”: true, “Host reservation identifier”: ( “hw-address” ), “subnet4”: ( { “id”: 1 , “subnet”: ” 10.10.10.0/24″, “pool”: ( { “pool”: “10.10.10.170 – 10.10.10.254” } ), “optional data”: ( { “name”: “subnet-mask”, “data”: “255.255.255.0” }, { “name”: “router”, “data”: “10.10.10.1” }, { “name”: “broadcast address”, “data”: ” 10.10.10.255″ }, { ” name”: “domain name server”, “data”: “10.10.10.53” }, { “name”: “domain name”, “data”: “bigdinosaur.lan” } ), “reservation”: ( { “host name”: “host1.bigdinosaur.lan”, “hw-address”: “aa:bb:cc:dd:ee:ff”, “ip-address”: “10.10. 10.100” }, { “hostname”: “host2.bigdinosaur.lan”, “hardware address”: “ff:ee:dd:cc:bb:aa”, “ip address”: “10.10.10.101” } ) } ) } }
The first stanza sets up a control socket on which the DHCP process listens for management API commands (I’m not looking to set up a management tool; this is overkill for a home lab, but this ensures that the socket exists if needed). Please move in that direction). We also configure the interface on which Kea listens for DHCP requests and instruct Kea to listen for these requests in raw socket mode. You should almost certainly use raw as your DHCP socket type (see here for why), but you can also set it to udp if you prefer.
