DNS - DDNS with DHCPv4 and DHCPv6

This page describes using and configuring DHCP for IPv4 (DHCPv4) and IPv6 (DHCPv6) to enable automatic updating of both the forward and reverse mapping zone file. While this is extremely useful for IPv4 it is practically essential for IPv6.

Note: The configurations assume use of ISC's DHCP verion 4.x+ unless otherwise noted.

DHCP Overview
ISC DHCP Configuration File Layout
IPv4 - IP based security
IPv4 - TSIG based security
IPv6 - IP based security
IPv6 - TSIG based security
DHCP with Mixed IPv4/IPv6

DHCP Overview

DHCP was primarily designed to enable automatic and centralized provisioning of IP addresses and other configuration elements, such as, default router address, DNS server(s). These additional elements are known as options in the DHCP jargon. In general, when a PC/server, configured to use DHCP (a DHCP Client), is booted it attempts to make contact with a DHCP server by sending a UDP DHCPDISCOVER message (to port 67) using the local network broadcast address (though RFC 2131 explicitly uses the value 255.255.255.255). Since at this point the PC/Server does not have an IP address is uses the special value 0.0.0.0. The DHCP server responds (after a number of checks) using the local network broadcast address using UDP on port 68 with an IP address and a variable lease time (together with any configured options). The lease time in effect says how long the PC/Server may retain the IP address before it must request another one or renew its lease.

Because the IP addresses are being allocated dynamically by the DHCP server, this poses a problem for any DNS configuration which needs to keep track of both the forward map (name to IP address) and possibly the reverse map (IP address to name). One way to solve this problem is to use Dynamic DNS (DDNS) to update the forward (and possibly reverse) map files. There are a number of ways this can be done as shown in figure 1 below:

Figure 1 - DHCP DNS Update Flow

Transactions 1 and 2: show the DHCP Client/Server dialog. There are a further two messages exchanged (not shown simply to keep the diagram uncluttered), DHCPREQUEST in which the client confirms it got the request by echoing the DHCPOFFER and a final DHCPACK in which the server authorizes use of the IP.

Transactions 3 and 4: show the DHCP server updating the forward map and reverse map DNS. These tranasctions are illustrated in the examples that follow. The DDNS transactions may be secured using either IP based security or TSIG (a symmetric-like MAC) based security. The DDNS standards allow a further method based on an asymmetric cipher called SIG(0). ISC DHCP does not (as of v4.x) support SIG(0) and it is not discussed further.

Transactions 5 and 6: show an alternative method of providing the same DNS update service directly from the DNS client. This normally occurs in cases where DHCP is not used such as IPv6 using SLAAC though a number of DHCP clients elect to do this even when using DHCP (includes most Windows clients). The DHCP client can signal its intention to perform a DDNS update (to either or both the forward and reverse files) to the DHCP server by using the FQDN option in the DHCPDISCOVER/DHCPREQUEST message (RFC 4702). These transaction types are not discussed further other than where they are relevant to DHCP configuration statements.

ISC DHCP V4.+ Config File Layout

DHCP provides a lot of flexibility using a bucket load of statements and many clauses to control its behavior. These statements are defined in the dhcpd.conf configuration file. It is beyond the scope of this page to describe DHCP in any but superficial detail - appropriate documentation should be consulted - but the typical file layout is, by convention, shown below. However, it should be noted that the order of clauses is not important and should reflect that which makes most sense for the user.

Note:Consistent with our DNS approach we use the terms statements (atomic items) and clauses (groups of items) when discussing DHCP configuration.

# global statements are applicable to all subnets
global statements
...
# zone clauses are optional and required
# only to define params for DDNS
# may be one or more zone clauses
zone example.com {
  ...
  zone statements
}
# key clauses are optional
# required only for DDNS TSIG
# may be one or more key clauses
key key-name {
  ...
  key statements
}
# must be at least one subnet clause
# in a dhcpd.conf file
subnets d.d.d.d netmask d.d.d.d {
  ...
  subnet statements
}
# other clauses may exist, for example, group
# which have no relevance for DDNS configuration
# and are not shown

