ISC DHCP support for Standard DDNS
- Updated on 18 Jul 2017
- 7 minutes to read
ISC DHCP 4.3 updates the DDNS code to be compliant with RFCs 4701, 4702, 4703 and 4361 [RT #21139].
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.
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.
© 2001-2018 Internet Systems Consortium For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership. ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.