ISC DHCP 4.3 updates the DDNS code to be compliant with RFCs 4701, 4702, 4703 and 4361 [RT #21139].
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.
In order to use the new standard DDNS style on a DHCP server you would simply include the following line in your configuration file.
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 will attempt 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.
The transition issue is then 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. In order 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 1 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.
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 present 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 your are just staring 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 to 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 co-operate 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. In order to make use of 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.