All the following configurations use the private IPv4 Address (RFC 1918) 192.168.2.254/24 range and example.com, example.net, example.org conventions for boring, but safe, reasons. IPv6 Addresses use the non-routable documentation address 2001:db8::. Both forward and reverse maps are assumed to be running on the same server (ns1.example.com - IP 192.168.2.15) for the sake of simplicity - there is no requirement that this be the case. The DHCP server is assumed to have the IP address 192.168.2.33.

Example 1 - IPv4 - IP Only

This example assumes that DDNS will only use IP security. This is generally a trivial, but potentially - depending on the environment - insecure, form of configuration. We all know that IP addresses can be spoofed, however, depending on the likelihood of external penetration (or the risk of local rogue machines) it may be a perfectly reasonable solution for, say, home networks or even those sitting behind a NAT gateway or Firewall. Security is always a judicious blend of paranoia versus real threat. Frankly, if you do have a rogue machine on your local private network perhaps the last thing you should be worried about is DDNS corruption.

The dhcpd.conf file is shown - relevant DDNS statements and clauses are shown in bold:

# global statements are applicable to all subnets
authoritative; # assume this is the only DHCP server on network
# global statements
...
# DDNS statements
ddns-updates on;           # default but good practice
ddns-update-style interim; # only supported active option
allow client-updates;      # default but good practice
do-forward-updates;        # default but good practice
...
# zone clauses are optional and required
# only to define params for DDNS
# may be one or more zone clauses
zone example.com {
  ...
  primary ns1.example.com;
  # uses name format could use IP address format
}
zone 2.168.192.in-addr.arpa {
  ...
  primary 192.168.2.15;
  # the above can use a dns name, instead of an IP
  # which is probably more flexible
  # primary ns1.example.com.
}

# must be at least one subnet clause
# in a dhcpd.conf file
subnet 192.168.2.254 netmask 255.255.255.0 {
  # useable IP addresses in this subnet
  range 192.168.2.0 192.168.2.32;
  range 192.168.2.34 192.168.2.128;
  ....
  subnet statements
  ....
  # DDNS statements
  ddns-domainname "example.com.";
  # use this domain name to update A RR (forward map)
  ddns-rev-domainname "in-addr.arpa.";
  # use this domain name to update PTR RR (reverse map)
}
# other clauses may exist, for example, group or host
# which are not relevant for DDNS configuration
# and are not shown

Notes:

The configuration is defensive in that significant default values are explicitly defined. While seeming excessive, this policy prevents problems due to changes in default values in new releases, but has the overriding merit of not needing to consult any documentation about default values when debugging under stress. The values are defined in the dhcpd.conf file - who knows or even cares about default values.
DHCP is normally used to download host configuration information such as DNS servers, default gateways etc. These are defined in DHCP using option statements. None are shown in the configuration simply to avoid clutter. DHCP also provides multiple additional statements to control its behavior, only those relevant to DDNS are shown. Appropriate DHCP documentation should be consulted for other statement and clause types.
DHCP documentation is very ill-disciplined over the use of, and insistence upon, an FQDN (with a terminating dot) in certain statements. In all cases the sun does not fall out of the sky if the dot is missing since the software, sensibly, checks for and inserts the dot when it requires an FQDN.
DHCP does not require that clauses are terminated by }; as in BIND but it does support this format and happily skips silently over the ;.

The skeleton named.conf file to enable DDNS from the DHCP server using IP security is shown below. It is assumed that both the forward and reverse zone are supported by the same name server for simplicity.

options {
  // global options
  ....
  allow-update {none;}; // disable globally - default
  ....
};
// other clauses as required

// zone clauses
zone "example.com" {
  type master;
  ....
  allow-update {192.168.2.33;}; # ip of dhcp server
};
// reverse zone
zone "2.168.192.in-addr.arpa" {
	type master;
  ....
  allow-update {192.168.2.33;}; # ip of dhcp server
};

