I ran my own home router and I used Kea and Power DNS using Systemd Containers to provide service for my whole home.
I was really impressed. I think the folks who put it together did a good job of addressing the major warts of my experience with isc-dhcp-server.
I'm sure it's a tremendous challenge writing software that's supposed to live up to modern expectations while still attempting to deliver on all of the legacy dependents and their unique use cases.
Makes me think of that article on how Cloudflare wrote their own Golang DNS Server and like some 900 whopping people use LOC records but they still support it
Yeah. Nowadays I use pi-hole which is dnsmasq underneath and use it with unbound.
Works great. Minimal fuss, efficient setup, little maintenance, I don't have to understand the guts. Everything on my local network is addressable.
Ad blocking at the router is also something you don't want live without once you've gone there but pi-hole is a great solution even if you don't want that.
I use Pihole as well (even tried to synchronize two for HA but I gave up). It is fantastic.
What worries me with dnsmasq is that it is a personal project maintained on a personal git (by a great person!). Sure, one can fork and whatnot but without several people participating it can fade out pretty quickly.
Yeah, fair point. And I don't think I've seen a router for sale that wasn't using dnsmasq as a dhcp server for 20 odd years. Must be some, I guess, but haven't encountered them.
I don't know about unbound's blocklists and stats or indeed much about unbound at all.
This: https://docs.pi-hole.net/guides/dns/unbound/ was stupidly simple, pi-hole has a gui that I was already used to and it all works great. So I think about and study other things that need fixing/improving in my life instead.
To flip it, why would I use unbound without pi-hole? What's the win I haven't seen (or even looked at or considered?)
> To flip it, why would I use unbound without pi-hole? What's the win I haven't seen (or even looked at or considered?)
In my experience, the fewer moving parts the better.
I run Unbound on my OPNsense router, and it uses the same blocklists as Pi-hole and the stats page (blocked domains, DNS requests, etc) are the same afaict.
There's places where integration makes sense (home network/small business with tens of clients/devices) and places where dedicated engines make sense (ISPs, large enterprise VPNs, the Internet).
dnsmasq is awesome if you want a one-stop shop for DHCP and DNS for sure.
dnsmasq is great. The best part is that you can assign the same IP to multiple interfaces on the same device (to multiple MAC addresses) which drives network purists crazy and is no longer supported by systemd-networkd (because they are puritans). Separated DHCP/DNS can not do this. I will look into kea and whether they can do this.
I used to (when I did that more) set up a bond of my wireless and ethernet devices, so when ethernet was plugged in it was preferred, otherwise it would use wireless. It was pretty seamless, and provided the same MAC on both networks.
I used to do that too. Nowadays I just run a WireGuard VPN and treat my WiFi network as "untrusted" (which is a good idea anyway) and it's more seamless if IP addresses change, or even if I leave the house and go somewhere else - I can expect most connections to stay up.
The use case is `ssh shortname` or `ssh shortname.lan` to a laptop on the same local network regardless whether the wired or wireless interface of the laptop is active.
An overlay like Tailscale MagicDNS might solve this but is complex.
Assigning the same name to 2 IP's (round robin DNS) will mean having to retry the ssh connection if the IP of the inactive interface is returned.
Failover bonding (mode 1) of the wireless and wired interfaces with MAC address spoofing so that the bonded interface maintains a consistent MAC address is reportedly not always supported by WiFi hardware and standards. Bonding may require manual reconfiguration when the laptop moves from the local network where "shortname" is used to an arbitrary WiFi network like airport or coffee shop.
Are there any solutions that satisfy single IP and reliable WiFi at the same time?
Linux used to be able to move the same IP between 2 interfaces depending on which was active. But it looks like advancements in Linux networking have killed this simple solution.
OPNSense deprecated (is deprecating?) the included ISC DHCP server and now has the Kea DHCP server as standard. I migrated to from ISC to Kea in OPNSense and it was relatively painless, and it's been working well since. No complaints here, but my setup is pretty vanilla.
I can't comment on the DNS integration, but I might look a bit deeper because it sounds useful.
ISC shut down the DHCP project in 2022 (and afaik, nobody has taken it up as a fork), so it's less of a OPNSense decision and more of an ISC decision. Nothing is stopping anyone from continuing to user ISC dhcp for a long time, but people are reluctant.
It sounded like they were encouraging dnsmasq for home use. I migrated to that successfully. My DHCPv6 is working flawlessly now whereas I was never able to get it running smoothly/persistently on ISC.
I understand Kea has more features so I'm a little curious what I'm missing.
I, too, was under the impression that Kea is now mostly out and they're going the dnsmasq route.
There were open issues about some basic features with Kea, too: https://github.com/opnsense/core/issues/7475
In my homelab I've been using very barebones options (the one built into systemd-networkd as well as the dhcp server built into RouterOS) and never found myself needing a web interface, a database or anything… really. It has been sufficient to add the couple dozen static allocations to the configuration files and forget DHCP exists. Even HA is not something I found myself wanting as nodes will retain their lease well over the period of downtime incurred during botched upgrades.
How fancy does a network needs to be before this starts making sense? Who are the target audience for this project?
I’ve hit twice over the last year where it was needed. Though in one case, it’s because a server that was physically old enough to vote happened to be handling dhcp and dns. I set the other, only slightly less old, server to be primary on both but left the original functioning just in case with failed.
The main need I had was for a bank. Network functionality is obviously highly important there. Windows updates impacted the dhcp service on one server, which wasn’t an obvious thing till leases started running out the following morning. Multiple DC’s, so set up for HA to avoid issues in the future. It’s almost never needed but great to have when total uptime is key to operations.
We use Kea at work and make extensive use of its hooks system to customise what leases we give out, and in which of our 8 datacenters. Our infrastructure is hundreds of thousands of machines and Kea's distributed nature makes it a breeze.
I looked at Kea based on ISC's suggestion to replace their DHCPD. I can totally see deploying this in a data-center environment given how flexible it is but it was just to overwhelming for me for simple home use. I personally found that migrating to dnsmasq for DHCP alone was extremely simple, light weight and most importantly trivial to comprehend. Even with all my static reservations for cameras, routers, laptop, computers and phones my config is only 46 lines long and very easy to read. Migrating to Kea on the other hand required using optional modules and a very lengthy configuration that was entirely too fragile for my use case, but that was just my personal anecdotal experience. I also like the memory footprint of dnsmasq and that I rarely have to think about it.
Private + Shared = RAM used Program
476.0 KiB + 24.5 KiB = 500.5 KiB dnsmasq
I did for like a day when I upgraded to 2.7, until I found out that Kea, at the time at least, did not do MAC address based IP reservations, and you had to use the client identifier instead. So all my static leases stopped working.
So I switched back to the old dhcpd. shrug I'm sure whatever was going on (dunno if it was ISC or Kea or pfsense et. al) has been fixed since then, but I can't upgrade to 2.8 without giving Netgate my personal data[1] so I have to switch to OPNSense anyways.
[1] aside, not to say I really blame Netgate, they do a lot of great work and commit a ton to FreeBSD, and they want to stop people abusing that by selling gateways and such with their work on them, but also...man just let me download the goddamn iso. At least let me compile 2.8 from source! The source isn't even available last I checked! I was fine compiling my own QAT driver. But alas...
I migrated my home router over to Kea and was distinctly unimpressed - it just carried on working 8) I do run a pretty full on pfBlocker-NG. I run quite a few other pfs too (31).
At work I have a CARP cluster of two elderly Dell servers with a lot of NICS. I have a change logged for next week.
Kea has broken with my config twice now over as many years when upgrading versions. I regret jumping from ISC-DHCPd for my 2023 PF-box reinstall just because they called it “EOL”
I assume it's just how pfsense is using Kea, but moving to this has been a bit regretful. Since moving from the legacy one to Kea, my static reservations don't work first time. Clients get given an address from the pool and then some time later (hours) get their static reservation. No clue why, from reading doc it seems like this is intended behaviour and that static reservations are discouraged??
On isc-dhcp, clients got their static reservation straight up.
Do you mean "Static Mappings"?
I have a couple dozen of those and had no issue during my pfSense upgrade.
I also rely heavily on two settings in "Services > DHCP Server":
- [x] Enable DNS Registration (leases will auto-register with the DNS Resolver)
- [x] Enable Early DNS Registration (static mappings will auto-register with the DNS Resolver)
I do not use the "Create a static ARP table entry for this MAC & IP Address pair." option for individual static mappings.
I've deployed Kea in some interesting applications. I quite like its failover options for redundancy purposes.
Definitely has a learning curve for odd devices that "support" DHCP, but I've been happy with how it works, its outputs, and how it can easily be segmented.
unfortunate that you can't start it without the ethernet interface in UP state. if you start it while the ethernet cable is disconnected, it will start the daemon but not actually "listen" on the device, even after the cable gets plugged in.
my solution: create a bridge with your ethernet device and add a dummy device and UP the said summy device, thereby UPing the bridge.
Looking at the CVE history, first "LTS" release 3.0.0 was quickly replaced by 3.0.1
https://kb.isc.org/docs/cve-2025-40779
"CVE-2025-40779: Kea crash upon interaction between specific client options and subnet selection"
https://github.com/isc-projects/kea/commit/0afd42b5dfb2e547b...
unprotected null pointer use, kea is in C++
Shall we call Rust Evangelism Task Force and Rewrite in Rust in 3 femtoseconds?
https://github.com/bluecatengineering/dora
Actually, yes, that'd be great!
All software from ISC was/is littered with security vulnerabilities. BIND is in the same hall of shame as Sendmail.
I ran my own home router and I used Kea and Power DNS using Systemd Containers to provide service for my whole home.
I was really impressed. I think the folks who put it together did a good job of addressing the major warts of my experience with isc-dhcp-server.
I'm sure it's a tremendous challenge writing software that's supposed to live up to modern expectations while still attempting to deliver on all of the legacy dependents and their unique use cases.
Makes me think of that article on how Cloudflare wrote their own Golang DNS Server and like some 900 whopping people use LOC records but they still support it
I use dnsmasq mostly for its fantastic integration with DNS.
DHCP and DNS go hand in hand in a network, I really struggle to understand why they are not more integrated in otherwise great solutions (such as kea)
Yeah. Nowadays I use pi-hole which is dnsmasq underneath and use it with unbound.
Works great. Minimal fuss, efficient setup, little maintenance, I don't have to understand the guts. Everything on my local network is addressable.
Ad blocking at the router is also something you don't want live without once you've gone there but pi-hole is a great solution even if you don't want that.
I use Pihole as well (even tried to synchronize two for HA but I gave up). It is fantastic.
What worries me with dnsmasq is that it is a personal project maintained on a personal git (by a great person!). Sure, one can fork and whatnot but without several people participating it can fade out pretty quickly.
Yeah, fair point. And I don't think I've seen a router for sale that wasn't using dnsmasq as a dhcp server for 20 odd years. Must be some, I guess, but haven't encountered them.
Keep in mind dnsmasq has been around for over two decades by that great person, but... all good things come to an end?
I'm curious why you'd use pi-hole in combination with Unbound instead of using blocklists and stats that Unbound has built in?
I don't know about unbound's blocklists and stats or indeed much about unbound at all.
This: https://docs.pi-hole.net/guides/dns/unbound/ was stupidly simple, pi-hole has a gui that I was already used to and it all works great. So I think about and study other things that need fixing/improving in my life instead.
To flip it, why would I use unbound without pi-hole? What's the win I haven't seen (or even looked at or considered?)
> To flip it, why would I use unbound without pi-hole? What's the win I haven't seen (or even looked at or considered?)
In my experience, the fewer moving parts the better.
I run Unbound on my OPNsense router, and it uses the same blocklists as Pi-hole and the stats page (blocked domains, DNS requests, etc) are the same afaict.
There's places where integration makes sense (home network/small business with tens of clients/devices) and places where dedicated engines make sense (ISPs, large enterprise VPNs, the Internet).
dnsmasq is awesome if you want a one-stop shop for DHCP and DNS for sure.
Does the dns auto registration from dhcp work well with v6 as well in dnsmasq?
No, the local name → IP resolution will work for IPv4 only
dnsmasq is great. The best part is that you can assign the same IP to multiple interfaces on the same device (to multiple MAC addresses) which drives network purists crazy and is no longer supported by systemd-networkd (because they are puritans). Separated DHCP/DNS can not do this. I will look into kea and whether they can do this.
Whatever you're doing can probably be done faster and simpler with bridge interfaces.
What's the use case for this?
Going between wired and wireless is one example.
I used to (when I did that more) set up a bond of my wireless and ethernet devices, so when ethernet was plugged in it was preferred, otherwise it would use wireless. It was pretty seamless, and provided the same MAC on both networks.
I used to do that too. Nowadays I just run a WireGuard VPN and treat my WiFi network as "untrusted" (which is a good idea anyway) and it's more seamless if IP addresses change, or even if I leave the house and go somewhere else - I can expect most connections to stay up.
The use case is `ssh shortname` or `ssh shortname.lan` to a laptop on the same local network regardless whether the wired or wireless interface of the laptop is active.
An overlay like Tailscale MagicDNS might solve this but is complex.
Assigning the same name to 2 IP's (round robin DNS) will mean having to retry the ssh connection if the IP of the inactive interface is returned.
Failover bonding (mode 1) of the wireless and wired interfaces with MAC address spoofing so that the bonded interface maintains a consistent MAC address is reportedly not always supported by WiFi hardware and standards. Bonding may require manual reconfiguration when the laptop moves from the local network where "shortname" is used to an arbitrary WiFi network like airport or coffee shop.
Are there any solutions that satisfy single IP and reliable WiFi at the same time?
Linux used to be able to move the same IP between 2 interfaces depending on which was active. But it looks like advancements in Linux networking have killed this simple solution.
LWN discussion of some 2025 CVE on kea: https://lwn.net/Articles/1023093/
Comments are less positive than here on HN.
OPNSense deprecated (is deprecating?) the included ISC DHCP server and now has the Kea DHCP server as standard. I migrated to from ISC to Kea in OPNSense and it was relatively painless, and it's been working well since. No complaints here, but my setup is pretty vanilla.
I can't comment on the DNS integration, but I might look a bit deeper because it sounds useful.
ISC shut down the DHCP project in 2022 (and afaik, nobody has taken it up as a fork), so it's less of a OPNSense decision and more of an ISC decision. Nothing is stopping anyone from continuing to user ISC dhcp for a long time, but people are reluctant.
OpenBSD’s dhcpd(8) is apparently basic on the one from the ISC: https://man.openbsd.org/dhcpd
Not sure this counts as a fork or when it was “reworked” by OpenBSD, though.
It sounded like they were encouraging dnsmasq for home use. I migrated to that successfully. My DHCPv6 is working flawlessly now whereas I was never able to get it running smoothly/persistently on ISC.
I understand Kea has more features so I'm a little curious what I'm missing.
I, too, was under the impression that Kea is now mostly out and they're going the dnsmasq route. There were open issues about some basic features with Kea, too: https://github.com/opnsense/core/issues/7475
dnsmasq vs kea
Which one is better to use with OPNsense?
In my homelab I've been using very barebones options (the one built into systemd-networkd as well as the dhcp server built into RouterOS) and never found myself needing a web interface, a database or anything… really. It has been sufficient to add the couple dozen static allocations to the configuration files and forget DHCP exists. Even HA is not something I found myself wanting as nodes will retain their lease well over the period of downtime incurred during botched upgrades.
How fancy does a network needs to be before this starts making sense? Who are the target audience for this project?
I’ve hit twice over the last year where it was needed. Though in one case, it’s because a server that was physically old enough to vote happened to be handling dhcp and dns. I set the other, only slightly less old, server to be primary on both but left the original functioning just in case with failed.
The main need I had was for a bank. Network functionality is obviously highly important there. Windows updates impacted the dhcp service on one server, which wasn’t an obvious thing till leases started running out the following morning. Multiple DC’s, so set up for HA to avoid issues in the future. It’s almost never needed but great to have when total uptime is key to operations.
We use Kea at work and make extensive use of its hooks system to customise what leases we give out, and in which of our 8 datacenters. Our infrastructure is hundreds of thousands of machines and Kea's distributed nature makes it a breeze.
I looked at Kea based on ISC's suggestion to replace their DHCPD. I can totally see deploying this in a data-center environment given how flexible it is but it was just to overwhelming for me for simple home use. I personally found that migrating to dnsmasq for DHCP alone was extremely simple, light weight and most importantly trivial to comprehend. Even with all my static reservations for cameras, routers, laptop, computers and phones my config is only 46 lines long and very easy to read. Migrating to Kea on the other hand required using optional modules and a very lengthy configuration that was entirely too fragile for my use case, but that was just my personal anecdotal experience. I also like the memory footprint of dnsmasq and that I rarely have to think about it.
I've been running Kea at dayjob in production for the last 5-ish years, setup in a HA manner. It's worked solidly.
I’m wondering if this fixes the issue in pfsense which causes the Unbound DNS server to restart every time a new dhcp lease is created.
Once day I will stop procrastinating and migrate my pfsense boxes over to Kea. I hope I like it.
I'll be thrilled if the expected DNS integration works and I don't get the side effects I get now from ISC.
I did for like a day when I upgraded to 2.7, until I found out that Kea, at the time at least, did not do MAC address based IP reservations, and you had to use the client identifier instead. So all my static leases stopped working.
So I switched back to the old dhcpd. shrug I'm sure whatever was going on (dunno if it was ISC or Kea or pfsense et. al) has been fixed since then, but I can't upgrade to 2.8 without giving Netgate my personal data[1] so I have to switch to OPNSense anyways.
[1] aside, not to say I really blame Netgate, they do a lot of great work and commit a ton to FreeBSD, and they want to stop people abusing that by selling gateways and such with their work on them, but also...man just let me download the goddamn iso. At least let me compile 2.8 from source! The source isn't even available last I checked! I was fine compiling my own QAT driver. But alas...
Kea itself seems to support it[1] so I guess it's a pfsense limitation. I haven't tried the switch myself but it's on the to-do list.
[1] "hw-address" here: https://kb.isc.org/docs/what-are-host-reservations-how-to-us...
I migrated my home router over to Kea and was distinctly unimpressed - it just carried on working 8) I do run a pretty full on pfBlocker-NG. I run quite a few other pfs too (31).
At work I have a CARP cluster of two elderly Dell servers with a lot of NICS. I have a change logged for next week.
Kea has broken with my config twice now over as many years when upgrading versions. I regret jumping from ISC-DHCPd for my 2023 PF-box reinstall just because they called it “EOL”
I assume it's just how pfsense is using Kea, but moving to this has been a bit regretful. Since moving from the legacy one to Kea, my static reservations don't work first time. Clients get given an address from the pool and then some time later (hours) get their static reservation. No clue why, from reading doc it seems like this is intended behaviour and that static reservations are discouraged??
On isc-dhcp, clients got their static reservation straight up.
Do you mean "Static Mappings"? I have a couple dozen of those and had no issue during my pfSense upgrade. I also rely heavily on two settings in "Services > DHCP Server":
- [x] Enable DNS Registration (leases will auto-register with the DNS Resolver)
- [x] Enable Early DNS Registration (static mappings will auto-register with the DNS Resolver)
I do not use the "Create a static ARP table entry for this MAC & IP Address pair." option for individual static mappings.
Hopefully this helps you in your troubleshooting.
I’ve got 60+ static reservations across multiple VLANs and don’t see this behavior. I’m not sure where you read it’s expected behavior, but it isn’t.
I’m guessing it’s something in you’re config.
on pfsense?
> Clients get given an address from the pool and then some time later (hours) get their static reservation.
I'm still on isc-dhcp (and not pfsense either) but is there a chance you have two DHCP servers running?
I've deployed Kea in some interesting applications. I quite like its failover options for redundancy purposes.
Definitely has a learning curve for odd devices that "support" DHCP, but I've been happy with how it works, its outputs, and how it can easily be segmented.
Can you expand on the applications you deployed kea in?
unfortunate that you can't start it without the ethernet interface in UP state. if you start it while the ethernet cable is disconnected, it will start the daemon but not actually "listen" on the device, even after the cable gets plugged in.
my solution: create a bridge with your ethernet device and add a dummy device and UP the said summy device, thereby UPing the bridge.
Migrated from ISC to Kea on OPNSense and zero issue so far
Moved a large enterprise deployment to kea and it’s been fantastic. Very easy to troubleshoot.
[dead]