ISC DHCP - Dynamic DNS Declarations

A key linkage among the address assignment and name resolution function is the automated updating of an IP address and hostname association from a DHCP server to a DNS server. This process called Dynamic DNS (DDNS) enables a DHCP server to update an A or AAAA and corresponding PTR record in DNS based upon the IP address assigned to a given host by the DHCP server. Thus devices obtaining IP addresses dynamically via DHCP can also be represented in DNS for name resolution. The DHCP server formulates the resource record update from the IP address just assigned and the hostname provided by the client and the domain name either configured in the DHCP server or provided by the client based on policy.

In some environments such as one with Microsoft clients clients can indicate whether they wish to perform the DNS update by setting the Client FQDN option (DHCPv4 option 81 and DHCPv6 option 39)[1]. Both option versions enable specification of a flag indicating whether the server should perform the address record update along with the client's fully qualified domain name. The DHCP server can be configured to honor such client requests by configuring the allow client-updates statement or to deny such requests by configuring the ignore client-updates statement. If the DHCP server is configured to allow client-updates and the client provides option 81 indicating its desire to perform the DDNS update within its Discover packet the server will not create the A or AAAA record. The DHCP server will however create a PTR record update for the address assigned mapping it to the FQDN provided in option 81.

If the DHCP server is configured to ignore client-updates or if the client indicates within option 81 that the server should perform the dynamic update then the DHCP server will formulate the A/AAAA and PTR record updates. The client's FQDN is formulated determining the hostname and concatenating the domain configured on the server via the option domain-name 'domain' setting in the DHCP configuration file. The hostname is derived from the first label in the FQDN provided in option 81 if present using the hostname option (option 12) provided by the client or if the use-host-decl-names parameter is configured the hostname in the corresponding host declaration is used. The DHCP server will formulate the A/AAAA and PTR records based on this FQDN and associated IP address and update the respective DNS server(s).

Avoiding Name Conflicts

Given this 'bottom up' approach to updating DNS you may be wondering how naming conflicts are handled e.g. if two devices claim the same hostname. If an update is sent to a DNS server with a FQDN that already exists but is associated with a different IP address has the same host moved to a different subnet or is another host attempting to use the same FQDN? This is handled by associating an 'owner' with a given address resource record. The ISC DHCP server provides an interim[2] update strategy to associate such an owner with a given resource record. The address owner association is performed by sending a TXT record along with the A record with the same DNS owner name (the host's FQDN). The TXT record Rdata field consists of an MD5 hash of the client's hardware (MAC) type and address or client identifier option.

If this update attempt fails i.e. the DNS server returns a YXDOMAIN error (record exists when it should not) then the DHCP server reformulates the update message using the prerequisite field indicating that a TXT record containing the calculated hash of the owner's identification exists in the RRSet. If this update succeeds then the same client has just updated its address record; otherwise the update fails as another host is already using the FQDN.

The DHCID resource record is intended to provide similar functionality as the TXT record in this dynamic update application explicitly. The DHCID RData field consists of:

• Identifier type code (2 octets)
• Digest type code (1 octet)
• Digest (hash '“ variable length)

Valid Identifier type codes include the following and identify the hash source data:

• 0x0000 '“ the one octet hardware type field followed by the client hardware address field from the client's DHCPREQUEST packet (DHCPv4)
• 0x0001 '“ The type and client-identifier octets from the client identifier option (DHCPv4)
• 0x0002 '“ The client's DUID meaning either the DHCPv6 client identifier option or the DHCPv5 client identifier option

As of now the only supported digest type is 0x01 SHA-256. This algorithm is applied to the data within the DHCP packet referenced by the Identifier type code. The resulting digest is added to the RData field of the DHCID record. The update process follows the same process as in the interim approach described above except that upon initial update failure the second update attempt will include a prerequisite for the existence of the DHCID resource record of the corresponding RData value.

Configuring TSIG-Signed Updates

Dynamic updates may be sent as normal updates as just described or alternatively may be signed using Transactions Signatures (TSIG). TSIG utilizes a shared secret key mechanism to sign the update message providing source authentication and message integrity checking. A hash of the update message is created using the shared key. The resulting output is the signature which is passed as a TSIG meta resource record included in the additional section of the DNS message containing the original A/PTR resource record update message to the DNS server. The DNS server also configured with the same shared key performs the hashing function using the specified algorithm and the shared key. If there's a match the update is accepted; otherwise it is rejected and an error message is returned to the DHCP server.

The syntax in configuring the ISC DHCP server to sign updates requires declaring the key by name its algorithm and shared secret key and key association with zones for which it will sign updates. The following example illustrates the key declaration followed by its association with updates to the ipamworldwide.com. zone.

key dhcp1-dns1.ipamworldwide.com. {

algorithm hmac-md5;

secret G/AeAdCQklYwbCfnemSq2A==;

};

zone ipamworldwide.com. {

primary 10.0.0.99;

key dhcp1-dns1.ipamworldwide.com.;

}

The primary statement indicates the IP address of the DNS server configured as master of the ipamworldwide.com zone. This master DNS server must likewise be configured with the dhcp1-dns1.ipamworldwide.com. key declaration. The key is associated with updaters to the zone by specifying the key name within the allow-update statement within the zone declaration. The following example illustrates the corresponding BIND DNS server configuration.

key dhcp1-dns1.ipamworldwide.com. {

algorithm hmac-md5;

secret G/AeAdCQklYwbCfnemSq2A==;

};

zone 'ipamworldwide.com.' {

type master;

file 'db.ipamworldwide.com';

allow-update { key dhcp1-dns1.ipamworldwide.com.; };

};

The secret key value can be generated using the dnssec-keygen utility supplied with the ISC BIND (DNS) distribution. Please refer to Chapter 15 for details regarding the syntax and valid parameters of the dnssec-keygen utility.