ISC DHCP support for Standard DDNS
  • 13 Jul 2021
  • 6 Minutes to read
  • Contributors
  • Dark
  • PDF

ISC DHCP support for Standard DDNS

  • Dark
  • PDF

Article Summary

ISC DHCP 4.3 updates the DDNS code to be compliant with RFCs 4701, 4702, 4703, and 4361.

Dynamic DNS update styles

Over the years there have been three distinct styles for the DDNS code. The ddns-update-style option in the configuration file is used to select amongst them for a server.

  • ad-hoc - This is the oldest of the three styles and is based on the script language. It has several issues and was deprecated in 4.2.0 and the code completely removed in 4.3.0.
  • interim - This is the second of the three styles and is written in C as part of the standard code base. It was added while the standards were still being developed and as a result suffers from being written before the standards were completed. It uses the same concepts as the standards, but differs in several details such as the use of MD5 instead of SHA and the use of TXT RRs instead of DHCID RRs. The DDNS interaction between ISC DHCP and a DNS server is fine; however, there may be difficulties with interoperability with another DHCP server that adheres to the current standards. (In 4.2.0 this code was enhanced to perform the DDNS transaction asynchronously. This option continues to be available.)
  • standard - This is the third and most recent of the options being released as part of 4.3.0. As mentioned in the description of the interim option, the basic operations between standard and interim are the same, with changes to the details to be compliant with the current standards. Due to these changes in the details, the two styles are not interoperable (that is, you should not have one DHCP server using interim while another uses standard with both updating the same DNS server).
  • none - This is included in this description for completeness. This option is available if you choose to disable DDNS.

To use the new standard DDNS style on a DHCP server you would simply include the following line in your configuration file:

ddns-update-style standard;

DHCP Server - which DDNS update style and other options should I use?

There are two major considerations when choosing which DDNS update style to use: the transition of DDNS records between styles, and the situation where you are dynamically adding both v4 and v6 addresses for the same host.

In order to understand some of the server issues between interim and standard, it is helpful to understand how the TXT or DHCID RRs are used. When a DHCP server or client decides to update the DNS via DDNS, it first gathers some basic information including the name, the ip address, and the client id or DUID. It attempts to update the DNS with this information and succeeds if the name didn't previously exist. If the name did exist, then we need a method to determine if the client causing the update is the same as the client that caused the previous addition. To do this we use the TXT or DHCID RRs. If we always create a TXT or DHCID RR based on some information unique to the client, then if the RR from the new request matches the one already in the DNS the update is for the same client and should be allowed.

Transition issue

The transition issue is that a DNS server may have a number of entries inserted by a DHCP server running the interim style, and switching the DHCP server to running the standard style could result in conflicts. To alleviate some of this issue, we included a simple transition mechanism. When the DHCP server determines that the name-to-address mapping has changed, it will attempt to remove the old mapping before adding the new mapping. As the lease database contains information about the previous DDNS transaction for dynamic addresses, the server is able to determine if the previous entry used a TXT or DHCID RR and remove it.

This feature means that as leases expire or names change, the old DNS records will be removed or updated. However, it is not uncommon for the same client to retain a name and address for considerable lengths of time; for example, consider a desktop system that is used every weekday and is given a one-week lease. In this case it might be months before the lease expires. There are two ways to handle these types of clients.

You could simply disable the DDNS optimization feature by inserting the following line in your configuration file:

update-optimization off;

When this feature is enabled, the DHCP server checks if the new name on a lease request is the same as the name already in the lease. If they are the same, it skips the DDNS step most of the time and normally only needs to perform the DDNS transactions when the lease is first granted. If the feature is disabled, the DHCP server does a DDNS update on each renew. While this change fixes the underlying problem, it presents a new problem of adding a large amount of DDNS traffic. To avoid that problem we have provided another feature.

If the following is defined in the includes/site.h file, the server checks to see if the new record and the old record have different types for the conflict RR. If they do, the DDNS update is performed even if the name-to-address mapping hasn't changed. This feature is enabled by default.


These features handle the case of a simple network setup well, but may not work for more complex networks. We are evaluating other transition aids to determine if their utility will outweigh the cost of writing them.

So if you don't have any current records--for example, if you are just starting to use DDNS or if you are able to delete all of your dynamic DNS records and allow them to be rebuilt, or if you have a network for which the above transition works well--you should use the standard option. If you have a more complicated network, you will need to evaluate the problems associated with any transition versus the utility of using a standard mechanism.

Interaction between v4 and v6 addresses

The second item to consider is the interaction of v4 and v6 addresses and the DNS. If you want to have the DHCP server insert both an IPv4 and IPv6 address for a given name, then the server must generate the same DHCID RR for both transactions. The standards define a way for the DHCPv4 and v6 clients on a machine to cooperate to provide the appropriate information in the client ID and DUID options, to allow a server to create the same value for the DHCID RR. To use this feature you must use the standard style.

DHCP Client options

On the client side there are two new options, -I and -i , and the -D  option has been modified.

  • -I indicates the use of the standard style; by default the client uses the interim style.
  • -i indicates that a v4 client should use a client id based on a DUID. If there isn't a default DUID it will be created. The resulting client id can be overridden by including a client id in the configuration.
  • -D has been modified to be usable with v4. It indicates if the DUID should be LL or LLT. When it is set on a v4 client it causes the -i option to be enabled.

The -i option allows v4 and v6 clients to provide the same DUID to a server. This would allow the server to determine that the two clients represent the same machine and would result in the same DHCID RR, and thus allow a name to have both a v4 and v6 address.

In release 4.3.1 we added another option -df. This option specifies a path to a secondary lease file. If the primary lease file doesn't contain a DUID, then the client will search the secondary lease file. If the client finds a DUID in the secondary it will be written to the primary. This option can be used to allow an IPv4 instance of the client to share a DUID with an IPv6 instance. After starting one of the instances, the second can be started with this option pointing to the lease file of the first instance; in this way, the second instance can use the exact same DUID as the first instance.