Work is underway to make dynamic DNS updating smooth, safe, and correct for OpenVPN users.

At this time, the project is brand new, and should only be approached by users comfortable with troubleshooting. It is assumed that early testers know how to configure a DNS server for dynamic updating.

This document will detail how to install and configure the current offering.


This document will assume you already have a working OpenVPN server, and your own DNS server that accepts dynamic updates from a DHCP server. If you don't, you don't actually need a DHCP server, but you will need to set up a DNS server with dynamic forward and reverse zones in the same way.

The OpenVPN server must be able to reach the DNS server on port 53.

You will need a reasonably recent copy of perl and a connection to the Internet to download from CPAN.


As root or as the user openvpn runs as,

# cpan install Net::OpenVPN::DDNS

It will install a bunch of dependencies, including Net::DHCP::DDNS that does the meat of the work.


See /etc/openvpn/ddns/update for global configuration and notes. It is recommended that configuration be done in the DNS zone itself, identified by the server's IP, although one could conceivably rely entirely on tweaking the global defaults in that file. This would be overridden by an update, though.

It is assumed that any OpenVPN server will have an "ifconfig" directive where the first argument is the server's address on the tun0 interface. This address can be considered "canonically owned" by the OpenVPN instance, and therefore, openvpn owns its reverse domain name as well.

For example, the server named "" having a tun address of would also own, and have at minimum the following DNS resource records: IN PTR
                      IN TXT ""

There is no need to configure what nameservers to use. That piece of information is expected in the zone's SOA record, and if it isn't correct, the master name server will not be found, and none of this will work.

Installing DDNS TSIG Keys

You will also need the update keys. You did keep them from when you set up the DNS server's dynamic zone, right? Simply copy the Kmykeyname.number.number.key file to, in this example, /etc/openvpn/ddns/keys/com.example.inside and set them chown root:openvpn, chmod 440. The file can also simply contain keyname=value if you don't have the original ddnssec-keygen output handy.

If, for whatever reason in tarnation, you're running a dynamic DNS server that does not require keys, then simply don't install any. The script will proceed without them.

Sharing a Zone with DHCP

Consider a laptop that plugs in at the office and then VPN's in from home. It is likely the DHCP server hasn't removed the address yet, so Net::OpenVPN::DDNS will need to recreate the DHCID record (or TXT, if it's isc-dhcpd) in order to safely override the existing A/AAAA record. In order to do this, it needs the same raw information that the DHCP server had.

The DHCP server might have generated the DHCID/TXT record from the hardware address, or it might have been given a value by the client; either a dhcp-client-identifier (v4) or DUID (v6). Whatever the case, the detail needs to be recorded on the server by an administrator, like this:

echo 'hwid = "01:23:45:67:89:AB"' > /etc/openvpn/ddns/clients/shortname

The prefixes are "hwid" for an ethernet address, "dcid" for a dhcp-client-identifer, and "duid" for a DUID. It is most likely the latter two will contain lots of escaped binary characters in the string.

In the absence of this datum, a valid dhcp-client-identifier will be generated using the client common_name.

ISC DHCPD Server Integration

If the OpenVPN server runs on the same box as the DHCP server, it can steal the client identifier from the leases file directly, IF the certificate common_name matches the client's short hostname. Configure the path to the leases file in /etc/openvpn/ddns/update.

To Do


OpenVPN 2.3.2 isn't exporting all the variables required for IPv6. A patch is currently being kicked around.

DUID and dhcp-client-identifier

It would be well if the client supplied the same opaque identifiers used by the system DHCP client.

More Documentation and Testing

Nuff said.

Last modified 4 years ago Last modified on 02/15/14 05:22:51