This how-to describes how to create a working DHCP/Dynamic DNS server on an Unslung Linksys NSLU2 server.

A prerequisite for this document is that you have set up and tested as working a primary DNS server as described in BuildPrimaryDNSServer. This document picks up where the BuildPrimaryDNSServer document leaves off, using almost the same DNS configuration files.

Please update here or send questions to Lee Kimber <lee atnospam kimberconsulting dot com>.

Installation

First, install DHCP by issuing:

ipkg install dhcp

Configuration

We need a key for the rndc service. This service is the control channel that DHCP will use to communicate with the DNS daemon. The key is a unique token that bind will use to 'trust' zone file changes initiated by DHCP. How to create this key was detailed in BuildPrimaryDNSServer. The process should leave you with a file called rndc.key in /opt/etc/named/.

Its contents will look something like this:

key "rndc-key" {
algorithm hmac-md5;
secret "VDHtbx5AHIeDCYmTPd9HA?==";
};

Before moving on, make sure this file is present and that its contents look something like the above.

Edit the DHCP configuration at /opt/etc/dhcpd.conf for your network. DHCP server configuration is widely described all over the Web, so this how-to won't duplicate them. Instead I have given my dhcpd.conf file below and described the lines that are relevant to making DHCP work with dynamic DNS.

vi /opt/etc/dhcpd.conf

# dhcpd.conf
#
# option definitions common to all supported networks...
option domain-name "leedomain.com";

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

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
ddns-update-style interim;

key "rndc-key" {
algorithm hmac-md5;
secret "VDHtbx5AHIeDCYmTPd9HA?==";
};

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
zone leedomain.com {
primary 192.168.1.79;
key rndc-key;
}

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.79;
key rndc-key;
}

# 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;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

subnet 192.168.2.0 netmask 255.255.255.0 {
}

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.2 192.168.1.25;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.79, 192.168.1.1;
}

The lines in the dhcpd.conf file above that enable DHCP to update the bind server are the lines reproduced below:

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
ddns-update-style interim;

key "rndc-key" {
algorithm hmac-md5;
secret "VDHtbx5AHIeDCYmTPd9HA?==";
};

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
zone leedomain.com {
primary 192.168.1.79;
key rndc-key;
}

# per Matt at: http://www.mattfoster.clara.co.uk/ddns.htm(approve sites)
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.79;
key rndc-key;
}

They tell the DHCP server which DDNS update method we are using (namely, 'interim').

The next set of lines provides the DHCP server with the rndc key that bind is using to validate control channel requests.

The two zone specifications tell DHCP which DNS server it should notify its IP address allocations to.

And, of course, they credit Matt Foster, who is apparently the first person on the Internet to have written a clear how-to on this aspect of DDNS!

If the bind server is configured with the named.conf file described in BuildPrimaryDNSServer, we are ready to start the DHCP and bind servers and test. If you have significantly changed your named.conf file, the key lines to ensure are present are:

To make sure bind has an agreed rndc key, ensure named.conf either has a line like:

include "/opt/etc/named/rndc.key";

or type in the key itself, something like this:

key "rndc-key" {
algorithm hmac-md5;
secret "VDHtbx5AHIeDCYmTPd9HA?==";
};

Ensure named.conf also have specification to set up how the control channel will be treated:

controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};

In named.conf's specifiations details about your zone files, make sure bind understands that the zone file may be modified by an application that uses the rndc key. In my named.conf, this is achieved with the lines:

allow-update { key "rndc-key"; };

For example:

zone "leedomain.com" {
type master;
file "db.leedomain.com";
allow-update { key "rndc-key"; };
notify yes;
};

zone "1.168.192.in-addr.arpa" {
type master;
file "db.192.168.1.rev";
allow-update { key "rndc-key"; };
notify yes;
};

That should be it for named.conf!

Testing

Before we restart bind, let's make sure we can monitor its start up and the messages issues when a client requests a DHCP address. First, make sure the bind server is off.

# /opt/etc/init.d/S09named stop
Shutting down DNS Services:

There are three files we can monitor as we first test our system and one directory where we should see changes as the system operates.

The three files are:

/var/log/leedomain.log (the bind logfile specified in our named.conf configuration above. Yours may have a different name!) /var/log/messages /opt/etc/dhcp.leases

You could open three ssh sessions to the server and monitor all three files in realtime while you have a client request a DHCP address. However, you get the most detailed troubleshooting information from /var/log/messages and /opt/etc/dhcp.leases, so I monitor just those two.

The directory where we should see changes if the system is working is /opt/etc/named/, where we should see journal files being written for zone files that are changed as a result of DHCP address allocations.

To test the DHCP server, open two ssh sessions to the server. Use each session to observe the DHCP logs and leases file set. To do this, set up a tail on each file.