Notes:

The allow-update {none;}; in the global options clause is the default but it is good defensive practise to explicitly disable it. Each zone that does allow DDNS update must then be specifically enabled.
The allow-update {192.168.2.33;}; in the zone clauses allows only the defined IP address to update any RR in the zone. If DHCP clients on individual hosts can update DNS their individual IP addresses (or range) must be explicitly defined in the allow-update address_match_list structure. Alternatively, multiple allow-update statements can appear in any zone clause.
DDNS is only allowed to the primary master name server. This name server is defined as the name server which appears in the SOA RR for the zone. Thus, the name server ns1.example.com (defined as the primary in the zone clause for example.com in the dhcpd.conf above) must appear in the SOA RR for the zone example.com as shown:
```
; zone file snippet for example.com
$ORIGIN example.com.
@        SOA ns1.example.com. hostmaster.example.com. (
            ... // other SOA parameters
            )
....
; other zone RRs
....
```

Example 2 - IPv4 - TSIG

This example assumes that DDNS will use cryptographic security when doing DDNS updates. While DDNS is specified to support both TSIG (symmetric-like hash) and SIG() (asymmetric) ciphers (and indeed BIND does support both) DHCP, however, (as of v4.x) only supports TSIG and only with one rather weak option.

To configure TSIG requires that both the DNS server and the DHCP server have copies of a shared secret key. This key must be handled with extreme caution, since if it is exposed or can be read either on the DNS server or the DHCP server (or any other location where it is stored for "safe-keeping") it is compromised and must be discarded and a new key generated. Clearly the last thing any attacker will do is to boast that they have discovered the key, rather they will elect to happily and silently cause as much damage as possible. The following configurations attempt to minimise the possibility of key compromise.

TSIG keys are generated using the BIND9 utility dnssec-keygen using a command like that shown in an appropriate directory:

dnssec-keygen -a hmac-md5 -b 128 -n host -C ddns-a-rrs

# when complete dnssec-keygen will ouput a message such as 
Kddns-a-rrs.+157+xxxxx

# a listing of the directory will reveal two files
Kddns-a-rrs.+157+xxxxx.key
Kddns-a-rrs.+157+xxxxx.private

The -a hmac-md5 argument defines the type of TSIG shared secret we are using. DHCP only supports hmac-md5 (dnssec-keygen supports many other types). The -b 128 argument indicates the number of bits to be used in the HMAC (range 1 - 512), -n host is mandatory when generating TSIG keys the -C ddns-a-rrs argument should be used with modern versions of BIND (it omits timing and state meta data). If your version of dnssec-keygen chokes on -C it can be omitted (and your version of BIND should be immediately updated). The name ddns-a-rrs is arbitrary and defines the key-name as it will be referenced in both BIND and DHCP. The name chosen is supposed to suggest that the key will be used by DDNS to update only A RR types - you may disagree. Feel free to let your imagination run wild with key names.

The output message Kddns-a-rrs.+157+xxxxx is a constant K immediately followed by the key-name, +157 defines the key type (in this case HMAC-MD5) and xxxxx is a 5 digit number that uniquely idetifies this key and will change every time you generate a new key. Inspection of the file Kddns-a-rrs.+157+xxxxx.key will show something like:

ddns-a-rrs. IN KEY 512 3 157 toXHab4lEVauzUYRbiogxg==

This is an artifact of the keygen process and is not used in our configuration. Its presence is a security risk - delete this file. Inspection of the file Kddns-a-rrs.+157+xxxxx.private will shown something like:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: toXHab4lEVauzUYRbiogxg==
Bits: AAA=

Edit this file to look like the following (a key clause) and save it to the same file name:

key "ddns-a-rrs" {
algorithm hmac-md5;
secret toXHab4lEVauzUYRbiogxg==;
};

