On Thu, 2025-09-18 at 13:14 +0100, Barry wrote:
> I got as far as getting kea dhcp working, but the integration with
> bind stumped me.
> It’s on my todo list to go back and try again.
I still have BIND DNS & DHCP servers running together on CentOS 7
(internally, not publicly), and used to do it all on Fedora before I
got sick of having to change server OS installations as often as
Fedora's schedule. Ooh look, a shiny new toy...
I'm not particularly sure which ISC DHCP server it is (it was the
default package they offered, back then), it wasn't that hard to
integrate one with the other (any dynamic clients the DHCP server give
an address is included in the local DNS server records, firstly in RAM,
then stored on disc after a time delay--this avoids lots of writing for
clients that quickly come and go).
The DHCPD config "includes" the same /etc/rndc.key file that BIND
includes, and the zone DHCPD updates needs the DNS server IP and the
rndc-key (using whatever name it calls itself in the keyfile).
So both of their config files have a line in them like this:
include "/etc/rndc.key";
And that file has something in it like this:
key "rndckey" {
algorithm hmac-md5;
secret "BCasdRANDOMfHdaNrCRAPtyi46445dhvnd346T";
};
named.conf has something in it like this (the allow-update lines being
important parts of the integration of the two services):
zone "example.com" {
type master;
file "example.com.zone";
allow-update { key "rndckey"; };
allow-transfer { 192.168.0/24; };
notify yes;
};
zone "0.168.192.in-addr.arpa" {
type master;
file "0.168.192.in-addr.arpa.zone";
allow-update { key "rndckey"; };
allow-transfer { 192.168.0/24; };
notify yes;
};
And dhcpd.conf has some things in it like this (the primary server
address and the keys being the important part of integration of the two
services):
ddns-update-style interim;
ddns-updates on;
allow client-updates;
zone 0.168.192.in-addr.arpa. {
primary 192.168.0.1;
key rndckey;
}
zone example.com. {
primary 192.168.0.1;
key rndckey;
}
The KEA DHCPD server is supposed to have a tool for converting old
style configuration files to the new. If you had a working (ISC)
system, that might be worth exploring.
I expect there's an equivalent scheme of using a shared key, and
specifying server addresses. This page seems to support that notion:
https://kea.readthedocs.io/en/latest/arm/ddns.html
But quickly looking at a website about configuring it, it looks like
they've taken inspiration from the afterlife manual from Beetlejuice.
https://kb.isc.org/docs/kea-administrator-reference-manual
You know what? This is a bundle of gobbledegook that I'd just rather
not ever have to deal with. Masses of reading before you even
contemplate the basics. It's just way too convoluted for my needs,
I'm not an ISP with thousands of clients to manage, I'll stick with my
out-of-date system while it still runs.
I'd let my router handle DHPC, except that it doesn't talk to its own
DNS server, giving no way for local machine name resolution to work.
You're left relying on mDNS acting like a magic box. Or, having to use
numerical IP addresses, remembering what each one is, and coping with
inconsistent addresses.
--
uname -rsvp
Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64
(yes, this is the output from uname for this PC when I posted)
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
--
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
