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>.
First, install DHCP by issuing:
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:
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.
The lines in the dhcpd.conf file above that enable DHCP to update the bind server are the lines reproduced below:
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:
or type in the key itself, something like this:
Ensure named.conf also have specification to set up how the control channel will be treated:
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:
That should be it for named.conf!
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.
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:
Start the bind server by issuing the command:
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:
You can see that there's no signs of error here. Next follows an example showing an error:
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:
Here's an example of dhcpd.leases showing an error:
@@tail -f /opt/etc/dhcp.leases
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.
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:
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.