Essentially, the material which appears after Key: is the base-64 secret key and must be unchanged on the secret line in the edited file structure (though terminated with a ;), some folks enclose this material in quotes ("") to make it easier to work with, though this is not a requirement. (Note: Much confusion reigns over when to use a quoted string and when it does not matter. In general, the rule says that if the item contains a space character it must be enclosed in quotes otherwise it's optional. Since the key material is encoded in base64 it can never contain a space so quotes are not essential.)

Note for the Perennially Curious: In the example above the key material consists of 24 characters. This is the base64 representation of 128-bits (the -b 128 dnssec-keygen argument). Base64 uses a 6-bit character set (ASCII is a 7-bit code) that explicitly excludes the space character. RFC 4648 contains all the gruesome details.

The resulting key clause file contains the shared secret and thus presents a security risk. The file is saved to the same name to ensure that we do not have multiple copies lying around - always a poor policy. You can subsequently rename the file if required (it does have a horrible name format), the objective being to keep a single copy of this file. Assuming you generated this file on the DNS server, secure the file with read only permission for the user BIND runs as, normally named (Linux) or bind (BSD) (better yet, secure it for read only access by root if you have root access). Copy the file to the DHCP server and secure it for read-only access for the DHCP user (normally dhcp) or root. If you copy the file from a third party machine make sure to delete it or a the very least secure it with minimal read-only permissions. This file will be included as shown in both the dhcpd.conf file and the named.conf file. The use of include is a further security precaution, in the event your .conf files are read the secret is not exposed.

Depending on your local policy another key called, say, ddns-ptr-rrs can be generated and the same process followed. Alternatively, you may choose to use a single key for both in which case a more appropriate key-name may be something like anyone-anytime. Just kidding. It's a perfectly viable, if potentially weak, policy especially if the DHCP clients will update the A RRs and the DHCP server will update the PTR RRs or vice versa. As a general matter of policy a single key should be used for a single function from a single source. Not always possible or practical but always the best policy where it is.

The configurations now look like this:

# dhcpd.conf fragment
# global statements are applicable to all subnets
authoritative; # assume this is the only DHCP server on network
# global statements
...
# DDNS statements
ddns-updates on;           # default but good practice
ddns-update-style interim; # only supported active option
allow client-updates;      # default but good practice
do-forward-updates;        # default but good practice
...
# zone clauses are optional and required
# only to define params for DDNS
# may be one or more zone clauses
zone example.com {
  ...
  primary ns1.example.com;
  # uses name format could use IP address format
  key ddns-a-rrs; # binds this key to forward (A) RR updates
}
zone 2.168.192.in-addr.arpa {
  ...
  primary 192.168.2.15;
  # the above can use a dns name, instead of an IP
  # which is probably more flexible
  # primary ns1.example.com.
  key ddns-ptr-rrs; # binds this key to reverse (PTR) RR updates
}
include "/etc/keys/Kddns-a-rrs.+157+xxxxx.private";
include "/etc/keys/Kddns-ptr-rrs.+157+xxxxx.private";

# must be at least one subnet clause
# in a dhcpd.conf file
subnet 192.168.2.254 netmask 255.255.255.0 {
  # useable IP addresses in this subnet
  range 192.168.2.0 192.168.2.32;
  range 192.168.2.34 192.168.2.128;
  ....
  subnet statements
  ....
  # DDNS statements
  ddns-domainname "example.com.";
  # use this domain name to update A RR (forward map)
  ddns-rev-domainname "in-addr.arpa.";
  # use this domain name to update PTR RR (reverse map)
}
# other clauses may exist, for example, group or host
# which are not relevant for DDNS configuration
# and are not shown

Notes:

The key ddns-a-rrs and key ddns-ptr-rrs statements in the respective zone clauses bind the use of the key-name to any transaction. This means it is possible to have key-per-zone configuration granularity.
DHCP does not require that clauses are terminated by }; as in BIND but it does support this format and happily skips silently over the ;. This feature allows the same key clause to be used unmodified in both BIND and DHCP.

