Since mid 2023 I have been running a Docker ISC Kea Image using base Docker Alpine Linux images, with S6 init system. (ISC Kea is a modern replacement for their DHCP.) The main DHCP server runs on my main server and I have an automatic fall over back up on my separate Linux router. I basically followed the Kea template Home Network of a Power User. I was never quite sure I had the automatic fall over back-up working. On 2023-01-02 I modified a configuration file on the primary server with a syntax error, 8 days later I notice millions of lines of errors on my log files. Sure enough the backup had simply been working. I fixed up the simple syntax error and the primary server took back over. Everything basically worked as expected.

ISC also has a project for a simple GUI interface primarily for Kea and basic for Bind9. There is apparently no Alpine package yet for Stork.

ISC-Kea seems to be provided in a number of packages

From IANA Service Name and Transport Protocol Port online Number Registry:

bootps    67   {tcp, udp}       Bootstrap Protocol Server (DHCP)
bootpc    68   {tcp, udp}       Bootstrap Protocol Client (DHCP)

The Kea Control Agent uses port 8000 by default, but that value can be manually defined in its configuration file. (Usually located at /etc/kea/kea-ctrl-agent.conf.) This port needs to be open and accessible on every server that hosts a Kea DHCP service and a Kea Control Agent.

This is a good case where the Docker network type needs to be set to host. The DHCP server needs to be directly on the host to function.

sudo nmap --script broadcast-dhcp-discover will test the DHCP servers on the same network.

• Command line program to test DHCP service
• The Official Nmap Project Guide to Network Discovery and Security Scanning
• 5 scripts for getting started with the Nmap Scripting Engine

• kea-dhcp4 -t /app/dhcpv4.conf to test the kea-dhcp4 configuration files /app/dhcpv4.conf
• kea-dhcp4 -c /app/dhcpv4.conf to start kea dhcp4 using configuration file /app/dhcpv4.conf

Use of symlink, TL;DR;

• kea-dhcp4 -c /app/dhcpv4_plus.conf to start kea dhcp4 using configuration file /app/dhcpv4_plus.conf. This configuration file is designed to work with the kea control agent setup. Where as the basic configuration /app/dhcpv4_basic.conf is not.

• kea-ctrl-agent -t /app/kea-ctrl-agent.conf to test the kea-cont-agent configuration file /app/kea-ctrl-agent.conf
• kea-ctrl-agent -c /app/kea-ctrl-agent.conf to start the kea-cont-agent configuration file /app/kea-ctrl-agent.conf

• The Kea Control Agent

• Kea Logging Configuration

I have stored log files in the .config directory that is a Docker mounted volume for persistence and easy external viewing outside container. The following logs files can be seen.

• .config/log/kea-dhcp4-commands.log
• .config/log/kea-dhcp4-dhcpsrv.log
• .config/log/kea-dhcp4-leases.log
• .config/log/kea-dhcp4.log
• .config/log/kea-dhcp4-ha-hooks.log

• docker attach kptr-kea-1 to attach to running container
• kea-dhcp4 -v To check running version

My local DNS server is a recursive caching type only. It take local (LAN) DNS queries and answers directly for any LAN name resolution, checks the cache for any external name resolution and then if not found locally or in cache checks the specified external DNS servers to resolve names. My DNS server is not setup as a public DNS server and is not publicly accessible. Hence DNSSEC is not relevant for this local DNS server query validation.

For external name resolution Bind9 basically now defaults to automatic use of DNSSEC. This can be validated with (How To Test A Recursive Server) using:

• dig @192.168.1.14 ftp.isc.org. A +dnssec +multiline, the query return flag ad indicates the DNS answer returned a validated answer.
• dig @192.168.1.2 ftp.isc.org. A +dnssec +multiline

Equally important the following commands helps confirm that invalid DNS queries have failed and do not rerun invalid IP address, which would be security risk. If dig @192.168.1.14 www.dnssec-failed.org A receives status: SERVFAIL“” then dig @192.168.1.14 www.dnssec-failed.org A +cd will disable DNSSEC and return the IP address showing that the SERVFAIL occurred due to DNSSEC failure. Basic Bind9 DNSSEC configuration options * The option (in /etc/bind/named.conf.options) dnssec-enable yes; is no longer valid and use will cause configuration error. DO NOT USE! DNSSEC is enabled by default. * The option dnssec-validation is set default to auto. The other setting options are yes and no. No action is required, if the option is not specified in the configuration file it is set to auto by default. So I do not need to do any configuration for DNSSEC to function on external queries. ====reference==== *How DNSSEC Works *DNSSEC – What Is It and Why Is It Important? *Domain Name System Security Extensions *Bind9 DNSSEC Guide ++ old references *DNSSEC with BIND 9 A Beginner's Guide to DNSSEC with BIND 9 *APNIC How to: Deploying DNSSEC with BIND and Ubuntu Server ++ =====DNS over TLS (DoT)===== =====References===== *KPTree.net's bare metal implementation of dns - dhcp, based upon ISC Bind9 and DHCP on Debian 10 (was originally Ubuntu). *ISC documentation *Template: Home Network of a Power User *Using Official ISC Packages for Kea *Kea Configuration Introduction *Kea Configuration for Small Office or Home Use *Install and run KEA DHCP with Stork on Debian 11 * JonasAlfredsson / docker-kea