Welcome to FreeUnix.dyndns.org -> Using DHCP on Linux/FreeBSD

If you have a DHCP server and most likely DNS servers, it would be nice if your DHCP server would automatically update the DNS servers when it hands out a lease (or removes one). This can be established by using Dynamic DNS updates (DDNS).

A DNS server usually maintains two resource records (RR) for each client. One maps FQDNs to IP addresses using A records (Address). The other maps the IP address to the FQDN using PTR records (Pointer). These records are required so that name resolutions can be made in both directions (IP to hostname and hostname to IP).

Dynamic DNS (DDNS) allows to update a DNS system with Address records and Pointer records for adresses handed out by a DHCP server. The use of DDNS updates, issued by a DHCP server, avoids the need for manual configuration of DNS for each host address change.
DDNS allows you to maintain consistency between the information stored in the A and PTR records and the actual address assignment done via DHCP.

When DDNS is active, the DHCP server updates the DNS server for the zone, thereby adding or deleting the corresponding PTR and /or A records, depending on the configuration. The DHCP server also notifies the DNS server when leases expire, causing the A and PTR records to be deleted. If a lease is renewed, no action occurs because none is necessary. For DDNS updates, the DNS server requires the fully qualified domain name (FQDN) and the IP address of the client. The DHCP server knows the IP address, but it must assemble the FQDN from the hostname and the subnet's domain name. The hostname can either be supplied by the client, supplied and/or "generated" by the server.

When a client loses or ends its lease, the DHCP server will send DNS server the DDNS update request which will deletes the PTR and A records associated with the client. Following log file excerpt shows you the messages to expect :

named[97]: client 192.168.1.1#32770: updating zone 'bundynet.org/IN':adding an RR
dhcpd: Added new forward map from kelly.bundynet.org to 192.168.1.81
named[97]: client 192.168.1.1#32770: updating zone '1.168.192.in-addr.arpa/IN':deleting an rrset
named[97]: client 192.168.1.1#32770: updating zone '1.168.192.in-addr.arpa/IN':adding an RR
dhcpd: added reverse map from 81.1.168.192.in-addr.arpa. to kelly.bundynet.org

The ISC DHCP server supports DDNS starting with version 3.0 . To enable DDNS updates, you will have to edit /etc/dhcpd.conf and add a line like this :

ddns-update-style interim;

There is another style, ad-hoc, but it's deprecated since ISC DHCP 3.0.1rc11 or rc10 and does not work. This scheme will most likely no longer be available in future releases. The interim scheme is what should be used now. The information given next on the ad-hoc scheme is only for informational purposes.
Of course, your DNS server must be configured to allow updates for any zone that the DHCP server will be updating.

The ad-hoc DDNS update scheme

For the ad-hoc DNS update method, the client's FQDN is derived in two parts. First, the hostname is determined. Then, the domain name is determined, and appended to the hostname.

The DHCP server determines the client's hostname by first looking for a ddns-hostname configuration option, and using that if it is present. If no such option is present, the server looks for a valid hostname in the FQDN option sent by the client. If one is found, it is used; otherwise, if the client sent a host-name option, that is used. Otherwise, if there is a host declaration that applies to the client, the name from that declaration will be used. If none of these applies, the server will not have a hostname for the client, and will not be able to do a DNS update.

The domain name is determined based strictly on the server configuration, not on what the client sends. First, if there is a ddns-domainname configuration option, it is used. Second, if there is a domain- name option configured, that is used. Otherwise, the server will not do the DNS update.

The A record will contain the IP address that the client was assigned in its lease. If there is already an A record with the same name in the DNS server, no update of either the A or PTR records will occur - this prevents a client from claiming that its hostname is the name of some other host.

If the A record update succeeds, a PTR record update for the assigned IP address will be done, pointing to the A record. This update is unconditional - it will be done even if another PTR record of the same name exists. Since the IP address has been assigned by the DHCP server, this should be safe.

When the client's lease expires, the DHCP server will remove the client's A and PTR records from the DNS database. If the client releases its lease by sending a DHCPRELEASE message, the server will likewise remove the A and PTR records.

The interim DDNS update scheme

The first point to understand about this style of DNS update is that unlike the ad-hoc style, the DHCP server does not necessarily always update both the A and the PTR records. The FQDN option includes a flag which, when sent by the client, indicates that the client wishes to update its own A record. In that case, the server can be configured either to honor the client's intentions or ignore them. This is done with the statement allow client-updates, or the statement ignore client-updates. By default, client updates are allowed.