The skeleton named.conf file to enable DDNS from the DHCP server using TSIG security is shown below. It is assumed both the forward and reverse zone are supported by the same name server for simplicity.

options {
  // global options
  ....
  allow-update {none;}; // disable globally - default
  ....
};
include "/etc/keys/Kddns-a-rrs.+157+xxxxx.private";
include "/etc/keys/Kddns-ptr-rrs.+157+xxxxx.private";
// other clauses as required

// zone clauses
zone "example.com" {
  type master;
  ....
  // update-policy and allow-update are mutually exclusive
  allow-update {key "ddns-a-rrs";}; # allowed key
  update-policy {grant "ddns-a-ptr" self * A TXT DHCID;}; 
};
// reverse zone
zone "2.168.192.in-addr.arpa" {
	type master;
  ....
  // update-policy and allow-update are mutually exclusive
  allow-update {key "ddns-ptr-rrs";}; # allowed key
  update-policy {grant "ddns-ptr-rrs" self * PTR TXT DHCID;}; 
};

Notes:

The choice of directory location for the included keys is a matter of site policy, remember only to set minimal read-only directory/file permissions. When both DHCP and BIND are loaded they initially run as root (to allocate priority port numbers among other functions) before issuing a suid() call to change to their normal (-u) account. The include statements are processed during the root user period which means that key files set read-only under root can be read.
allow-update and update-policy are mutually exclusive - select a strategy based on one or the other statements (though multiple statements of each type may appear in any zone). Both are shown in the same zone clause (a load-time error) for illustrative purposes only.
update-policy allows a ferocious number of options and is a seriously complex statement to implement. Many variation are both relevant and applicable depending on the requirements. The policy shown in the examples is one of many possibilities. The policy says grant (allow or permit) any DDNS transaction which uses the key-name defined (ddns-a-rrs for example.com - forward map, and ddns-ptr-rrs for 2.168.192.in-addr.arpa - reverse map) to update any (*) RR with the same name (self) but only of the defined RR type (A TXT or DHCID for example.com and PTR TXT or DHCID for 2.168.192.in-addr.arpa) all other transactions will fail. Thus, a DDNS transaction with the correct key for, say, joe.example.com will be allowed to update any A, TXT or DHCID RR with the name joe.example.com. The use of TXT and DHCID allows various versions of DHCP, when used in DHCP master/slave configurations, to keep track of updates. When the update source is MS AD the options ms-self or ms-subdomain are relevant. For Kerberos 5 update sources the options krb5-self and krb5-subdomain are relevant.
DDNS is only allowed to the primary master name server. This name server is defined as the name server which appears in the SOA RR for the zone. Thus, the name server ns1.example.com (defined as the primary in the zone clause for example.com in the dhcpd.conf above) must appear in the SOA RR for the zone example.com as shown:
```
; zone file snippet for example.com
$ORIGIN example.com.
@        SOA ns1.example.com. hostmaster.example.com. (
            ... // other SOA parameters
            )
....
; other zone RRs
....
```

Example 3 - IPv6 - IP Only

The principle behind DHCP-DNS IPv6 is similar to that defined above for IPv4. In order to avoid repeating the background material you are advised to read the IPv4 - IP section as well as the DHCP Overview and DHCP Config Layout Notes. This section will focus only on the IPv6 configuration and relevant notes. Finally, if you are running a mixed (dual stack) IPv4 and IPv6 network please read these notes, otherwise strange things may happen.

Recall, that IPv6 addresses are defined using AAAA (Quad A) RRs and the method of creating IPv6 reverse map zone names uses a nibble format (but uses a PTR RR). The example shows a fairly standard IPv6 delegation of a 2001:db8::/64 address range. The reverse map file is also assumed to lie on the /64 boundary. (If you need an IPv6 calculator.) The dhcpd.conf file is shown for a typical IPv6 configuration:

