LogoopenSUSE Build Service > Projects
Sign Up | Log In

View File DDNS-howto.txt of Package dhcp.219 (Project openSUSE:12.1:Update)

The ISC DHCP server v3 supports dynamical DNS updates (DDNS), as do BIND8/9.
There are several standards in the works; for now the best way to do it seems
to be updates done by the DHCP server only (not by the clients themselves).

Short outline of how things work together:
  - DHCP clients send their preferred hostname along the request
  - dhcpd acknowledges the lease 
  - dhcpd contacts named, asking it to update the zone, using an HMAC-MD5 key
    (TSIG, short for transaction signature) for authentication 
  - named updates the zone (and rewrites the zone files periodically)
  - when the lease times out or is freed, named will remove it 

The following instructions should get you started.
They are basically taken from the dnskeygen and dhcpd.conf man pages.



1. Make a key to be used by dhcpd to authenticate for DNS updates. 
You can use the script /usr/bin/genDDNSkey which essentially runs BIND's key
generating utility, extracts the secret from the K*.private key file and puts
it into the file /etc/named.keys. File name and key name can be specified on
the commandline, or via shell environment. Install the bind-utils package if
you don't have the script, or get it here: <http://www.suse.com/~poeml/genDDNSkey>. 
Call genDDNSkey --help for usage info. 

The simplest example to use it is:

	genDDNSkey

which is equivalent to 

	genDDNSkey --key-file /etc/named.keys --key-name DHCP_UPDATER

thereby using the defaults that fit the rest of this readme.

The script works both for BIND8 and BIND9 (some subtle difference in the syntax).


2. Configure dhcpd:

/etc/dhcpd.conf needs these additional lines:

	-------------------->
        ddns-updates      on;
        ddns-update-style interim;
        ignore client-updates;

        include "/etc/named.keys";
	<--------------------

and in the subnet declaration:

	-------------------->
        subnet 192.168.0.0 netmask 255.255.255.0 {
                range dynamic-bootp 192.168.0.201 192.168.0.219;

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

        }

	<--------------------

Note that this setup implies that the DNS server runs on the same machine
(127.0.0.1), but you can easily change that.

Since the DHCP server runs in a chroot jail by default, the key file needs to
be copied into the jail because dhcpd cannot files outside it (thanks Andrew
Beames for pointing this out!). This can easily be achieved by adding 
	/etc/named.keys
to the value of DHCPD_CONF_INCLUDE_FILES in /etc/sysconfig/dhcpd, which can be
done via YaST, or via any editor. 



3. Configure named:

Append something along these lines to /etc/named.conf:

	-------------------->
        include "/etc/named.keys";

        zone "whirl" in {
                type master;
                file "dyn/whirl.zone";
                allow-update { key DHCP_UPDATER; };
        };
        zone "0.168.192.in-addr.arpa" in {
                type master;
                file "dyn/0.168.192.zone";
                allow-update { key DHCP_UPDATER; };
        };
	<--------------------

Since named runs, by default, in a chroot directory since SuSE 8.2, we need to add 
	/etc/named.keys 
to the value of NAMED_CONF_INCLUDE_FILES in /etc/sysconfig/named, just as we
did it with dhcpd.

Since named runs, by default, as user "named" since SuSE 8.2, there is another
issue to be sorted out: named needs to create its .jnl files somewhere, but it
isn't allowed to do that in its working directory (/var/lib/named) for security
reasons. See /usr/share/doc/packages/bind9/README.SuSE for a solution.


if you got this far, there is a reasonable chance that you've got DDNS working.
Obviously, you need some zone files :) One further note: if you provide dummy
hostnames like d1, d2, d3,... for the dynamical clients they will have a
hostname even if they don't send a hostname (and no DDNS update is done).

If it doesn't work, closely watch /var/log/messages. In almost all cases the
messages give the right clues.

Feedback is appreciated. 

Have fun, 
Peter
-- 
Thought is limitation. Free your mind.