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

As an Amazon Associate I earn from qualifying purchases.

Avoid to content

Moving didn’t harmed as much as I believed it would– and vibrant DNS still works!

Opening the closet of facilities to peek within!

Credit: Aurich Lawson|Getty Images

A couple of months back, I create a huge fat guide on how to set up DNS and DHCP on your LAN the old-school method, with bind and dhcpd working together to perfectly give out addresses to hosts on your network and likewise sign up those hosts in your LAN’s forward and reverse DNS lookup zones. The post did actually well– thanks for reading it!– however something commenters mentioned was that my favored dhcpd application, the age-old isc-dhcp-server, reached end-of-life in 2022. To change it, ISC has for several years been dealing with the advancement of a brand-new DHCP server called Kea.

Kea (which for this piece will refer primarily to the isc-kea-dhcp4 and isc-kea-dhcp-ddns applications) does not change the end-user experience of getting DHCP addresses– your gadgets will not much care if you’re utilizing isc-dhcp-server or isc-kea-dhcp4. Rather, what Kea gives the table is a brand-new codebase that rejects the older dhcpd’s multi-decade stack of frequently crufty code for a brand-new stack of much less crufty code that will (ideally) be much easier to keep and extend.

Numerous Ars readers know the timeless Joel on Software post about how rewording your application from scratch is nearly never ever a great concept, however something like isc-dhcp-server– whose redesign is being managed planfully by the Internet Systems Consortium– is the exception to the guideline.

According to ISC, the older isc-dhcp-server application’s codebase was ending up being progressively hard to preserve, and at a specific point, it struck what we in some cases describe as the “Old Yeller” limit, where it lastly ended up being smarter to begin over than to continue to make complex a currently over-complicated mess of old code. In isc-dhcp-server’s location, Kea is correctly multithreaded, supports high schedule, can extend its performance through optional hooks and a full-featured API, and even has an optional visual user interface for reporting and admin jobs.

For admins, Kea being a ground-up reword suggests that you can’t simply take your existing isc-dhcp-server setup file and drop it in /etc/kea— and while there are automatic tools to equate that existing config file to Kea-speak, those tools supply more of a beginning point than a location. Diving into the documents to identify what choices are essential for the performance your particular setup requirements is an obligatory part of the procedure.

We’ll short-circuit that simply a tiny bit as I step through my own upgrade procedure and share the config I’m utilizing on my LAN. Initially, the inescapable cautions!

Table of Contents

Who the heck is this guide even for?

If you’re a network engineer searching for suggestions on updating your business’s core DHCP performance over to Kea, this is not the guide for you. We’ll be re-creating my homelab-specific isc-dhcp-server setup in Kea JSON and discussing the (mainly extremely standard) alternatives I’ve chosen. We are not going to be doing anything insane innovative. If you’re doing this at work, should not you have a VAR or MSP doing this for you? Do not count on my guidance for an environment that in fact matters!

On the other hand, if you’re an Ars reader with a homelab (or if you’re like me and your whole home network is your homelab since nobody who understands any much better is around to stop you) and you’ve got isc-dhcpd offering DHCP services, this guide is precisely for you! Offered you have a fairly easy setup with a couple of subnets and absolutely nothing wild going on, this guide must get you pointed in the ideal instructions.

Wait, this “upgrade” sounds difficult and unrewarding!

Yeah, changing a program that works fine with another program that works fine however needs a brand-new setup does not precisely seem like the most beneficial thing one might do with their time, however take a look at it by doing this: The old isc-dhcp-server application was launched 26 years earlier, and if Kea is likewise supported and supported by its dev neighborhood, the expectation is that it will be around for a minimum of as long. With a little bit of luck, this discomfort will be a one-time-only offer.

And to be completely clear, you do not requirement to alter over from isc-dhcp-server to Kea for your homelab. (At least not yet.) The isc-dhcp-server plans are still readily available on every huge Linux distro, and will likely stay so for rather a long time. ISC states that Kea is totally production-ready, however if you ‘d choose to enjoy Kea prepare a bit longer and let folks like me continue to flail around with it, you absolutely still have a lot of time to do so.

I think we’re doing this

The extremely first thing to do for folks transitioning from isc-dhcp-server to Kea is to run your existing isc-dhcp-server setup file through the ISC’s Kea Migration Assistant tool. This will offer you some concept of how your existing dhcpd setup will require to be modified when hammering it into Kea’s JSON-style config files.