# global statements are applicable to all subnets
authoritative; # assume this is the only DHCP server on network
# global statements
...
# DDNS statements
ddns-updates on;           # default but good practice
ddns-update-style interim; # only supported active option
allow client-updates;      # default but good practice
do-forward-updates;        # default but good practice
...
# zone clauses are optional and required
# only to define params for DDNS
# may be one or more zone clauses
zone example.com {
  ...
  primary ns1.example.com;
  # uses name format could use IPv6 address format
}
zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa {
  ...
  primary 2001:db8::17;
  # the above can use a dns name, instead of an IP
  # which is probably more flexible
  # primary ns1.example.com.
  # and for IPv6 can be much shorter
}

# must be at least one subnet clause
# in a dhcpd.conf file
subnet6 2001:db8::/64 {
  # useable IP addresses in this subnet
  # can be range or /prefix format (used in example)
  range6 2001:db8::/112;
  # optional use of temporary IPv6 addresses will not update
  # forward or reverse maps as defined by RFC 4941
  range6 2001:db8:0:0:1::/104 temporary;
  ....
  subnet statements
  ....
  # DDNS statements
  ddns-domainname "example.com.";
  # use this domain name to update AAAA RR (forward map)
  ddns-rev-domainname "ip6.arpa.";
  # use this domain name to update PTR RR (reverse map)
}
# other clauses may exist, for example, group or host
# which are not relevant for DDNS configuration
# and are not shown

The skeleton named.conf file to enable DDNS from the DHCP server using only IP security is shown below. It is assumed that both the forward and reverse zone are supported by the same name server for simplicity.

// named.conf assumed at 2001:db8::17/ns1.example.com
options {
  // global options
  ....
  allow-update {none;}; // disable globally - default
  ....
};
// other clauses as required

// zone clauses
zone "example.com" {
  type master;
  ....
  allow-update {192.168.2.33;}; # ipv4 of dhcp server
  allow-update {2001:db8::3c5;}; # ipv6 of dhcp server
};

// reverse zone
zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
  type master;
  ....
  allow-update {2001:db8::3c5;}; # ipv6 of dhcp server
};

Notes:

The allow-update {none;}; in the global options clause is the default but it is good defensive practise to explicitly disable it. Each zone that does allow DDNS update must then be specifically enabled.
The allow-update {2001:db8::3c5;}; in the zone clauses allows only the defined IP address to update any RR in the zone. If DHCP clients on individual hosts can update DNS their individual IP addresses (or range) must be explicitly definedin the allow-update address_match_list structure. Alternatively, multiple allow-update statements can appear in any zone clause.
In the example.com zone both an IPv4 and an IPv6 address are shown in allow-update statements to illustrate that such a configuration is possible. For example, in a dual stack environment separate instances of the DHCP server must be running for both IPv4 and IPv6. Since IPv4 and IPv6 addresses may be freely mixed in a forward map zone file this configuration is highly likely. Reverse map zones for IPv6 use a different format and zone name so the presence of an IPv4 address in the allow-update for the zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa would be an error - updates must always be from an IPv6 address.
The reverse zone is shown as 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa based on the /64 break. This is fairly arbitrary and it could have been based on the /112 which is the useable range allocated in the subnet clause which would have created a reverse zone of 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa - see discusion in IPv6 reverse maps on this topic.
RFC 4941 specifically recommends that temporary IPv6 addresses (used to provide privacy) are not forward or reverse mapped.
DDNS is only allowed to the primary master name server. This name server is defined as the name server which appears in the SOA RR for the zone. Thus, the name server ns1.example.com (defined as the primary in the zone clause for example.com in the dhcpd.conf above) must appear in the SOA RR for the zone example.com as shown:
```
; zone file snippet for example.com
$ORIGIN example.com.
@        SOA ns1.example.com. hostmaster.example.com. (
            ... // other SOA parameters
            )
....
; other zone RRs
....
```

