DuckCorp » DDNS

h1. Logging

The following verbosity levels are available:

* quiet: display only errors

* normal: informative and warning, as well as errors

* verbose: everything above plus debug information

Logging is always done on console when using clients, and never on servers; verbosity can be adjusted in 'log/console_level'.

Logging to file can be done on servers and ddns-client if a log directory with proper permissions is given in 'log/path'.

h1. DNS

DDNS is used with Bind, so we currently cannot publish configuration example using another server but there's no reason it should not work with another software.

DDNS only works using TSIG; unsecure communication with the DNS server is not possible (and will not be implemented). To further improve security, your DNS server and DDNS services hostnames should be on a DNSSEC-secured zone and your resolvers on all involved machines should check DNSSEC information. The zone to be dynamically updated should also be DNSSEC-secured.

With Bind9 (bind9utils) you can create a keypair using:

<pre>

dnssec-keygen -a HMAC-SHA512 -b 512 -n USER <key-name>

</pre>

with <key-name> being the name of your configuration.

You need to create a key entry in your Bind configuration using the same exact name, like for example:

<pre>

key <key-name> {

  algorithm hmac-sha512;

  secret "<secret-key>";

}

</pre>

with <secret-key> being the space-separated two-part hash inside the '.key' file.

You can then allow this key to update a zone by adding in the zone block:

<pre>

allow-update { key <key-name>; };

</pre>

If you need more information, read the Bind manual.

h1. Webserver

This part of the configuration is needed for the server parts only.

DDNS was only tested using Apache Httpd, thus we can only provide configuration examples for this software but others should work too.

The server parts needs to run Ruby. This can be achieved very easily using a Passenger-enabled vhost (read the Phusion Passenger documentation).

The webserver needs to provide authentication because DDNS does not provide any way to handle accounts. In our installation we use a LDAP authentication provider with a custom objectClass for such accounts.

In order to check which DNS entries an account is allowed to modify, this provider must return a custom multi-valued field listing hostnames to be authorized. In Apache Httpd a provider can fetch extra data in addition to the uid, then available as _AUTHENTICATE_*_ environment variables to the script. You need to call this field 'ddnsHostname' (case is not important).

Here is our LDAP configuration as example:

<pre>

attributetype ( duckcorpAttributeType:32

  NAME 'ddnsHostname'

  DESC 'Dynamic DNS Hostname'

  EQUALITY caseIgnoreMatch

  SUBSTR caseIgnoreSubstringsMatch

  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectclass ( duckcorpObjectClass:23

  NAME 'ddnsUser'

  SUP top AUXILIARY

  MUST ( ddnsHostname ) )

</pre>

And part of the ApacheHttpd configuration as example:

<pre>

<Location />

  AuthName "DDNS"

  AuthType Basic

  AuthBasicProvider ldap

  # export ddnsHostname attribute

  AuthLDAPUrl ldapi:///<base-dn>?uid,ddnsHostname?sub?(objectClass=ddnsUser)

  AuthLDAPBindDN <bind-dn>

  AuthLDAPBindPassword <bind-pw>

  AuthLDAPRemoteUserAttribute uid

  AuthLDAPDereferenceAliases never

  Require valid-user

</Location>

</pre>

(just fill-in <base-dn>, <bind-dn> and <bind-pw> with your own values)

h1. MyIP server

You don't need to configure anything.

h1. MyIP client (ddns-myip [<iface>])

You need to provide an 'url' for your MyIP service provider. You may also provide a 'proxy_url' if you cannot surf the Internet without a proxy.

If you are multihomed, you might want to setup a DNS entry for each provider; in this case your can provide an interface name as command parameter. A default interface to use to find your main IP without having to provide an interface name every time can be specified in the 'default_interface' setting.

h1. RegIP server

You need to provide 'regip.ns_server' which is the hostname of your DNS server.

You may provide the TTL used when creating DNS entries in 'regip/ttl'.

You also need to provide the path to your TSIG private key used to authenticate to your DNS server in 'regip/key_file'. The name of this file needs to be the unaltered name generated by the 'dnssec-keygen' command, and your public key must be available in the same directory.

h1. RegIP client (ddns-client)

You need to provide a 'regip/url' for your RegIP service provider. You may also provide a 'regip/proxy_url' if you cannot surf the Internet without a proxy.

You also need to provide a 'regip/passwd' to authenticate with your account.

Then comes the list of DNS entries you wish to configure, as keys in the 'profiles' hash. Each entry may specify an 'ipv4' and/or 'ipv6' entry. If you do not care about one of the protocol, just don't specify it and it will be ignored (meaning this entry will _never_ be altered).

Each ip field can have the following values:

* <ip>: a manually chosen IP

* none: which mean you do not want any associated IP (if such DNS entry exist, it will be deleted)

* auto: use MyIP to find your external IP

If you are multihomed you may provide an 'interface' parameter in a profile to force using a specific provider.