Cleaning up the lab (#3) - less highly available DHCP

Something I don't find myself saying often: time for a downgrade.

I contacted the Technitium folks about my issues with DHCP, and they helped me debug things a bit further. It led to me installing my first fresh Ubuntu 22.04 machine, and setting up a new Technitium instance on it.

After installing Ubuntu, I setup Technitium as before, and tried creating my DHCP scope again, and...

It instantly worked. I didn't even have to enable it. This definitely fulfils Technitium's promise of being nearly configuration-free out of the box.

Which leads me to the title of this post - I'm going to be making my DHCP a bit less "highly available", switching back to Technitium and turning off my ISC Kea servers for now. This is for a number of reasons:

• Technitium does a much better job of showing DHCP leases.
• I need to be able to set an "offer delay time", an option that ISC Kea doesn't appear to have available.
• Having one server (two if you count my secondary DNS server) rather than three/four at the heart of the home network feels better, even if it's technically less resilient.
• Switching will allow for dynamic DNS for my homelab domain, which isn't currently possible to do with a Kea/Technitium combo.

Technitium has DHCP high availability on the roadmap, so I won't be without HA forever.

This will also encourage me to create some isolated networks within Proxmox within which I can do weird things like run special DHCP servers, and continue to experiment.

I did enjoy my brief stint with Kea, and still plan to create some posts about my setup. I won't be tearing it down, but I will be re-deploying dns01 and dns02 as Ubuntu 22.04 machines.

Now that I'll have working "slightly-delayable" DHCP, it opens the door for getting Foreman PXE deployments going at home. Yay!

Here's quick bit of neatness: exporting my Technitium settings from dns01, and importing them into dns03 (which will become dns01)...

Within Settings -> General, click Backup Settings...

A popup appears, which asks which items you want to backup:

Click Backup.

Restoring was just as easy. Logged into dns03, went to the same section and selected Restore Settings instead, and...

Success. dns03 is now "dns01" in everything but network configuration, and I even got to keep my statistics and pretty pretty graphs.

I did lose my DHCP configuration, which makes sense because it only existed on dns03 before and was overwritten when I restored from the backup. However, I was able to immediately enable the previously-broken settings from dns01.

Perhaps I'm being a bit too brave, but... rm -rf dns01 --yes-i-really-mean-it

A quick edit to networking and a hostname change later:

wings@dns03:~$ sudo nano /etc/netplan/00-installer-config.yaml
wings@dns03:~$ sudo nano /etc/hosts
wings@dns03:~$ sudo hostnamectl set-hostname dns01.windowpa.in
wings@dns03:~$ sudo reboot
Connection to 10.1.2.5 closed by remote host.
Connection to 10.1.2.5 closed.

And dns01 is reborn!

wings:~/ $ ssh 10.1.2.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:DFjYMlhKPvmtzETRzOP2Iw3HmJJW8yPW3ipWGaclDFM.
Please contact your system administrator.
Add correct host key in /Users/wings/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /Users/wings/.ssh/known_hosts:105
Host key for 10.1.2.1 has changed and you have requested strict checking.
Host key verification failed.

Indeed, it is possible a host key has just been changed. Time to edit ~/.ssh/known_hosts and remove the old keys.

After connecting to the new machine and making sure everything was okay, I tested forcing a machine in my network to get new addresses (hint - dhclient -r && dhclient -v).

Happily, the machine was listed with its lease.

Might as well convert it to a reserved lease, no?

Let's see what happened with dynamic DNS 🤔

Well, that's less than ideal. rad01 was updated in DNS, but with its full hostname. Surely that means...

wings:~/ $ ping rad01.windowpa.in.windowpa.in                         [6:08:46]
PING rad01.windowpa.in.windowpa.in (10.1.1.3): 56 data bytes
64 bytes from 10.1.1.3: icmp_seq=0 ttl=64 time=10.140 ms

Ah. Easy enough to correct - just strip the hostname to not be a FQDN.

root@rad01:~# cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	rad1.windowpa.in	rad1

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root@rad01:~# cat /etc/hostname
rad01.windowpa.in
root@rad01:~# echo "rad01" >> /etc/hostname

Had to do a bit of poking in Technitium to get the lease to match the new hostname. Regardless, here it is;

And in DNS:

Which means...

wings@torrent:~$ ping rad01
PING rad01.windowpa.in (10.1.1.3) 56(84) bytes of data.
64 bytes from rad01.windowpa.in (10.1.1.3): icmp_seq=1 ttl=64 time=0.962 ms

Dynamic DNS is fully working!

Join me next time as I setup Foreman DHCP and deploy some things.