Example 4 - IPv6 - TSIG

The principle behind DHCP-DNS IPv6 is similar to that defined above for IPv4. In order to avoid repeating the background material you are advised to read the IPv4 - TSIG section as well as the DHCP Overview and DHCP Config Layout Notes. This section will focus only on the IPv6 configuration and relevant notes. Finally, if you are running a mixed IPv4 and IPv6 solution please read these important notes, otherwise the sun may fall out of the sky.

Recall, that IPv6 addresses are defined using AAAA (Quad A) RRs and the method of creating IPv6 reverse map zone names uses an IPv6 nibble format. The example shows a fairly standard IPv6 delegation of a 2001:db8::/64 address range (though /48 and /56 are also common). The reverse map file is also assumed to lie on the /64 boundary though alternative configurations are possible. (If you need an IPv6 calculator.)

The key generation process for IPv6 TSIG (and the key handling precautions) are exactly the same as those for IPv4 and are not repeated here. (The sole exception is that we have assumed the forward mapping update key is called ddns-aaaa-rrs to reflect the fact that we are updating AAAA RRs (not A RRs as for IPv4).)

The dhcpd.conf file, assuming the procedures for TSIG generation have been followed, is shown for a typical IPv6 configuration:

# dhcpd.conf fragment
# global statements are applicable to all subnets
authoritative; # assume this is the only DHCP server on network
# global statements
...
# DDNS statements
ddns-updates on;           # default but good practice
ddns-update-style interim; # only supported active option
allow client-updates;      # default but good practice
do-forward-updates;        # default but good practice
...
# zone clauses are optional and required
# only to define params for DDNS
# may be one or more zone clauses
zone example.com {
  ...
  primary ns1.example.com;
  # uses name format could use IP address format
  key ddns-aaaa-rrs; # binds this key to forward (A) RR updates
}
zone 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa {
  ...
  primary 2001:db8::17;
  # the above can use a dns name, instead of an IP
  # which is probably more flexible
  # primary ns1.example.com.
  # and for IPv6 can be much shorter
  key ddns-ptr-rrs; # binds this key to reverse (PTR) RR updates
}
include "/etc/keys/Kddns-aaaa-rrs.+157+xxxxx.private";
include "/etc/keys/Kddns-ptr-rrs.+157+xxxxx.private";

# must be at least one subnet clause
# in a dhcpd.conf file
subnet6 2001:db8::/64 {
  # useable IP addresses in this subnet
  # can be range or /prefix format (used in example)
  range6 2001:db8::/112;
  # optional use of temporary IPv6 addresses will not update
  # forward or reverse maps as defined by RFC 4941
  range6 2001:db8:0:0:1::/104 temporary;
  ....
  subnet statements
  ....
  # DDNS statements
  ddns-domainname "example.com.";
  # use this domain name to update A RR (forward map)
  ddns-rev-domainname "ip6.arpa.";
  # use this domain name to update PTR RR (reverse map)
}
# other clauses may exist, for example, group or host
# which are not relevant for DDNS configuration
# and are not shown

Notes:

The key ddns-aaaa-rrs and key ddns-ptr-rrs statements in the respective zone clauses bind the use of the key-name to any transaction. This means it is possible to have key-per-zone configuration granularity.
DHCP does not require that clauses are terminated by }; as in BIND but it does support this format and happily skips silently over the ;. This feature allows the same key clause to be used unmodified in both BIND and DHCP.

// named.conf assumed at 2001:db8::17/ns1.example.com
options {
  // global options
  ....
  allow-update {none;}; // disable globally - default
  ....
};
include "/etc/keys/Kddns-aaaa-rrs.+157+xxxxx.private";
include "/etc/keys/Kddns-ptr-rrs.+157+xxxxx.private";
// other clauses as required

