Make your DHCP server dynamically update your DNS records on Ubuntu Hardy Heron

Information
The steps in this post shows how to configure the DHCP server to automatically update the DNS records when giving out a new lease to a client computer. All on the Ubuntu Hardy Heron server.

Before continuing
These steps assumes that you already have a working copy of dhcp3-server and bind9 installed. If you don’t have that I suggest that you first read my two other posts on how to install them:

Setting up a DNS for the local network on the Ubuntu Hardy Heron server
Setting up a DHCP server on Ubuntu Hardy Heron

Step by step instructions

1. Move the files to a directory that bind can write to

Apparently the Ubuntu server is installed with an AppArmor profile that prevents bind to write to the /etc/bind directory. The default profile suggests that these files should be put in /var/lib/bind. If you have followed the steps in my previous post you might have your zone database files in /etc/bind/zones. We will start by copying the files so we have a backup remaining if anything goes wrong:

1.1 Copy the zone database files:

sudo cp /etc/bind/zones/* /var/lib/bind/

1.2 Change the owner and group of the files to bind, so that bind will have file permissions that allows it to write to the files:

sudo chown bind:bind /var/lib/bind/*

2. Create a secret shared between the DHCP server and the DNS

We don’t wont anybody to be able to update our DNS, so we need to create a secret, a key, that the DCHP server must know in order to be able to update the DNS.

2.1 Generate a new key:

sudo dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER

2.2 Show the generated key:

sudo cat Kdhcp_updater.*.private|grep Key

2.3 Now copy the key to the clipboard so that you can paste it into the configuration file later on.

3 Configure the DNS

We now need to add the key to the bind configuration and tell it what zones that we want it to allow updates on. I’ve included the whole contents of my file here and marked the changes that I’ve made in bold.

3.1 Edit /etc/bind/named.conf.local:

sudo nano /etc/bind/named.conf.local

3.2 Changes are marked with bold:

# The secret key used for DHCP updates.
key DHCP_UPDATER {
    algorithm HMAC-MD5.SIG-ALG.REG.INT;

    # Important: Replace this key with your generated key.
    # Also note that the key should be surrounded by quotes.
    secret "asdasddsaasd/dsa==";
};

zone "home.lan" {
    type master;

    # Change the path of the database file to the writable copy in /var/lib/bind
    file "/var/lib/bind/home.lan.db";

    # Tell this zone that we will allow it to be updated from anyone
    # that knows the secret specified in the DHCP_UPDATER key.
    allow-update { key DHCP_UPDATER; };
};

zone "10.10.10.in-addr.arpa"  {
    type master;

    # Change the path of the database file to the writable copy in /var/lib/bind
    file "/var/lib/bind/rev.10.10.10.in-addr.arpa";

    # Tell this zone that we will allow it to be updated from anyone
    # that knows the secret specified in the DHCP_UPDATER key.
    allow-update { key DHCP_UPDATER; };
};

4 Configure the DHCP server to send updates to the DNS

4.1 Edit dhcpd.conf:

sudo nano  /etc/dhcp3/dhcpd.conf

4.2 Changes are marked with bold:

#
# Make sure to change the ddns update style to interim:
ddns-update-style interim;
ignore client-updates;      # Overwrite client configured FQHNs
ddns-domainname "home.lan.";
ddns-rev-domainname "in-addr.arpa.";

# option definitions common to all supported networks...
option domain-name "home.lan";
option domain-name-servers ubuntu.home.lan;

default-lease-time 600;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

key DHCP_UPDATER {
    algorithm HMAC-MD5.SIG-ALG.REG.INT;

    # Important: Replace this key with your generated key.
    # Also note that the key should be surrounded by quotes.
    secret "asdasddsaasd/dsa==";
};

zone home.lan. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

zone 10.10.10.in-addr.arpa. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

# This is a very basic subnet declaration.
subnet 10.10.10.0 netmask 255.255.255.0 {
  range 10.10.10.100 10.10.10.200;
  option routers router.home.lan;
}

5 Tighten the permissions on the configuration files

The configuration files now contains our secret key. We should not let just anyone read our secret key, so lets remove the general read rights from them:

sudo chmod o-r /etc/bind/named.conf.local
sudo chmod o-r /etc/dhcp3/dhcpd.conf 

We should now have a fully working dynamic dns system for our local network, lets hold our thumbs and restart the services.

6 Restart the services to reload the configuration.

sudo /etc/init.d/bind9 restart
sudo /etc/init.d/dhcp3-server restart

7 Testing the setup

7.1 If you have an Ubuntu client that uses DHCP you can restart its network to make the DHCP-client request a new ip-address from the server:

sudo /etc/init.d/networking restart

7.2 You should now be able to lookup your client computer in your DNS:

host lani-desktop

Result:
lani-desktop.home.lan has address 10.10.10.100

7.3 And the reverse should now also work for your client computer address:

host 10.10.10.100

Result:
100.10.10.10.in-addr.arpa domain name pointer lani-desktop.home.lan.

8 Cleanup

8.1 Remove the generated key files:

 sudo rm Kdhcp_updater.*

8.2 Remove the old zone db files:

sudo rm -R /etc/bind/zones

Done

Some “important” pointers

Database files being rewritten by bind
The dns database files are now being rewritten by the bind service. Some people have mentioned that they think that bind messes up these files so that they are impossible to maintain. I don’t think that they are that bad and personally I don’t have any problem editing them after that bind has rewritten them. I’m not sure how often that bind rewrites these files, but at least it seems to always happen when you stop the bind service. What I think is more important is to always stop the bind service before making any changes to the database files, otherwise they might be overwritten by bind.

Examples of how to stop and start the bind service:

sudo /etc/init.d/bind9 stop
sudo /etc/init.d/bind9 start

The only way that I can think of to avoid this problem is to split your domains into two sub domains, for example dyn.home.lan. and static.home.lan. You could then have the DCHP server to only update the dyn.home.lan domain. But I didn’t want this and I’m not going to update these files that often that it matters for me. Please let me know if you know of a better solution.

Key generation
When using the dnssec-keygen to generate the secret key I passed it the parameter “-r /dev/urandom”. I’ve seen some pointers about that this will generate a less secure key. But for me the dnssec-keygen would just halt without that parameter. One other suggestion that I’ve seen it that you should switch to another terminal window on the server and run some commands that make some work on the server, to make it fill up the default /dev/random. I think that I would have done this if I would set this up in a corporate environment. But for my own home network I really think that the /dev/urandom will be sufficient.

Troubleshooting
There must be many more ways to troubleshoot any problems. But I managed to get it working by checking the system log for clues when a service didn’t start or when the DHCP server didn’t update the DNS records:

tail /var/log/syslog

That’s it!
I’ve really tried to make these steps as accurate as possible, following my own steps to get this to work. Please let me know if you think that I’ve missed something. Thank you.

About these ads