Using Dual-Stack Mixed Mode (DSMM) with DDNS in ISC DHCP 4.4

The Problem with DDNS and Dual Stack clients

When clients obtain both an IPv4 and an IPv6 address, they generally want their hostnames when added to DNS to be the same, for both the v4 and the v6 address – i.e. they want, for the same name, for there to be both an A and a AAAA record.

This is hard to coordinate because:

• The DDNS updates can come from either the DHCP server(s) or from the client directly (and client updates may or may not be permitted by the DNS server).
• In ISC DHCP, the DHCPv4 and DHCPv6 servers run as separate daemons.
• The DHCPv4 and DHCPv6 protocols are very different; the client requests for v4 and v6 addresses will be asynchronous and thus need some sort of signalling mechanism to ensure that:
  • Two clients don’t get the same name (one with the A RR and the other with the AAAA).
  • A new client doesn’t “steal” a name already assigned to another client.
  • Dynamically-assigned names don’t replace or delete static names.
  • Unused name-address mappings are cleaned up, either when released, or when the same client comes back with a new address.

In DHCP 4.3 and earlier we provided two mechanisms for managing DDNS updates via the DHCP server:

• Interim (this uses a TXT RR for each dynamic hostname) and was written before the standards were finalised.
• Standard (this uses a DHCID RR for each dynamic hostname).
• (Previously, we also had “ad-hoc” but this was deprecated in 4.2.0.)

ISC DHCP servers can be configured to use either Interim or Standard (see ISC DHCP support for Standard DDNS), but in a dual-stack environment, both need to be using the same mechanism to manage dual-stack client names properly – they are not interoperable. This is due to the interaction of v4 and v6 addresses and the DNS. If you want the DHCP server to insert both an IPv4 and IPv6 address for a given name, then the server must generate the same DHCID or TXT RR for both transactions (and in the case of the ISC DHCP server you must use the standard style – this is because of a bug in the interim style which means that ISC DHCP v4 and v6 servers don’t generate matching client IDs).

We have tackled this problem in ISC DHCP 4.4, as described below.

What is Dual-Stack Mixed Mode (DSMM)?

Dual-Stack Mixed Mode (DSMM) operates under the premise that all DHCP servers supporting one protocol (v4 or v6) will use one DDNS update style (interim or standard) while all servers supporting the “other” protocol use the “other” update style. This ensures that the type of guard record (TXT or DHCID) is always the same for a given protocol.

It provides a combination of separation and coordination to help DHCP and DNS administrators support an environment in which there are both static and dynamic addresses in DNS, and where the client dual-stack implementations cannot be relied upon to be compliant with current RFCs in how they provide DHCID and request hostname to address mappings. DSMM should prevent the creation of orphaned guard records and unusable dynamic names, but at the expense of removing the guarantees that a client with an IPv4 address and hostname can have the same hostname if it obtains an IPv6 address too, or that two clients can end up sharing the same name – one of them with an IPv4 address and the other with IPv6.

In short, when DSMM is enabled, a DHCP server will ignore DNS address and guard records of the “other” type when deciding if updates can be made, or whether the existing entries are either static or belong to another client and must be left alone. In no case will address or guard records of the “other” type be altered by a DSMM server.

Limitations of DSMM

Implementing DSMM removes the possibility that a client requesting a name for an IPv4 address will be guaranteed to be able to use the same name for an IPv6 address. It removes the assurance that the IPv4 and IPv4 addresses found in DNS for a specific hostname belong to the same client. DSMM does not apply to updating Reverse DNS (but we anticipate that Reverse DNS will be correctly maintained in most instances). Allowing direct client updates should be avoided.

Changes in ISC DHCP 4.4

In 4.4, ISC DHCP introduces three new configuration parameters:

1. The ddns-dual-stack-mixed-mode parameter controls whether the server applies Dual-Stack Mixed Mode rules during DDNS conflict resolution. This parameter is off by default, has no effect unless update-conflict-detection is enabled, and may only be specified at the global scope.
2. The ddns-other-guard-is-dynamic parameter controls whether a server running DSMM will consider the presence of the other update style DHCID RR as an indication that a DNS entry may be overwritten. It should only be enabled after careful study as it allows DNS entries that would otherwise be protected as static, to be overwritten in certain cases. This parameter is off by default, has no effect unless ddns-dual-stack-mixed-mode is enabled, and may only be specified at the global scope.
3. The ddns-guard-id-must-match parameter controls whether the client id within a DHCID RR must match that of the DNS update’s client to permit DNS entries associated with that DHCID RR to be ovewritten. Proper conflict resolution requires ID matching and should only be disabled after careful consideration. When disabled, it is allows any DNS updater to replace DNS entries that have an associated DHCID RR, regardless of client identity. This parameter is on by default, has no effect unless update-conflict-detection is enabled, and may only be specified at the global scope.

Implementing DSMM on your DHCP servers

(The steps below assume that your DNS servers are configured to accept updates from your DHCP servers – this article does not cover that part of the set-up.)

1. Decide which of your DHCP servers (v4 and v6) is going to use ddns-update-style interim and which will use standard, and configure them accordingly.
2. Add to both servers the new option ddns-dual-stack-mixed-mode, and also make sure that you have update-conflict-detection enabled.
3. On your servers, consider whether you will need to enable ddns-other-guard-is-dynamic. You would normally use this to to permit updates to address records which would otherwise be interpreted as static (no accompanying guard of its type) because a guard of the other type does exist. Under default handling, this would be considered a static entry and the update would not be allowed. Use of ddns-other-guard-is-dynamic essentially states that the presence of the other type of guard indicates that entries for this FQDN of either type are dynamic after all.
4. On your servers, consider whether you will enable ddns-guard-id-must-match. Enabling this option permits dynamic clients to overwrite each other’s entries whilst still protecting static entries.

The criteria under which a dynamic entry will be permitted to be updated can be expressed as follows:

1. No records for this FQDN exist.
2. An address record is present and the guard record, optionally matching the client ID (see ddns-guard-id-must-match), is present.
3. An address record is not present but the guard record, optionally matching the client ID (see ddns-guard-id-must-match) is present (recovery from orphaned guard record scenario).
4. Optionally, the only guard record present is the other type of guard record, regardless of whether or not the other type of address record is present (see ddns-other-guard-is-dynamic).

Summary

In an ideal world…

• ISC DHCPv4 and DHCPv6 servers both use Standard style DDNS.
• DHCP clients provide the right information to both v4 and v6 DHCP servers.
• Either there are no direct client DDNS updates, or clients that do this implement the Standard style DDNS fully and correctly.

In the real world…

• Clients do not adhere to current DDNS RFCs when communicating directly with DNS servers or via their DHCP server.
• DHCP clients provide inconsistent DHCID values for v4 and v6.
• Update failures due to name collisions, absences and other problems lead to orphaned RRsets in DNS, blocking the further use of formerly-dynamic names.
• Reverse DNS RRsets are not updated consistently.

Dual-Stack Mixed Mode, whilst deviating from the RFCs, attempts to provide a workable DDNS production environment that accommodates most broken client behavior until such time as all clients can be trusted or required to be RFC-compliant.

This blog post is based on Using Dual-Stack Mixed Mode (DSMM) with DDNS in ISC DHCP 4.4, in ISC’s Knowledgebase. The KB article may have updates on this information.