(Folks who are uneasy pasting their setup submits into a web-based tool can most likely make the most of regional variations of the Kea Migration Assistant. If you’re utilizing Ubuntu Server, you can set up the isc-dhcp-keama plan from the default repos.)

If you have my level of luck, the Migration Assistant will spit back a config file primarily made from remarks about how whatever you wish to do usages deprecated alternatives. Which’s okay! Reserve the output declare a couple of minutes– we’ll return to it.

Do you like remarks? Since the keama tool is going to provide you great deals of remarks.

Credit: Lee Hutchinson

Do you like remarks? Since the keama tool is going to provide you great deals of remarks.

Credit: Lee Hutchinson

Really setting up Kea

Now it’s time to set up Kea, and there are a number of alternatives for getting that done. If you’re on Ubuntu and you ‘d choose to go the bare metal path, there are Kea plans readily available in the repositories; for Ubuntu Server 24.04 LTS, which is what I’m utilizing, the plans are for Kea variation 2.4.1( Kea’s “stable” branch).

This is a completely cromulent variation to merely set up and run, however if you ‘d like something more present, ISC keeps a set of repos for many significant Linux distros. This is the alternative I picked, making use of these guidelines right here, due to the fact that Kea is under active advancement, and the present (since October 2024) 2.6.1 variation from the ISC repo provides functions missing from 2.4.1 steady (and a few of the setup alternatives are somewhat various, too).

There’s likewise a set of main Docker images for Kea if you ‘d choose a setup that is a bit more ephemeral– or if Docker is your favored approach of running facilities tools like Kea.

(A fast note for folks who select to go the Docker path: I’ll be continuing in this guide with directions for bare-metal installs. If you’re going on with Docker, you’ll require to adjust this things into Docker-speak yourself. At the minimum, you’ll require a directory site reserve on your host to save your Kea setup files and DHCP lease database beyond the Docker image.)

There are 3 particular Kea plans we desire: isc-kea-dhcp4 isc-kea-dhcp-ddnsand isc-kea-doc (or kea-dhcp4-server kea-dhcp-ddns-serverand kea-doc if you’re setting up from the older Canonical repos instead of the ISC ones). There are several other Kea bundles you might set up if you ‘d choose to play even more, consisting of the isc-kea meta-package if you desire all of the Kea elements, however for this guide, we’ll stick simply with the 3 noted.

The factor there are numerous things to set up here– a minimum of compared to the old isc-dhcp-server all-in-one bundle– is that Kea divides out its DDNS performance into different elements. We require isc-kea-dhcp4 to supply IPv4 DHCP services, and after that we require isc-kea-dhcp-ddns to hook Kea approximately our DNS server (bind, in this circumstances) to do the real vibrant updates to your zone files as hosts reoccured. The isc-kea-doc bundle includes an entire mess of beneficial example setup files to baby crib from– more on that in a bit.

Both the DHCP server and the DDNS server elements have their own setup files, and the next action is to modify those files. If you utilized the Kea Migration Assistant previously, keep that output file helpful for completion of the next area.

Examining our setup requires

Simply to re-emphasize something from the start of this short article: I can’t inform you how you ought to configure your circumstances of Kea. Rather, I’ll inform you how I set up my circumstances of Kea. (If you desire some more setups to take a look at, seek advice from the examples provided by the isc-kea-doc bundle in /usr/share/doc/isc-kea-doc/examples— there’s an incredible quantity of helpful details saved there!)

Lots of sample config files await your perusal if you set up the optional docs bundle.

Credit: Lee Hutchinson

Numerous sample config files await your perusal if you set up the optional docs bundle.

Credit: Lee Hutchinson

I have a basic setup: I require to offer DHCP services to a single subnet, and the majority of the hosts on that subnet have DHCP appointments, so I do not require an enormous swimming pool. I do not require anything elegant or complicated( beyond DDNS, which isn’t extremely expensive or complex).

With that being stated, the primary element of the migration to Kea for me was evaluating the essential things in my old isc-dhcp-server config file and seeing either how the Migration Assistant turned it into Kea-speak, or, if the Migration Assistant didn’t understand what to do with a provided setting, attempting to by hand discover the comparable setting for Kea.

A fast walk-through of my old config revealed that I had the list below requirements to continue from the old setup to the brand-new:

