Setting up DHCP with Dynamic DNS (Linux Servers)

Throughout my time tinkering in home lab, I have come across a problem. I am having trouble remembering all these IP Addresses. But thankfully, a solution to this already exists. DNS. However, How can I get my home labs DNS records to update automatically with our DHCP server? We can do this with Dynamic DNS. Today I will be showing you how I did this.

We will be doing this with 2 Linux servers. One will be our DNS server, the other will be our DHCP server. I have disabled DHCP on my router.

Firstly, we want the DHCP server and DNS server to make changes securely. To do this, we generate a key using ddns-confgen. You must save this output into a file. I saved it in /etc/bind/ and named the file dhcp1.

On top of that, I also renamed the key to dhcp1

Now, let’s set up the DNS server. I’ve named this one NS1. We need to install bind9.

Run sudo apt install bind9. Since I have already installed it, I get a message saying bind9 is already the newest version.

Upon installation, there will be a new directory in your /etc folder. This is where the bind9 configuration files will be. Let’s walk through what each one does. If you are using a distribution of Linux that is NOT Ubuntu, the configuration files are probably somewhere else.

The named.conf file is the main config file for bind. This file simply references other configuration files.


The named.conf.options file contains options for your DNS server such as enabling dnssec-validation, what IP addresses to listen on, recursion settings, access control lists, etc. For example, in this specific set up, I have set up an access control list (at the very top) that only allows localhost, localnets, and 192.168.1.0/24 (my home labs network.)

From there, I can now specify this ACL, anywhere else, making it easier for managing this DNS server as my homelab grows. I would only have to update one file instead of updating multiple files if my network ever grows.

The named.conf.options file contains options for your DNS server such as enabling dnssec-validation, what IP addresses to listen on, recursion settings, access control lists, etc. For example, in this specific set up, I have set up an access control list (at the very top) that only allows localhost, localnets, and 192.168.1.0/24 (my home labs network.)

The named.conf.local file is used for configuring local zones. Here we specify our forward and reverse lookup zones, as well a the file path to the files containing the configuration of those zones. I have also allowed dhcp1 to update our DNS server for both zones. I have also included the file path to the key our DHCP server will use to securely update this DNS server.

Now, switching over to the /var/lib/bind directory, here is where our zone files live. I have placed these here as it is more secure. the files with the .jnl appeared after the DHCP server was able to successfully update the DNS server.

db.168.192 is our reverse DNS (PTR) for our home lab. This file contains PTR records mapping IP addresses to domain names. The entries you see like device-0004, kali.templab.lan, were added in here by my DHCP server. You can also manually update this file if you’d like.

db.templab.lan is our forward lookup zone file. it contains the A records for our domain.

Now, on our DHCP server (Cent OS), the main configuration file we want to look at is dhcpd.conf. This file includes configurations like lease time, subnets, ddns configurations, etc. In this file we want to include the key we generated on our DNS server. So we specify the file path at the top.

Now let’s make sure we save that file on the server as well. I created a directory in /etc/dhcp called ddns-keys and stored the key in there, just like we specified in the dhcpd.conf file.

After making these changes, you must sudo systemctl restart dhcpd (for centOS). Everything should be working properly. Lets check the logs.

Here we can see that our DHCP server successfully handed out a lease to device5174. And after that, we can see it also added a forward and reverse map to the device. Let’s check the logs on our DNS server.

Here we can see our DNS server successfully updated the zone files with the IP and host name of the device that our DHCP server just gave a lease to. Now let’s check if DNS actually works.

I am on my laptop now connected to my home lab network. (192.168.1.0/24)

Lets use dig to find out. In the answer section, we can see it resolves to the correct IP address. Let’s try the reverse.

To do the reverse we use dig -x <ip address>. Here in the answer section we can see it correctly resolves as well.

Implementing this has made navigating my homelab a lot easier, and on top of that, makes it even more obvious as to why DNS was invented in the first place. Nobody would remember anything by IP address.

Leave a Reply

Your email address will not be published. Required fields are marked *