Setting up a Dynamic DNS Service

[patris_70]

http://blogs.techrepublic.com.com/opensource/?p=751&tag=rbxccnbtr1

PART 1 - Named


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 192.168.10.0 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 127.0.0.1 port 953

    allow { 127.0.0.1; } 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 "168.192.in-addr.arpa" {

        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 192.168.0.0 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

[patris_70]

http://blogs.techrepublic.com.com/opensource/?p=751&tag=leftCol;post-751

PART 2 - DHCP


Last week, we looked at the beginnings of setting up a dynamic DNS service where one could connect any system to the network, have it provide a DHCP-delivered IP address, and automatically set up the forward and reverse DNS names for the system. In particular, the previous tip concentrated on configuring BIND, the DNS server.

In this final tip, we configure ISC’s DHCPd service, which will serve the DHCP-based IP addresses to clients and update the DNS records accordingly. Again, this setup is based on a CentOS 5.3 configuration, but with perhaps minor path changes, it will work on any Linux distribution. As well, in our previous example, we used the home network domain name “home.lan” and the IP address network 192.168.10.0.

The dhcpd configuration file is typically /etc/dhcpd.conf. This file provides all the runtime options to dhcpd, allows you to configure different options for different subnets, and allows you to assign static IP addresses based on the requesting system’s MAC address. Configuring dhcpd fully is beyond the scope of this tip, so we will concentrate primarily on the dynamic DNS related pieces.

At the top of /etc/dhcpd.conf, ensure the following keywords are defined:

 ddns-update-style interim;

ddns-updates on;

ddns-domainname "home.lan.";

ddns-rev-domainname "in-addr.arpa";

use-host-decl-names on;

allow client-updates;

allow unknown-clients;

include "/etc/rndc.key";

zone home.lan. {

        primary 192.168.10.2;

        key rndckey;

}

zone 168.192.in-addr.arpa. {

        primary 192.168.10.2;

        key rndckey;

}

What the above does is define a variety of options to enable dynamic DNS updates. It also defines our two DNS zones: the 192.168.0.0 reverse lookup zone and the home.lan domain name. Finally, it indicates to use the “rndckey” as defined in /etc/rndc.key (see part 1 for more details on the RNDC key), and indicates that the primary DNS server is 192.168.10.2 — the IP our named server is listening on. If the DHCP server is on the same system as the DNS server, you can use 127.0.0.1 instead; however, ensure that named is configured to listen on the IP address 127.0.0.1, port 53.

If you also configure static IPs to systems based on their MAC address, you can write host stanzas with hostname information. This ensures that regardless of what the connecting system reports as a hostname, it will use a specific pre-determined hostname. There are two ways this can be done, actually; the first is to define the host statement with the additional dynamic DNS options, such as:

 host tyr {

        hardware ethernet 00:0c:eb:20:dc:fe;

        fixed-address 192.168.10.1;

        option host-name "tyr";

        DDNS-hostname "tyr";

}

This tells dhcpd to map the hostname tyr.home.lan to the system with the specified MAC address. It will also statically assign the IP 192.168.10.1 every time, and also tells dhcpd to report the hostname as tyr to named when the system connects.

The other option is to define the above without the option host-name and DDNS-hostname keywords. Instead you can provide A and PTR records in your named zone files for this host.

Once both named and dhcpd are configured, restart both services. At this point you will be able to connect any system to the network, and if you watch the logs (such as /var/log/messages), you will see the “conversation” between named and dhcpd as dhcpd hands out IP addresses to client systems