I required to develop one DHCP-enabled subnet
I required DDNS allowed and forward- and reverse-lookup zones defined
I required to represent a finalizing secret for DDNS updates
I most likely desired longer DHCP lease times than the default (given that it’s a homelab without a great deal of host turnover)
I required some host bookings.

Broken down that method, the migration didn’t look awfully frightening– and it’s simplified by the reality that the Kea default config files come filled with detailed remarks and setup examples to baby crib from. (And, once again, ISC has actually done an exceptional task with the docs for Kea. All variations, from deprecated to bleeding-edge, have comprehensive and substantial online documents if you’re curious about what a provided alternative does or where to use it– and, as kept in mind above, there are likewise the provided sample config files to tear apart if you desire more comprehensive examples.)

Setup time for DHCP

We have 2 Kea applications to set up, so we’ll do DHCP very first and after that get to the DDNS side. (Though the DHCP config file likewise includes a lot of DDNS things, so I think if we’re being pedantic, we’re setting both up simultaneously.)

The very first file to modify, if you set up Kea through bundle supervisor, is /etc/kea/kea-dhcp4.confThe file ought to currently have some fairly sane defaults in it, and it’s worth taking a minute to check out the remarks and see what those defaults are and what they indicate.

Here’s a gently sterilized variation of my working kea-dhcp4.conf file:


  "Dhcp4":
    "control-socket":
      "socket-type": "unix"
      "socket-name": "/tmp/kea4-ctrl-socket"
    
    "interfaces-config": ,
    "dhcp-ddns": ,
    "ddns-conflict-resolution-mode": "no-check-with-dhcid"
    "ddns-override-client-update": real,
    "ddns-override-no-update": real,
    "ddns-qualifying-suffix": "bigdinosaur.lan"
    "authoritative": real,
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "expired-leases-processing": ,
    "loggers":[]
    "reservations-global": incorrect,
    "reservations-in-subnet": real,
    "reservations-out-of-pool": real,
    "host-reservation-identifiers":[
      "hw-address"
    ]
    "subnet4":[]

The very first verses established the control socket on which the DHCP procedure listens for management API commands (we’re not going to establish the management tool, which is overkill for a homelab, however this will guarantee the socket exists if you ever choose to enter that instructions). They likewise established the user interface on which Kea listens for DHCP demands, and they inform Kea to listen for those demands in raw socket mode. You probably desire raw as your DHCP socket type (see here for why), however this can likewise be set to udp if required.

Next, we’re making it possible for DDNS so that hosts on the network will register themselves with DNS as they’re appointed DHCP addresses. We’ll be supplying a couple of alternatives to make DDNS work the method I desire– particularly, I desire DHCP customers to constantly register themselves with DDNS, and I desire them to do it with my domain suffix. We likewise desire our host to be authoritative That it correctly reacts to all types of DHCP demands.

Pay specific attention to the ddns-conflict-resolution-mode criterion. This setting determines whether Kea customizes forward- and reverse-lookup records for DHCP hosts as they sign up. The default worth is check-with-dhcidthat makes Kea act in accordance with RFC 4703 and not get rid of or modify any DNS records it does not acknowledge as its own, with that acknowledgment keying off of the Dynamic Host Configuration Identifier, or DHCID, which Kea records when it develops a brand-new DNS host file entry.

(If you’re utilizing a variation of Kea prior to 2.5.0, you’ll need to utilize the ddns-use-conflict-resolution alternative rather, which was changed in 2.5.0 with ddns-conflict-resolution-modeAll of this is set out, with in-depth descriptions, in the main docs.)

The factor I’m utilizing no-check-with-dhcid rather of the default is that in this case, I’m slotting Kea into an existing environment with existing zone files occupied with existing entries from existing hosts, and I desire Kea to be unconstrained with eliminating and changing those existing entries as hosts de- and re-register themselves. I figure I’ll alter it back to the default choice after a couple of weeks, when Kea has actually supervised for a while. If you’re in a comparable scenario, you may think about a comparable option; otherwise, it’s great to leave that choice at its default.

Next, we have some lines that handle DHCP lease life time and how Kea recovers ended leases. As kept in mind previously, I choose a longer lease time considering that my homelab does not have a great deal of hosts and isn’t constrained for address area, so I’ve bumped the default values up substantially. You need to set these worths to taste or leave them at defaults.

The logging verses are all from the defaults in the config file, so there’s absolutely nothing much to discuss there.

After this, we get to the meaty bit where we inform Kea what subnet to listen to for inbound DHCP demands and how to react to them. I have my primary LAN sector noted, and the pools verse recognizes the real address swimming pool within that subnet from which customer addresses will be given out. I’m utilizing 10.10.10.170-10.10.10.254 for my swimming pool.

(Without getting too far into the weeds, I like to utilize 10.10.10.2-99 for fixed attending to, 10.10.10.100-169 for DHCP host bookings, and greater addresses for basic DHCP hosts. The old sysadmin in me chooses having the ability to determine a host’s function by taking a look at its IP address.)

Listed below the subnet and swimming pool meanings are the particular DHCP choices we desire our customers to get. There are lots of things you can specify here, however I’m sticking to the essentials: Clients get a netmask, an entrance address, a broadcast address, a DNS server, and a domain.

If you ‘d like, you can include some host appointments. If you choose specific customers to constantly get the exact same IP address whenever they sign up with the LAN, this is how you do it.

What other choices exist that we didn’t get to?

There are various methods to put your own setup together, with among the main factors to consider being the scope of how commonly our choices use. The majority of the setup choices here can be set to use worldwide, use per subnet, or use to particular groups of hosts.

The very best method to go into this, if you seem like there’s something you wish to do that I have not covered, is to invest a long time dissecting the Kea example setup files, which ought to be found in /usr/share/doc/isc-kea-doc/examplesSeveral usage cases are laid out there, and no matter how unusual your homelab is, you need to have the ability to discover something that a minimum of resembles what you’re wanting to do.

Setup time for DDNS

The DDNS setup is a bit easier than the DHCP setup and does not truly require that lots of verses. Setup for the Kea DDNS element is saved in kea-dhcp-ddns.confHere’s mine:


"DhcpDdns":
  "control-socket":
      "socket-type": "unix"
      "socket-name": "/tmp/kea-ddns-ctrl-socket"
  
  "tsig-keys":[]
  "forward-ddns" : ,
  "reverse-ddns" :
    "ddns-domains":[]
  "loggers":[
      "name": "kea-ddns"
      "output_options":[
          "output": "syslog"
          "pattern": "%-5p %mn"
          "maxsize": 1048576,
          "maxver": 8]
      "severity": "INFO"
      "debuglevel": 0]

Just like with the DHCP side of your house, we begin by setting up a control socket. After that, we define a cryptographic secret (saved in a file) that will be provided to the DNS server when producing, upgrading, or eliminating entries in the forward and reverse DNS zone files. This can be the very same secret you’re currently utilizing if you have an existing isc-dhcp circumstances currently running.

(Note that if you’re utilizing the 2.4.1 steady variation of Kea from the Canonical repos, you’ll need to inline your TSIG secret– external crucial storage wasn’t presented till variation 2.5.8. Some examples of how to do this can be discovered in the main docs.)

Continuing in the config file, listed below the crucial statement, are 2 really essential areas: the ones that specify the names of the forward and reverse DNS zones, the DNS server or servers with reliable control over those zones, and the name of the secret which will be utilized for DNS updates.

We set up our logging, which I’m setting up the very same as with the DHCP server so that whatever disposes into syslog. If you ‘d choose your DHCP and DDNS logging information to appear in its own file, this can be set up here.

Start ’em up

Which’s … type of it. If you’re transitioning off of the older isc-dhcpd-server application, now’s the time to stop isc-dhcpd-server and launch (or reboot) the Kea services. Before beginning the brand-new things up, it’s not a bad concept to offer your Kea setup submits a syntax check utilizing the -t alternatives for the DHCP and DDNS servers, thus:

$ kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

2024-10-03 08:19:36.370 INFO [kea-dhcp4.hosts/9004.137401687681472] HOSTS_BACKENDS_REGISTERED the following host backend types are available: mysql postgresql
2024-10-03 08:19:36.371 WARN [kea-dhcp4.dhcpsrv/9004.137401687681472] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2024-10-03 08:19:36.371 WARN [kea-dhcp4.dhcp4/9004.137401687681472] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2024-10-03 08:19:36.371 INFO [kea-dhcp4.dhcpsrv/9004.137401687681472] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 10.10.10.0/24 with params: t1=43200, valid-lifetime=86400
2024-10-03 08:19:36.371 INFO [kea-dhcp4.dhcpsrv/9004.137401687681472] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-10-03 08:19:36.371 INFO [kea-dhcp4.dhcpsrv/9004.137401687681472] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
2024-10-03 08:19:36.371 INFO [kea-dhcp4.dhcpsrv/9004.137401687681472] DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0

