$Id: secure-ddns-howto.html,v 1.65 2002/03/17 22:52:50 jakob Exp $

Secure dynamic DNS howto

Table of contents

1. Introduction


This text was produced at the DNSSEC/DYNUPD workshop hosted by the RIPE NCC. The workshop took place at the Grand Hotel Krasnapolsky in Amsterdam, the Netherlands, between January 21-24, 2002.

Participants and authors:
Brian Wellington, Daniel Massey, David Blacka, Ed Lewis, Jaap Akkerhuis, Jakob Schlyter, Johan Ihrén, Lars-Johan Liman, Mark Kosters, Olaf Kolkman, Randy Bush, Roy Arends, Scott Rose, Ted Lemon, Ted Lindgreen and Wesley Griffin.

This document only covers use with ISC's BIND 9 and DHCP software. If anyone can help with examples using other products that use the same standards, we would be delighted to include them. Send text <tm>.

Why Dynamic Update?

Dynamic update proposes to provide a workable solution to the seemingly trivial operation of exchanging data between two computers with known names both visiting a foreign network where we don't know, care or trust the underlying address. This feature has long been available for specific platforms, but a general OS-agnostic method has been lacking.

We now have a more or less ubiquitous availability of DHCP, increasing use of TSIG in the DNS infrastructure and a renewed interest in getting DNSSEC deployed. Therefore it seems possible to to, in a secure fashion, both publish and consume locally available information via appropriate application protocols (ftp, http, whatever).

To put it simply, it is now possible to point your neighbour at the IETF conference to a web page on your laptop by pointing at the URL on your business card.

Why Secure Dynamic Update?

Secure dynamic update in this context covers the entire chain from the client initiated update (protected by a TSIG or SIG(0) signature) via the automatic resigning of the updated records (via online DNSSEC keys) in the zone to the final server synchronization via update of the serial number and slave notification and subsequent IXFRs.

Dynamic update of a zone and DNSSEC signing of a zone are orthogonal concepts. However, since both require modern software and both require key management the additional cost of full DNSSEC for such a zone becomes marginal and is therefore a good idea.


Please send comments on this document to dnsop@cafax.se.

2. Configuring the Forward Zone


There are three steps to configure dynamic updating of the forward zone, which are divided into the three following sections:

  1. Decide on which keying method you will use
  2. Configure the server
  3. Configure the client

Once these three steps have been completed, the next section discusses how to test the dynamic update setup.

Software Requirements


You have to choose one of two different key types to use to secure the dynamic update: TSIG keys and SIG(0) keys.


TSIG keys are symmetric HMAC-MD5 keys.

Generating TSIG Keys

TSIG keys are generated with the following command:

$ dnssec-keygen -a HMAC-MD5 -b 512 -n HOST <keyname>

<keyname> is the name of the key and can be virtually anything that is formatted as a DNS name. It is recommended that the keyname be the fully qualified domain name of the host so that the update-policy self works correctly. (see Section of the BIND ARM for more information on update-policy).

The key will be stored in the file K<keyname>+157+<keyid>.private

<keyid> is the unique id of the key.

This file will not be used directly by anything, and the key is the string after the Key: line in the file (See the next step, Configuring the DNS Server).

One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy.

One solution to feed more entropy to the system is to generate it by creating system activity. In another window you can compile a kernel, visit websites, etc. What precisely you should do depends on the operating system and how it was compiled, but generally anything involving keyboard I/O will work.

A less secure, and not recommended, solution to this is to use the -r <randomdev> parameter that allows you to specify another random device, such as /dev/urandom. This is not recommended, because the /dev/urandom device does not guarantee the data to be strong and will continue to output data even when the entropy has been exhausted.

SIG(0) Keys

SIG(0) keys are asymmetric key-pairs. There is a public key and a private key forming a SIG(0) key-pair. They can be of any of the asymmetric key algorithms (RSAMD5, RSASHA1, DSA).

Generating SIG(0) Keys

SIG(0) keys are generated with the following command:

$ dnssec-keygen -a <keyalg> -b <keysize> -n HOST <keyname>

<keyalg> is the desired algorithm of the key and can be any of the following values: RSAMD5, RSASHA1, DSA. We recommend that you use RSAMD5.