In one session, tail the /var/log/messages file by issuing the following command: tail -f /var/log/messages

In the other session, tail the /opt/etc/dhcp.leases file by issuing the following command: tail -f /opt/etc/dhcp.leases

Reload the DHCP server by issuing the command: # /opt/etc/init.d/S56dhcp start

Start the bind server by issuing the command: # /opt/etc/init.d/S09named start

You should see any errors as each server loads its configuration files in the session where you are tailing the /var/log/messages file.

Assuming both servers load their configurations correctly and bind starts, bring up a client on the DHCP server's client network and configure it to receive its IP address details from DHCP. How you do this will depend on your client.

If the system is working correctly, we should see something like this in the /var/log/messages window:

tail -f /var/log/messages

<29>Aug 29 16:36:07 named[679]: starting BIND 9.3.1 -c /opt/etc/named/named.conf
<30>Aug 29 16:36:08 named[679]: loading configuration from '/opt/etc/named/named.conf'
<30>Aug 29 16:36:08 named[679]: no IPv6? interfaces found
<30>Aug 29 16:36:08 named[679]: listening on IPv4? interface lo, 127.0.0.1#53
<30>Aug 29 16:36:08 named[679]: listening on IPv4? interface ixp0, 192.168.1.79#53
<29>Aug 29 16:36:08 named[679]: command channel listening on 127.0.0.1#953
<190>Aug 29 16:38:00 dhcpd: DHCPDISCOVER from 00:50:8d:65:64:ef (desktopxp) via ixp0
<190>Aug 29 16:38:01 dhcpd: DHCPOFFER on 192.168.1.25 to 00:50:8d:65:64:ef (desktopxp) via ixp0
<190>Aug 29 16:38:01 dhcpd: Added new forward map from desktopxp.leedomain.com to 192.168.1.25
<190>Aug 29 16:38:01 dhcpd: added reverse map from 25.1.168.192.in-addr.arpa. to desktopxp.leedomain.com
<190>Aug 29 16:38:01 dhcpd: DHCPREQUEST for 192.168.1.25 (192.168.1.79) from 00:50:8d:65:64:ef (desktopxp) via ixp0
<190>Aug 29 16:38:01 dhcpd: DHCPACK on 192.168.1.25 to 00:50:8d:65:64:ef (desktopxp) via ixp0

You can see that there's no signs of error here. Next follows an example showing an error:

tail -f /var/log/messages

<190>Aug 29 14:55:46 dhcpd: DHCPDISCOVER from 00:50:8d:65:64:ef via ixp0
<190>Aug 29 14:55:47 dhcpd: DHCPOFFER on 192.168.1.25 to 00:50:8d:65:64:ef (desktopxp) via ixp0
<190>Aug 29 14:55:47 dhcpd: Added new forward map from desktopxp.leedomain.com to 192.168.1.25
<187>Aug 29 14:55:47 dhcpd: unable to add reverse map from 25.1.168.192.in-addr.arpa. to desktopxp.leedomain.com: not authorized
<190>Aug 29 14:55:47 dhcpd: DHCPREQUEST for 192.168.1.25 (192.168.1.79) from 00:50:8d:65:64:ef (desktopxp) via ixp0
<190>Aug 29 14:55:47 dhcpd: DHCPACK on 192.168.1.25 to 00:50:8d:65:64:ef (desktopxp) via ixp0

Obviously, the line beginning 'error 187' in the /var/log/messages file tells us that this the the log that will highlight specific problems with DDNS. In the above case, the error was that the db.1.168.192.in-addr.arpa zone file was not specified in named.conf and therefore had no 'notify-updates' specification.

If the system is working correctly, the /opt/etc/dhcpd.leases file should show something like this:

# tail -f /opt/etc/dhcpd.leases

lease 192.168.1.25 {
starts 2 2006/08/29 16:34:05;
ends 2 2006/08/29 16:44:05;
binding state active;
next binding state free;
hardware ethernet 00:50:8d:65:64:ef;
uid "\001\000P\215ed\357";
client-hostname "desktopxp";
}
lease 192.168.1.25 {
starts 2 2006/08/29 16:38:01;
ends 2 2006/08/29 16:48:01;
binding state active;
next binding state free;
hardware ethernet 00:50:8d:65:64:ef;
uid "\001\000P\215ed\357";
set ddns-rev-name = "25.1.168.192.in-addr.arpa.";
set ddns-txt = "31b5102c1061bd8025d5cfd5406e924bef";
set ddns-fwd-name = "desktopxp.leedomain.com";
client-hostname "desktopxp";
}

Here's an example of dhcpd.leases showing an error:

