Open Source

Setting up a dynamic DNS service part 1: named

Vincent Danen shows you how to configure the BIND side of a dynamic DNS service. When combined with DHCPd, you can create a system where a client obtains an IP via DHCP and will automatically have a DNS name assigned to it.

Running a home DNS server is not without its benefits. The same holds true for running a home DHCP server. The two together provide an easy way to reference individual systems using DNS names for the local network, and the ability to dynamically allocate local IP addresses as systems come and go. On Linux, there are a number of DNS and DHCP servers, but two that work hand-in-hand are ISC's BIND and DHCPd. Together, you can create a system where a client system obtains an IP via DHCP and will automatically have a DNS name assigned to it.

In other words, if you connect a laptop to the local network, you need do nothing more than configure it to use DHCP; once it has connected, any other computer in the network will be able to ping or connect to it by merely using its hostname. This is commonly known as dynamic DNS. In this tip I'll look at configuring the BIND side of a dynamic DNS service, and in a following tip I'll configure the DHCP side and put it all together. The configuration here is used on a CentOS 5.3 system, but with some potential path changes, it should work on any Linux distribution.

Configuring BIND for dynamic DNS service

To begin with, you must configure BIND by editing /etc/named/named.conf on most Linux distributions. Configuring BIND entirely is beyond the scope of this tip, so we'll concentrate on the bits required to make dynamic DNS work. This will assume you already have a local network set up; in this example the local domain name is "home.lan" and the network address space is the local network.

By default, most distributions create /etc/rndc.key as part of the installation, so ensure the following is in /etc/named/named.conf:

include "/etc/rndc.key";
controls {
    inet port 953
    allow {; } keys { rndckey; };

The /etc/rndc.key conf contains a single stanza suitable for both named and dhcpd that defines the key rndckey (double-check /etc/rndc.key to be sure; if the name there is different, use that instead of rndckey or rename it). If this file does not exist, it can be created by editing /etc/rndc.key and placing in the following contents:

key "rndckey" {
        algorithm       hmac-md5;
        secret          "[dns-keygen output]";

where the secret is created by the /usr/sbin/dns-keygen tool.

Returning to /etc/named/named.conf, your zone statements should look similar to this:

zone "home.lan" {
        type master;
        file "master/home.lan";
        allow-update { key "rndckey"; };
        notify yes;
zone "" {
        type master;
        file "reverse/168.192";
        allow-update { key "rndckey"; };
        notify yes;

This defines two zones: the home.lan zone and the reverse lookup zone for the network. The important bits to note here are that they are both of the type "master" and that the allow-update keyword contains the RNDC key to use (rndckey as previously defined). These tell named to allow updates if the appropriate key is provided. The zone files included are standard BIND zone files.

In the next tip, we will look at configuring the DHCP side of our project.

Get the PDF version of this tip here.

Delivered each Tuesday, TechRepublic's free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!


Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks