Most private households with Internet access are connected such that their IP address is not always the same. Typical examples are ADSL connections where the provider enforces that the connection must be reestablished at least once a day and where you get a new temporary address whenever this happens.
This becomes a problem if you want to access one of the systems in your home network over the Internet while you are elsewhere. If no-one at home can tell you what the current address is, you need some other means for obtaining that information. (And you also have to make sure that you can pass through whatever firewalls are in your intended path.)
The solution most often chosen for this problem relies on a
DNS (Domain Name
System) service provider who offers the possibility of doing online updates
of the address record for the domain whenever the address changes
(dynamic DNS
or
DDNS
).
Most of these providers offer a fairly simple interface where the domain's
owner merely has to issue an appropriately customized
HTTP
GET request,
and there also exist several providers who offer such a service free of charge,
usually with limits on the number of supported domain names and the rate of
updates per time.
This leaves the problem of when and how to automatically trigger an update.
The simplest case is where your Internet connection is associated with a single (but changing) global IPv4 address and where the router connecting you to the Internet has DDNS client functionality and is able to forward ports. You just enter the relevant information in the router and you are done with DDNS; all that remains is the configuration of port forwarding.
The situation becomes more interesting if your Internet service provider allocates a global but changing IPv6 subnet to your connection. Such a subnet is usually more than sufficient for every host in your home network(s) to obtain a (temporary) global IPv6 address, but you now should define a domain name for every host you want to reach from the Internet. For this to work, you usually need an appropriate DDNS client on every such host.
For UNIX systems (in particular Linux-based ones) there exist a number of open-source DDNS clients. When I started to need such a client, I looked at some of them, but was not particularly impressed by their concepts, interfaces, modularization, flexibility, and reuse of existing functionality, let alone their documentation. I therefore developed another solution: duhg (DDNS updates via HTTP GET).
With duhg you need a configuration file having a section for every domain you wish to keep up to date. A simple file ~/.duhg might look like this:
domain yours.example.com {
addr_cmd = "my_ip"
user = "the_greatest"
password = "very_secret!"
url_template = "https://example.com?host=<domain>&myip=<ipaddr>"
}
The value my_ip
in this example is assumed to be a command
provided by you which prints, on standard output, the IP address (IPv4 or IPv6)
you want to be associated with the domain yours.example.com
.
Now every command-line invocation
duhg yours.example.com
would invoke my_ip
in order to obtain the desired value,
compare it with the address to which yours.example.com
currently resolves, and
if there is a difference, perform an HTTP GET request to a URL constructed with
the template given in url_template
and using the specified
user
and password
values as credentials.
Further possibilities for configuration and use are described in a manual page.
duhg is written as a collection of UNIX shell scripts and relies on the existence of a command for executing an HTTP GET request (the default is curl or wget, whichever is available), and the DIG utility from the BIND tools.
The software is released under the GNU GPL, version 2, and can be found in the directory http://home.htp-tel.de/lottermose2/duhg/dist. The package is distributed as a gzipped tar archive (duhg-version.tar.gz) accompanied by a digital signature (duhg-version.tar.gz.sign). The archive contains the files necessary for generating a Debian package or an RPM package from it.