@@tail -f /opt/etc/dhcp.leases

 
lease 192.168.1.25 { 
  starts 2 2006/08/29 14:55:47; 
  ends 2 2006/08/29 15:05:47; 
  binding state active; 
  next binding state free; 
  hardware ethernet 00:50:8d:65:64:ef; 
  uid "\001\000P\215ed\357"; 
  set ddns-txt = "31b5102c1061bd8025d5cfd5406e924bef"; 
  set ddns-fwd-name = "desktopxp.leedomain.com"; 
  client-hostname "desktopxp"; 
} 
lease 192.168.1.25 { 
  starts 2 2006/08/29 15:00:44; 
  ends 2 2006/08/29 15:10:44; 
  binding state active; 
  next binding state free; 
  hardware ethernet 00:50:8d:65:64:ef; 
  uid "\001\000P\215ed\357"; 
  set ddns-txt = "31b5102c1061bd8025d5cfd5406e924bef"; 
  set ddns-fwd-name = "desktopxp.leedomain.com"; 
  client-hostname "desktopxp"; 
}@@

The error is that it did not set a reverse pointer record.

Both the /var/log/messages and the /opt/etc/dhcpd.leases files that show errors are showing reverse name record errors, although the /opt/etc/dhcpd.leases file error is hard to see because when things go wrong it simply doesn't write the line showing the record was set!

We should also see that the system has added DNS zone journal files to the collection of zone files we created in /opt/etc/named/ directory.

# ls /opt/etc/named/
db.192.168.1.rev db.leedomain.com.jnl db.localhost.rev rndc.key
db.leedomain.com db.localhost named.conf root.servers

In the listing above, we can see that we have a journal file for db.leedomain.com called db.leedomain.com.jnl. Worryingly, we don't have a journal file for the db.192.168.1.rev file. This is because, as our /opt/etc/dhcpd.leases and /var/log/messages files showed, something went awry with updating the reverse pointer record.

You can check your zone files for the records that bind added after receiving notification of the IP address allocation from the DHCP server. In the case above, the db.leedomain.com and db.192.168.1.rev files will contain the extra entries.

If you have set your bind server to log to a separate file from the system file, you may find other errors in that log which will be worth hunting down. If your bind server logs its messages to /var/log/messages, then check that file instead. Two other errors I have seen are:

1.Unsuccessful write due to 'failed rollover' of journal file (caused where I had manually modified a zone file, which brought it out of sync with that zone file's journal file), and 2. update unsuccessful: desktopxp.leedomain.com: 'name not in use' prerequisite not satisfied.

It is worth scanning these log files for signs of problems even though they aren't exactly thrilling to read.

A separate bind log might show something like the following:

tail -f /var/log/leedomain.log

29-Aug-2006 11:57:41.746 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 2006080801
29-Aug-2006 11:57:41.756 general: info: zone 1.168.192.in-addr.arpa/IN: loaded serial 2006080801
29-Aug-2006 11:57:41.766 general: info: zone leedomain.com/IN: loaded serial 2006080801
29-Aug-2006 11:57:41.774 general: info: zone localhost/IN: loaded serial 2006080801
29-Aug-2006 11:57:41.793 general: notice: running
29-Aug-2006 11:57:41.795 notify: info: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2006080801)
29-Aug-2006 14:55:47.003 update: info: client 192.168.1.79#1027: updating zone 'leedomain.com/IN': adding an RR at 'desktopxp.leedomain.com' A
29-Aug-2006 14:55:47.011 update: info: client 192.168.1.79#1027: updating zone 'leedomain.com/IN': adding an RR at 'desktopxp.leedomain.com' TXT
29-Aug-2006 14:55:47.012 general: info: journal file db.leedomain.com.jnl does not exist, creating it

Test from a separate Linux box

If the client's DHCP request went off all right you should see no errors. The client should be able do to the things the DHCP server gave it the ability to do – show an IP address, show a gateway IP address, perform DNS resolution.

Now check that the bind server is resolving the IP addresses of client names where the client received their IP information from the DHCP server. Fire up a Linux client, either using the DHCP server or using static IP and run a dig test against the DNS server for a local client name. If DHCP successfully updated bind, the bind server should return the correct IP address for the client.

How to use dig to do this was described towards the end of the BuildPrimaryDNSServer how-to.

If it resolves, then your configuration is complete.

This documents my first try at integrating DHCP and DNS so I'd appreciate more tips, techniques for increasing its efficiency and more testing techniques. Since I began running the above system I have discovered that the new client adds and deletes are not written to Bind's zone files immediately. Such new changes appear to be stored in the *.jnl files until - I think - the five minute TTL in the zone's record expires.

Also, as a result of running this, I've come to understand more about how Bind zone files actually work and am currently testing various modifications to the the zone files I used in BuildPrimaryDNSServer to see what helps operation and clarity.