$ kea-dhcp-ddns -t /etc/kea/kea-dhcp-ddns.conf

2024-10-03 08:20:02.175 INFO [kea-dhcp-ddns.dctl/9028.131816933525376] DCTL_CONFIG_CHECK_COMPLETE server has completed configuration check: listening on 127.0.0.1, port 53001, using UDP, result: success(0), text=Configuration check successful

Presuming no mistakes are spotted, it’s time to begin your services!

Attempt ’em out

As soon as your services are begun, the only thing delegated do is let a host register itself with DHCP and see what occurs. Get your host of option, cross your fingers and toes, and activate a DHCP renewal.

Here’s the log output for a host effectively getting an address and registering itself with DNS. Your log output might not look similar, however if all works out, you’ll see something comparable:

2024-10-03T07:36:21.370880 -05:00 frylock kea-dhcp4: INFO DHCP4_QUERY_LABEL got question: [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6 2024-10-03T07:36:21.371033 -05:00 frylock kea-dhcp4: INFO DHCP4_PACKET_RECEIVED [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: DHCPDISCOVER (type 1) gotten from 0.0.0.0 to 255.255.255.255 on user interface eth0 2024-10-03T07:36:21.371659 -05:00 frylock kea-dhcp4: INFO DHCP4_LEASE_OFFER [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: lease 10.10.10.171 will be provided 2024-10-03T07:36:21.371697 -05:00 frylock kea-dhcp4: INFO DHCP4_PACKET_SEND [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: attempting to send out package DHCPOFFER (type 2) from 10.10.10.20:67 to 10.10.10.171:68 on user interface eth0 2024-10-03T07:36:21.371834 -05:00 frylock kea-dhcp4: INFO DHCP4_QUERY_LABEL got inquiry: [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6 2024-10-03T07:36:21.371865 -05:00 frylock kea-dhcp4: INFO DHCP4_PACKET_RECEIVED [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: DHCPREQUEST (type 3) gotten from 0.0.0.0 to 255.255.255.255 on user interface eth0 2024-10-03T07:36:21.372014 -05:00 frylock kea-dhcp4: INFO DHCP4_LEASE_ALLOC [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: lease 10.10.10.171 has actually been assigned for 86400 seconds 2024-10-03T07:36:21.372043 -05:00 frylock kea-dhcp4: INFO DHCP4_PACKET_SEND [hwtype=1 bc:24:11:e4:55:a8]cid=[ff:68:69:36:b7:00:02:00:00:ab:11:8c:79:c1:fb:f0:75:be:b5]tid=0xebc5aca6: attempting to send out package DHCPACK (type 5) from 10.10.10.20:67 to 10.10.10.171:68 on user interface eth0 2024-10-03T07:36:21.372451 -05:00 frylock called[233]: customer @ 0x7c90201e2698 10.10.10.20 # 47583/key dhcpupdate: signer "dhcpupdate"authorized 2024-10-03T07:36:21.372478 -05:00 frylock called[233]: customer @ 0x7c90201e2698 10.10.10.20 # 47583/key dhcpupdate: upgrading zone 'bigdinosaur.lan/ IN': erasing rrset at 'testbox.bigdinosaur.lan' A 2024-10-03T07:36:21.372489 -05:00 frylock called[233]: customer @ 0x7c90201e2698 10.10.10.20 # 47583/key dhcpupdate: upgrading zone 'bigdinosaur.lan/ IN': erasing rrset at 'testbox.bigdinosaur.lan' DHCID 2024-10-03T07:36:21.372501 -05:00 frylock called[233]: customer @ 0x7c90201e2698 10.10.10.20 # 47583/key dhcpupdate: upgrading zone 'bigdinosaur.lan/ IN': including an RR at 'testbox.bigdinosaur.lan' A 10.10.10.171 2024-10-03T07:36:21.372514 -05:00 frylock called[233]: customer @ 0x7c90201e2698 10.10.10.20 # 47583/key dhcpupdate: upgrading zone 'bigdinosaur.lan/ IN': including an RR at 'testbox.bigdinosaur.lan' DHCID AAIBmbAv/h6HepABnIwn8vOOkSYCmkaDHfyLgS4lnQYM76o=2024-10-03T07:36:21.374071 -05:00 frylock called[233]: customer @ 0x7c901800f318 10.10.10.20 # 51638/key dhcpupdate: signer "dhcpupdate"authorized 2024-10-03T07:36:21.374097 -05:00 frylock called[233]: customer @ 0x7c901800f318 10.10.10.20 # 51638/key dhcpupdate: upgrading zone '10.10.10.in-addr. arpa/IN': erasing rrset at '171.10.10.10.in-addr. arpa' PTR 2024-10-03T07:36:21.374108 -05:00 frylock called[233]: customer @ 0x7c901800f318 10.10.10.20 # 51638/key dhcpupdate: upgrading zone '10.10.10.in-addr. arpa/IN': erasing rrset at '171.10.10.10.in-addr. arpa' DHCID 2024-10-03T07:36:21.374123 -05:00 frylock called[233]: customer @ 0x7c901800f318 10.10.10.20 # 51638/key dhcpupdate: upgrading zone '10.10.10.in-addr. arpa/IN': including an RR at '171.10.10.10.in-addr. arpa' PTR testbox.bigdinosaur.lan. 2024-10-03T07:36:21.374133 -05:00 frylock called[233]: customer @ 0x7c901800f318 10.10.10.20 # 51638/key dhcpupdate: upgrading zone '10.10.10.in-addr. arpa/IN': including an RR at '171.10.10.10.in-addr. arpa' DHCID AAIBmbAv/h6HepABnIwn8vOOkSYCmkaDHfyLgS4lnQYM76o=2024-10-03T07:36:21.375504 -05:00 frylock kea-dhcp-ddns[265]: 2024-10-03 07:36:21.375 INFO  [kea-dhcp-ddns.d2-to-dns/265.126183045056384] DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 00020199B02FFE1E877A90019C8C27F2F38E9126029A46831DFC8B812E259D060CEFAA: effectively included the DNS mapping addition for this demand: Type: 0 (CHG_ADD) 2024-10-03T07:36:21.375528 -05:00 frylock kea-dhcp-ddns[265]: Forward Change: yes 2024-10-03T07:36:21.375537 -05:00 frylock kea-dhcp-ddns[265]: Reverse Change: yes 2024-10-03T07:36:21.375543 -05:00 frylock kea-dhcp-ddns[265]: FQDN: [testbox.bigdinosaur.lan.]
2024-10-03T07:36:21.375550 -05:00 frylock kea-dhcp-ddns[265]: IP Address: [10.10.10.171]
2024-10-03T07:36:21.375556 -05:00 frylock kea-dhcp-ddns[265]: DHCID: [00020199B02FFE1E877A90019C8C27F2F38E9126029A46831DFC8B812E259D060CEFAA]
2024-10-03T07:36:21.375563 -05:00 frylock kea-dhcp-ddns[265]: Lease Expires On: 20241003203621 2024-10-03T07:36:21.375569 -05:00 frylock kea-dhcp-ddns[265]: Lease Length: 28800 2024-10-03T07:36:21.375576 -05:00 frylock kea-dhcp-ddns[265]: Conflict Resolution Mode: no-check-with-dhcid

Keep in mind the interaction in between the kea-dhcp4 namedand kea-dhcp-ddns procedures as they collaborate to get the host attended to and signed up. If you see something that looks sort of like this in your output, congrats– you did it!

The sweet odor of broccoli and success

The swap from isc-dhcp-server to Kea was one that I put off for a long time due to the fact that, I indicate– ugh? It’s sort of a broccoli upgrade, where you understand it’s excellent for you and you understand you must do it, however it’s simply not enjoyable or attractive, and it does not always include anything brand-new to the ol’ homelab’s performance.

As so frequently occurs with broccoli upgrades, I’m thankful I buckled down and made the switch– if for no other factor than to shore up a crucial facilities part of my entire LAN. Modification is frightening, and isc-dhcp-server has actually been a continuous buddy for more than a years of home sysadmin experiences, however there is something to be stated about residing on the safe side of the assistance curve.

Sit down and consume your broccoli, fellow homelabbers still running isc-dhcp-server. It’s time to update, and it’s not frightening at all.

Lee is the Senior Technology Editor, and supervises story advancement for the device, culture, IT, and video areas of Ars Technica. A veteran member of the Ars OpenForum with a substantial background in business storage and security, he resides in Houston.