<keysize> is the desired size in bits of the key and the ranges are different depending on the algorithm:

<keyname> is the name of the key. Since it must be published in the zone file, it should be a subname of the zone that it is being published in. It is recommended that the keyname be the fully qualified domain name of the host so that the update-policy self works correctly. (see Section of the BIND ARM for more information on update-policy).

The key will be stored in the file K<keyname>+<keyalg>+<keyid>.private

<keyid> is an identity tag to be able to differentiate between different keys under the same name.

There will also be a corresponding K<keyname>+<keyalg>+<keyid>.key file that contains a DNS KEY resource record formatted for inclusion in the zone file.

One possible problem that can be encountered with dnssec-keygen is that it might use up all the entropy in /dev/random before it is done generating the key. This will make dnssec-keygen appear to hang, when in fact it is simply waiting for more entropy. One solution to this is to use the -r <randomdev> parameter that allows you to specify another random device, such as /dev/urandom.

Configuring the DNS Server

Configuring the server also depends on which type of key you choose.


The /etc/named.conf file must be edited to configure the server for dynamic update.

The first step is to configure the server to use the key. This is accomplished with the following lines in the /etc/named.conf file:

key <keyname> {
    algorithm HMAC-MD5;
    secret "<keydata>";

<keyname> is the name of the key chosen when the key was generated (See the previous step, Generating TSIG keys).

<keydata> is the string after the Key: line in the generated key file (See the previous step, Generating TSIG keys).

SIG(0) Keys

Only the zone file must be edited to configure the server for dynamic update with sig(0). No changes are needed in /etc/named.conf as the client's public, not private, key is in the zone file.

The first step is to add the generated key, using the K<keyname>+<keyalg>+<keyid>.key file, to the zone file. This generated key file contains a properly formatted resource record that can be simply copy-and-pasted into the zone file.

If you are using DNSSEC signed zones, then the next step is to resign your zone.

Allowing Updates

The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:

update-policy {
    grant <keyname> name <hostname> A TXT;


zone "example.com" {
    type master;
    file "master/example.com";

    update-policy {
        grant foo.example.com. name foo.example.com. A TXT;

Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:

update-policy {
    grant host1.example.com. name host1.example.com. A TXT;
    grant host2.example.com. name host2.example.com. A TXT;
    grant host3.example.com. name host3.example.com. A TXT;
    grant host4.example.com. name host4.example.com. A TXT;
    grant bofh.example.com. subdomain example.com. ANY;

Simple example where every key can update the A+TXT records of its matching hostname:

update-policy {
    grant * self * A TXT;

Note: update-policy is described further in Section of the BIND ARM.

The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.

allow-update {
    key <keyname>;

<keyname> is the name of the key chosen when the key was generated (See the previous step, Keys)

Configuring the DHCP Client

There are also two ways to configure the client:

These two options are mutually-exclusive, i.e., you can use either the built-in dhclient updater or the dhclient-exit-hooks script, but you cannot use both at the same time.

Using the Built-in dhclient Updater

The built-in dhclient updater only supports TSIG keys, so if you've chosen to use SIG(0) keys, you must use the dhclient-exit-hooks script.

The dhclient.conf file must be edited to configure the client for dynamic update using the built-in dhclient updater.

The first step is to configure the dhclient with the fully qualified domain name of the client along with some other dynamic update options. This is accomplished by placing the following lines in the dhclient.conf file:

send fqdn.fqdn "<client-fqdn>";
send fqdn.encoded on;
send fqdn.server-update off;

<client-fqdn> is the fully qualified domain name (including the trailing dot) of the client.

The second step is to configure the dynamic update key and zone. This is accomplished with the following lines in the dhclient.conf file:

key <keyname> {
    algorithm HMAC-MD5;
    secret "<keydata">;

zone <zone-fqdn> {
    key "<keyname>";

<keyname> is the name of the key chosen when the key was generated (See previous step, Generating TSIG keys).

<keydata> is the string after the Key: line in the generated key file (See previous step, Generating TSIG keys).

<zone-fqdn> is the zone that will receive the dynamic update. Note that the closing } on the zone statement does not have a ; after it.

Using the dhclient-exit-hooks Script

dhclient allows for external events to be called via scripts placed in certain locations. See the man page on dhclient-script(8) for details. In this example, we use /etc/dhclient-exit-hooks to invoke nsupdate.

dhclient does not need any specific configuration to enable use of the /etc/dhclient-exit-hooks script. If the script is present, and readable, then it will be automatically executed.

The dhclient-exit-hooks script uses nsupdate from the BIND distribution which must be available on the client machine. nsupdate supports both TSIG and SIG(0) keys.

If you're using TSIG keys and have decided to use the dhclient updater, then you must not use the dhclient-exit-hooks script.

The dhclient-exit-hooks script shown below can be used for both TSIG and SIG(0) keys, the only difference is which keyfile is specified. Both the .key and .private files of the generated keyfiles must be present in the same directory on the client for nsupdate to operate correctly.

nsupdate -v -k $KEYFILE > /dev/null << EOF
server $SERVER
zone $ZONE
update delete $HOSTNAME A
update add $HOSTNAME $TTL A $new_ip_address

<qd.ip.of.ns> is the IP address of the nameserver. The dns name of the nameserver (with a terminal dot) may be used instead of the name, but will require a name lookup first.

<zone-fqdn> is the zone that will receive the dynamic update.

<fully-qualified-client-hostname> is the fully qualified domain name of the client.

<generated-keyfile> is the filename of the .private generated keyfile including the directory (See previous section Keys).

TTL specifies the time to live of the updated records. [ NOTE: we need to probably discuss this somewhere ]

This script calls nsupdate, specifying -v to use TCP to send the dynamic update. The four lines "server...", zone...", update...", and update..." tell nsupdate what actions to perform on the specified zone at the specified server. The "send..." line tells nsupdate to finally send the query. See the nsupdate man page for more information.

No changes are needed to /etc/dhclient.conf other than:

send fqdn.fqdn "<client-fqdn>";
send fqdn.encoded on;
send fqdn.server-update off;

3. Configuring Reverse Zone

Assuming the use of TSIG to authenticate dynamic updates, three entities are involved in the updating of the "reverse map" zone corresponding to a DHCP server's IP allocations. The three entities are the DHCP server, the DHCP client, and the DNS server.

See the previous section Keys to generate TSIG keys.

Assuming the use of BIND's DNS implementation and ISC's dhcp (dhcpd and dhclient) implementation, three files need to be modified. The three files are /etc/named.conf (assuming default names of files), /etc/dhcpd.conf for the DHCP server, and /etc/dhclient.conf for the DHCP client.

The steps that need to be accomplished are:

  1. Configure the DHCP server and DNS server to use and require authenticated dynamic update messages.
  2. Configure the DHCP server to update the appropriate in-addr.arpa subzone each time that a lease is let or modified.
  3. Configure the DHCP client to give the DHCP server a domain name to insert in a PTR RR.
  4. Configure the DHCP client to prohibit the DHCP server from attempting to insert an A RR for the supplied name.

Step 1

This step is explained in detail elsewhere. What is needed is a shared secret (again, assuming TSIG) for to secure the messages between the DHCP server and DNS server. In /etc/named.conf, the key is needed, and granted the authorization to make prescribed changes. In /etc/dhcpd.conf, the DHCP server is also given the key (using the same syntax as in the /etc/named configuration file), and is configured to use the key. "Configured" means that there is a zone statement block, with the secret specified inside.

Configuration examples:

In /etc/named.conf:

key update.1.168.192.in-addr.arpa. {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

zone "1.168.192.in-addr.arpa" {
    type master;
    file "zones/1.168.192.in-addr.arpa";
    allow-update { key update.1.168.192.in-addr.arpa.; };

(Note that the use of allow-update may be too loose.)

In /etc/dhcpd.conf:

key update.1.168.192.in-addr.arpa. {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

zone 1.168.192.in-addr.arpa {
    key update.1.168.192.in-addr.arpa.;

To force dhcpd to send the update to a specific server, as opposed to searching the RRset of NS RRs, you can use the

    primary <ip address>;

sub-statement of the zone statement above.

Step 2

The DHCP server needs to be configured to perform updates. This is done by inserting one line in statement "ddns-update-style interim;". In /etc/dhcpd.conf:

ddns-update-style interim;

Step 3

In order for the DHCP server to know how to properly form the PTR RR inserted into the reverse map zone, the DHCP server either makes up a name or uses one supplied by the client. Assuming the DHCP client wants a specific name to be used, the DHCP client must be configured to submit a name to the the server. For example, a DHCP client wanting the name "hostname.example.com" is let the address, and will see this PTR RR appear: 3600 IN PTR hostname.example.com

This is done with the send fqdn.fqdn option in /etc/dhclient.conf:

send fqdn.fqdn "hostname.example.com.";
send fqdn.encoded on;

The last line, "encoded on" tells the DHCP client to transmit the domain name in the DNS protocol format. This item should always be set "on."

Step 4

Assuming that the DHCP client machine is going to alter the "forward map" zone (the A RR), the DHCP server should not attempt to do this. There are two reasons why the DHCP server should not attempt to update the forward zone - the effort may be redundant of an effort by the DHCP client, and the DHCP server may lack the authorization that the DHCP client has to do this.

To inform the DHCP server to not attempt the forward map update, the DHCP client specifies an option (setting). To make the DHCP client do this, in /etc/dhclient.conf:

send fqdn.server-update off;


In summary, the configurations shown above are summarized as this:

In /etc/named.conf:

key update.1.168.192.in-addr.arpa. {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

zone "1.168.192.in-addr.arpa" {
    type master;
    file "zones/1.168.192.in-addr.arpa";
    allow-update { key update.1.168.192.in-addr.arpa.; };

In /etc/dhcpd.conf:

key update.1.168.192.in-addr.arpa. {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

zone 1.168.192.in-addr.arpa {
    key update.1.168.192.in-addr.arpa.;

ddns-update-style interim;

In /etc/dhclient.conf:

send fqdn.fqdn "hostname.example.com.";
send fqdn.encoded on;
send fqdn.server-update off;

Setting the TTL used for A and PTR records updated by the DHCP client and server

The DHCP client currently sets the TTL to one half of the lease duration. This means that if the client's IP address changes during that period, any cached versions of the client's A record will be wrong. The DHCP server sets the TTL of the A and PTR records to 3600 seconds, but can be configured to set it to any value. For DHCP clients, a very small value is probably appropriate - even as little as ten seconds. To set the TTL in the DHCP server, add the following to your /etc/dhcpd.conf file, where <ttl> is the desired TTL in seconds:

ddns-ttl <ttl>;

Setting the hostname for clients not sending the fqdn or host-name options

To set the hostname for clients not sending the fqdn option, add something like following to your /etc/dhcpd.conf file. The actual hostname in the example below will, for ip address aaa.bbb.ccc.ddd, be dhcp-aaa.bbb.ccc.ddd. For more information on how to define your own hostname format, consult the dhcpd documentation.

ddns-hostname = pick (option fqdn.hostname, option host-name,
                      concat ("dhcp-",
                              binary-to-ascii (10, 8, "-", leased-address));
option host-name = config-option server.ddns-hostname;

The ISC server will accept a hostname sent in the host-name option as well as the fqdn option, so the function of the code we added is simply to make up a name in the event that the client sends neither option.

4. Troubleshooting

In order to monitor the behaviour of a setup, proper logging should be in place.

Configuring Logging for the DNS Server

There are several categories that log messages fall in to. For instance, all queries fall in to the "queries" category, all notify messages will fall in to the "notify" category, and so on. We are interested in the "dnssec", the "update" and the "security" categories.

The messages for every category are channeled into files or through syslog. The channel phrase can be used to specify which severity level should be logged, how the format of the log message should be, what extra information should be logged, where it should be logged, how many versions should be kept, and how large the zone file may grow.

For this setup we will log all above categories in one place:

logging {
    category dnssec   { security_log; };
    category update   { security_log; };
    category security { security_log; };

    channel security_log {
        file "dns-security.log" versions 5 size 20m;
            // every time the log grows over 20 Mbyte, it will
            // backup and rollover. Maximum 5 backups will be kept.
        print-time yes;
        print-category yes;
        print-severity yes;
        severity info;

Debugging DNS updates from the DHCP server and client

When debugging problems with DHCP server DNS updates, first make sure that the DHCP server is parsing the configuration file correctly. You can test this with "dhcpd -t". If the DHCP server prints error messages when you run it, you must fix these errors before proceeding. If you are also modifying the DNS configuration file, you may make the mistake of putting a ";" after a "}". This is allowed for the key declaration so that keys can be shared between the DHCP and DNS servers, but the DHCP server normally does not allow a ";" after a "}".

Once you have a clean parse of the config file, you can watch what the DHCP server is doing in syslog, or you can run "dhcpd -d" to have the DHCP server run in the foreground and print errors to the controlling terminal.

The DHCP server logs by default to the LOG_DAEMON facility. Errors are logged at LOG_ERROR, but a lot of additional information is logged at LOG_INFO or LOG_DEBUG, so if you are debugging, it's good to have a syslog file that records INFO- and DEBUG-level messages.

Assuming that you have your DHCP client configured to send an FQDN option as described elsewhere in this document, the DHCP server should not attempt to update the client's A record. When the client gets a lease, you should see a log message like this:

Jan 23 18:38:51 dhcpd dhcpd: added reverse map from to roam.randy.ws.sigz.net.

If, instead, you see a message like this, it means that the client is not sending a fully-qualified domain name:

Jan 23 18:38:51 dhcpd dhcpd: unable to add reverse map from to roam.randy.ws.sigz.net.

This can be either because it is not sending an FQDN option at all, or because it is sending an unqualified domain name in the FQDN option. It is possible to see this same problem even if your client is sending an FQDN option that contains more than one label. For example, you might see:

Jan 23 16:20:39 dhcpd dhcpd: Unable to add forward map from 
laptop.yfd.example.yfd.example to timed out

This means that the client has almost been configured with a fully-qualified domain name, except that the root label was left off. On the ISC DHCP client, you need to do this:

send fqdn.fqdn "laptop.yfd.example.";

not this:

send fqdn.fqdn "laptop.yfd.example";

Notice the trailing '.' in the first example. If the client doesn't send a fully-qualified domain name, the DHCP server assumes that the name is to be added in a forward zone that has been configured on the server. You will also see this behavior if the client has not been configured to tell the server that it will update its own A record. You must have this line in your dhclient.conf:

send fqdn.server-updates false;

If you see a message like this, it means either that your DHCP server isn' t using the right key to update the record, or that it is not using any key to update the record, or that the primary DNS server for the zone is not reachable. Make sure you have a zone statement, and that you used the same name for the key on both the DHCP and DNS servers:

Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: timed out.

If you see this message, your key isn't a valid key to use to update the zone:

Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: invalid TSIG key.

If you see this, your clocks are out of sync. Make sure you use "date -u" when comparing clock times. Clocks must be within five minutes of each other:

Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: clock skew too great.

This message means that the zone statement in your configuration file doesn't refer to an actual zone in the DNS. It is possible to have a subdomain that is not a zone. In order for a domain to be a zone, it must have an SOA record. So if you get this message, find the most specific SOA record above the name you are updating and write a zone declaration for the name to which that SOA record is attached:

Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43.
5.0.193.in-addr.arpa. 30 IN PTR laptop.yfd.example: not a zone.

The same logging configuration described for the server applies to the client. The error messages described above also have the same meanings on the client.

5. Limitations and Possible Complications



The documentation for the involved programs and protocols could be clearer and definitely need more and better examples. This has been reported and will hopefully be improved in the future.

Syntactic differences

There are unfortunate syntactic differences between dhclient.conf, dhcpd.conf, and /etc/named.conf. In some places a certain item is expected to be surronded by quotes ("), in other places not. Sometimes a command is terminated with semicolon (;), in other places the same command is not, etc. This is very confusing, and one has to read the documentation carefully.


The clocks in the participating computers must be in sync, especially for updates for updates performed with TSIG. Use of NTP is strongly recommended.

Serial numbers

Since the SOA serial number is incremented for every update of the zone file, one can no longer depend on the correctness of numeric structures (such as the common YYYYMMDDnn formula) of serial numbers in zones subject to dynamic updates. Beware that if you lower the serial number in an existing zone, you have to take manual steps to re-synchronize all slave servers for the zone.


The DNS TTL (time to live) property mixes poorly with dynamic updates and DHCP. There is no guarantee that the TTL will match the remaining DHCP lease time for the client at any given moment. This remains to be a discussion topic.

Deleting the updates in the forward tree

After one leaves the temporary network, the forward tree must be updated to remove the temporary IP address issued by the DHCP server. Many options were suggested, but all were rejected because of some issue or another.

Separate dynamic zones

It seems unlikely that dynamic update, regardless of its security, will be enabled for all zones. Among the reasons for this is the different traceability characteristics of a zone with "important servers" and a zone with "mobile laptops". In the server zone it is crucial to be able to keep track of who did exactly what change when and why, and typically the (static) zone file is under some sort of revision control that interacts extremely poorly with a dynamically updated zone.

But at the same time it seems unlikely that people using dynamically updated DNS entries for their machines will be satisfied with an longer (therefore percieved as "inferior") domainname like "laptop.dynamic.example.com."

The best suggestion we have to ameliorate this situation is to go the CNAME way. I.e.:

laptop.example.com.             IN      CNAME   laptop.dynamic.example.com.

However, if and when doing that, it is probably desirable to have the reverse mapping point at the "exposed name, rather than the CNAME. I.e.:

x.y.z.w.in-addr.arpa.           IN      PTR     laptop.example.com.

DNS Server Side

BIND only

The only DNS server available to the workshop participants that was able to deal with dynamic updates of secure zones at the time was BIND. Thus, we only give you instructions for platforms that are supported by BIND for the DNS serers.

Update policy

The zone subject to dynamic updates needs an update policy. Care should be exercised to not devise a too liberal update policy. Especially the zone apex records (SOA, NS, ...) need to be protected from updates by malicious/clueless clients.

Manual updates and journal files

When dynamic update is enabled for a zone, the zone can no longer be manually edited as normal. Attempting to do so may work in some cases, but will usually result in a name server error.

The DNS server keeps a journal file of incoming updates. The file is not automatically syncronized with the zone file, but can be forced with the "rndc stop" command. Extreme care has to be exercised when manually updating a zone subject to dynamic updates.

When using BIND 9.2, the following must be done to edit a master file of a zone maintained by dynamic update. Note that this stops named until the process is complete.

  1. rndc stop
  2. remove the journal file (.jnl)
  3. edit the zone
  4. start named

When using a recent BIND 9.3 snapshot (that is, newer than bind-9.3.0s20020122) , the following can be used instead, which does not require that named be stopped:

  1. rndc freeze zone
  2. edit the zone
  3. rndc unfreeze zone

DHCP Client Side


The DHCP client in MacOS does not know how to do dynamic updates, so it could not be used in the tests.


The DHCP client in Windows does do updates, but needs GSS-TSIG to have full functionality, so it could not be used either in the tests.


Updates seem to work with modern DHCP clients running on Unix or Linux.

First cycle bug

Several BSD platforms reported that when the dhclient was tasked with sending updates, the update would not reach the DNS server when the IP address was initially handed out, but when it was refreshed (half a lease time later) the update came and was processed orderly. This was found to be a race condition in the dhclient, and will be fixed in coming releases.


dhclient uses a DHCP-ID to indicate that a DNS record has been updated by a certain client. The DHCP-ID is either provided by the client as a configured value, or a hash value automatically computed over a combination of the FQDN of the host and its MAC address. Currently the DHCP-ID is stored in the DNS (by dhclient) as a TXT record (in lack of a proper DNS record). dhclient will only update the record if it either doesn't exist at all, or if the corresponding DHCP-ID matches. Otherwise it's left as it is. Therefore, if a DNS file contains a static record for a hostname, that you suddenly want to allow dynamic updates to, the record must first be removed manually. If there is another TXT record with the same owner name, the update will not take place.

No turning off forward updates

The DHCP server is told by the dhclient whether the server is expected to update the forward zone or not. The configuration is such that either the server is tasked to do this, or the client assumes that it should to it itself. There is no way to configure the client to neither tell the server to do it, nor perform the update itself. This is problematic if you want to do the update from a script outside the dhclient.

Multiple forward zones

dhclient does not yet deal with multiple forward zones, i.e., a laptop can not automatically update the two zones hostname.example.com, and hostname.myhomenet.org.

Updating Signed Zones

DNSSEC model changing

This document does not cover how to make your zone secure. Please be aware that the DNSSEC model is undergoing change, and the workshop was based on the available software that handles the RFC 2535 model. It is expected that this model will change when/if the "Delegation Signer (DS)" record is introduced. (See "draft-ietf-dnsext-delegation-signer-05.txt", work in progress). Since DS is not handled by current software, it could not be tested.

Deleting the last record

BIND 9.2.0 has a bug where if you try to delete the last data record (apart from the zone SOA and NS records) from a zone, it will fail to perform the update. The bug may show its ugly face under other circumstances too. The bug has been reported but not yet fixed.

Signing key on-line

If the server is to be able to update records in a signed zone, it must be able to sign new records added to the zone. Thus the private half of the zone key must be stored on line, at the name server's disposal, typically as a readable file in the directory specified in the "directory ".....";" statement in the /etc/named.conf file. This might be considered bad security practice.

TSIG vs. SIG(0)

The BIND 9.2.0 way of securing the update transaction is through TSIG. TSIG uses symmetric keys, which means, in a sense, a system with a higher built-in risk than one with asymmetric keys. If one side is compromised, the other one falls at the same time. The alternative method with asymmetric keys (usually referred to as SIG(0)) is not easily supported in BIND 9.2.0, but given the higher risk with symmetric keys, SIG(0) is the preferred method. There are patches for BIND 9.2.0 to support this, and it will hopefully be supported in future releases.

TTLs and signature lifetimes

As mentioned, TTLs mix poorly with dynamic updates, and even more so with DNSSEC signatures. Signature lifetimes can be specified for all records in a zone, but there is currently no way to specify them with better precision than days. This should probably be mended in the future, but it has complicated consequences for caching and signature validation, and it remains an open question how you should choose the signature lifetimes and whether all records should have the same lifetime.

It should also be noted that the server will not automatically re-sign records for which the signature has expired. The consequences of this are not fully penetrated.

Signing updates with multiple keys

If multiple zone keys are present in the zone, but not in the BIND working directory, a SERVFAIL error is returned for the update. This bug has been fixed and the fix will be part of future releases. The solution will be that the server will generate SIG records using any zone keys found in the directory.

Updating the zone apex - don't!

You must not update the KEY record at zone apex, since that will immediately invalidate entire zone, due to the fact that the KEY record set has changed, and the parent SIG is thereby no longer valid.

Key roll-over

Doing key roll-over is extremely complicated, especially if one wants to do it from a remote site. The following text demonstrates the issues involved wrt key-rollover in a dynamic updated zone. The steps described below is a rough generalisation on the actual steps involved.

This is the basic idea:

There are 3 states,

  1. "before" production state
  2. "rollover" state
  3. "after" production state

The purpose of this excersize is to minimize the "rollover-state" time, since production state is critical.

while in state 1):

The following will transfer the nameserver from state 1 to state 2. A possible feature request may be (and is already issued :-) to have the two steps below in one (ie. rndc flush & dissallow update) (see issues section)

while in state 2:

The following command puts the status in state 3)


The above scenario demonstrates the clash between dynamicly updating the zone and manually updating the zone (one needs to re-sign the zone with the new key).

As shown above, during the re-sign of the zone, it needs to be physically on disk, and therefore new dynamic updates need to stop (temporarily) and current (pending) updates needs to be flushed to the zone on disk.

If there is a strong requirement for dynamic updates, stopping the nameserver from receiving dynamic updates poses a problem.

Several solutions to this problem came to mind:

  1. Dynamically resigning a zone (infinite ugliness!)
    After the new private key is put on the nameserver, one can traverse the zone (through NXT records) and dynamically update all records.
  2. Somehow accept and que pending updates (significant ugliness).
    This introduces another problem. If the "rollover state" exceeds the time a dynamically updated record exists (i.e. add-delete during this time) the nameserver does redundant work, and meanwhile the client is not able to have its desired records published.
  3. Somehow accept and propagate updates during the zone-signing session (moderate ugliness)
    This means the journal file will already have the signatures of the new key, the file-on-disk is signed offline, and after a flush, the journal file will be included in the zone-file-on-disk. Eventhough the zone file is manually changed, there are no records deleted, no new names added, and only records (NXT SIG) with the same name changed. Since it is not allowed to manually update (delete) NXT and SIG records, there seems to be no clash. This makes it ofcourse impossible to perform an ixfr.