// zone clauses
zone "example.com" {
  type master;
  ....
  // update-policy and allow-update are mutually exclusive
  allow-update {key "ddns-aaaa-rrs";}; # allowed key
  update-policy {grant "ddns-aaaa-ptr" self * AAAA TXT DHCID;}; 
};
// reverse zone
zone "0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa" {
  type master;
  ....
  // update-policy and allow-update are mutually exclusive
  allow-update {key "ddns-ptr-rrs";}; # allowed key
  update-policy {grant "ddns-ptr-rrs" self * PTR TXT DHCID;}; 
};

Notes:

The choice of directory location for the included keys is a matter of site policy, remember only to set minimal read-only directory/file permissions. When both DHCP and BIND are loaded they initially run as root (to allocate priority port numbers among other functions) before issuing a suid() call to change to their normal (-u) account. The include statements are processed during the root user period which means that key files set read-only under root can be read.
allow-update and update-policy are mutually exclusive - select a strategy based on one or the other statements (though multiple statements of each type may appear in any zone). Both are shown in the same zone clause (a load-time error) for illustrative purposes only.
update-policy allows a ferocious number of options and is a seriously complex statement to implement. Many variation are both relevant and applicable depending on the requirements. The policy shown in the examples is one of many possibilities. The policy says grant (allow or permit) any DDNS transaction which uses the key-name defined (ddns-aaaa-rrs for example.com - forward map, and ddns-ptr-rrs for 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa - reverse map) to update any (*) RR with the same name (self) but only of the defined RR type (AAAA TXT or DHCID for example.com and PTR TXT or DHCID for 2.168.192.in-addr.arpa) all other transactions will fail. Thus, a DDNS transaction with the correct key for, say, joe.example.com will be allowed to update any AAAA, TXT or DHCID RR with the name joe.example.com. The use of TXT and DHCID allows various versions of DHCP, when used in DHCP master/slave configurations, to keep track of updates. When the update source is MS AD the options ms-self or ms-subdomain are relevant. For Kerberos 5 update sources the options krb5-self and krb5-subdomain are relevant.
DDNS is only allowed to the primary master name server. This name server is defined as the name server which appears in the SOA RR for the zone. Thus, the name server ns1.example.com (defined as the primary in the zone clause for example.com in the dhcpd.conf above) must appear in the SOA RR for the zone example.com as shown:
```
; zone file snippet for example.com
$ORIGIN example.com.
@        SOA ns1.example.com. hostmaster.example.com. (
            ... // other SOA parameters
            )
....
; other zone RRs
....
```

DHCP with Mixed IPv4/IPv6

Dual stacked (IPv4/IPv6) environments add a significant amount of confusion and complexity that, perhaps, not even your mother can sort out. In general, they should be avoided like the plague. However, we live in a modern world of antibiotics and strange bosses. The following notes are unlikely to be helpful, but....

In its current form a single instance of DHCP (4.2) will not support both IPv4 and IPv6. Two instances are required one of which must be started with the -6 argument (IPv6) and one with the -4 argument (IPv4). If both instances run on the same server then one needs to use a non-standard dhcpd.conf path (and pid name for start/stop scripts). The following shows a possible solution:
```
# dhcp for IPv4 assumes standard dhcpd.conf location
# the default if neither -4 nor -6 has changed at least once
# always specify it
dhcpd -4 
# dhcp for IPv4 assumes standard dhcpd.conf location
dhcpd -6 -cf /etc/dhcpd6.conf -pf /var/run/dhcpd6.pid  
```
Additionally, service start scripts will need to be modified or created with appropriate settings to allow for Linux users commands like service dhcp6 start.
In general, a better solution is to create a separate world of IPv6 only and IPv4 only systems and progressively (read rapidly) migrate users from one world to the other. IPv6 provides so many tunneling and interworking methods for IPv4 that even the protocol designers get confused. When it comes to DHCP DDNS updating the forward map must be shared between IPv4 and IPv6 (shown and briefly discussed above), whereas the reverse maps are by their nature separate with unrelated delegation paths and can easily be maintained on separate DNS servers.
Carefully consider changing career.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.