If the server is configured to allow client updates, then if the client sends a fully-qualified domain name in the FQDN option, the server will use that name the client sent in the FQDN option to update the PTR record. If the client also indicates that it wants to update its own A record, the DHCP server will not attempt to set up an A record for the client, but does set up a PTR record for the IP address that it assigns the client, pointing at the FQDN supplied by the client.

If the server is configured not to allow client updates, or if the client doesn't want to do its own update, the server will simply choose a name for the client, possibly using the hostname supplied by the client. If the client sends an FQDN in the fqdn option, the server uses only the leftmost part of it. However, if the server configuration contains a ddns-hostname option, this one takes precedence over a possible client supplied FQDN or hostname.
The server will use its own domain name for the client, just as in the ad-hoc update scheme. It will then update both the A and PTR record, using the name that it chose for the client. Result is that all DHCP clients will be know in DNS with the same domain name, which is desirable.
However, it the client does not supply an FQDN option, nor a hostname, and the server is not configured to create a hostname - like with a ddns-hostname option - the server will not perform a DDNS update. If you want DDNS updates, and your server does not "generate" hostnames, make sure your clients supply a hostname.

Configuration of a server to create hostnames for DDNS updates is done with the ddns-hostname option. It can be a function that works on client supplied information like the MAC address. An example:

ddns-hostname = binary-to-ascii(16,8,"-",substring(hardware,1,6));

You will then get hostnames like 0-b-6a-13-86-f8.yourlan.net for a client with 00:0b:6a:13:86:f8 as MAC address. Other functions are possible of course but this particular one has the added advantage of always generating the same hostname for a given MAC address. See man dhcp-eval for more info.
At that point, the RR's in your DNS are consistent with the address and hostname assigned by your server. But, that doesn't mean that the client knows it has a (possibly) new hostname. Even worse, the clients hostname might change whenever the server assigns another IP address. You can configure your server to send the new hostname to the client by defining a host-name option. An example :

option host-name = binary-to-ascii(16,8,"-",substring(hardware,1,6));

This will generate a hostname and the server will send it to the client. But, that doesn't mean your client will also use this hostname. If you want your client to set its hostname to the hostname send by a DHCP server, and hence make it consistent with the RR's in DNS (as result of a ddns update), you will have to tell the DHCP client to do so explicitly because nor dhcpcd, nor dhclient will do this by default.
To force dhcpcd to set the hostname, invoke it with the -H option, like this :

dhcpcd -H

The -H options sets the clients hostname to the one supplied by the server. You can of course also let the client perform a name lookup after receiving a lease, and set its hostname to returned hostname.

The other difference between the ad-hoc scheme and the interim scheme is that with the interim scheme, a method is used hat allows more than one DHCP server to update the DNS database without accidentally deleting A records that shouldn't be deleted nor failing to add A records that should be added. The scheme works as follows:

- When the DHCP server issues a client a new lease, it creates a text string that is an MD5 hash over the DHCP client's identification . The update adds an A record with the name the server chose and a TXT record containing the hashed identifier string (hashid). If this update succeeds, the server is done.
- If the update fails because the A record already exists, then the DHCP server attempts to add the A record with the prerequisite that there must be a TXT record in the same name as the new A record, and that TXT record's contents must be equal to hashid. If this update succeeds, then the client has its A record and PTR record. If it fails, then the name the client has been assigned (or requested) is in use, and can't be used by the client. At this point the DHCP server gives up trying to do a DNS update for the client until the client chooses a new name.

The interim DNS update scheme is called interim because it does not quite follow the current IETF drafts on DDNS. Also, the existing ddns-resolution draft calls for the DHCP server to put a DHCID RR on the PTR record, but the interim update method does not do this. This might change (or not) in the future. It is possible that future versions of ISC DHCP will use yet another DDNS update scheme.

A popular scenario in real-world deployments is the one where client updates are not allowed or used, and hence the DHCP server updates both the A and PTR records, using a name supplied by the client. Name collisions in this scenario are likely, if no administrative procedures are designed to prevent them. Hence, in this scenario, it is important to ensure the uniqueness of hostnames supplied by clients.

The server does not update very aggressively. Because each DNS update involves a round trip to the DNS server, there is a cost associated with doing updates even if they do not actually modify the DNS database. So the DHCP server tracks whether or not it has updated the record in the past (this information is stored on the lease) and does not attempt to update records that it thinks it has already updated.