jdd: Java DynDNS client
Hosted by SourceForge.net Logo
Go to SourceForge.net project page
Download JDD 0.7 for Unix/Linux
Download JDD 0.7 for Windows
(Both versions require Java 1.3 or later)

JDD is an open source Java-based update client for DynDNS (and Dynu). If you aren't comfortable editing XML files, you'll probably be happier with a different one. On the other hand, if you can deal with a little XML, JDD could be a good choice for you.

JDD could also be a good choice if you know some Java and need some functionality that isn't provided by other dynamic DNS clients--perhaps you use a less-well-known dynamic DNS service that has its own update protocol, or you want the LCD in your 3.5" bay to show your current external IP address. JDD is specifically designed to be modular and easily extensible.

This document was rather hastily thrown together--I'm sorry I haven't found the time to make it better organized and easier to understand. And for now, the docs for module writers is nonexistent. If you're interested in extending JDD or if you simply need help getting it running, please e-mail code@joecheng.com.

How it works

JDD breaks the problem into two pieces: detecting when your IP address changes, and doing things in response to IP address changes. Monitors are responsible for the former, and updaters take care of the latter. For example, if your host boink.dyndns.org is behind a Linksys broadband router, you would setup JDD with a linksys monitor and have a dyndns updater attached to it.

Monitors can have more than one updater, so if that same host has a dynu.com alias, you can also attach a dynu updater to the same monitor--all updaters will get triggered whenever the monitor notices the IP address changed. There's also no limit on the kinds of actions updaters can carry out: if, say, you'd like to receive an AIM instant message anytime your IP address changes, you could write an custom updater (in Java) to do that.

Configuring JDD

JDD figures out what monitors and updaters are available to it by reading modules.xml. The defaults should be suitable for most users, unless you want to monitor a broadband router that is not listed.

After being told what monitors and updaters are available, JDD needs to know what monitors and updaters you want to use and what parameters to pass to them (username/password, hostname, how often to check for IP address changes, etc.). The config.xml file provides this information. All users will need to edit this file before starting JDD. If you are using a supported broadband router (or using web IP checking) in conjunction with DynDNS or Dynu service, you will probably be able to figure things out by reading the comments in the included config.xml. But if not, read on.

Simple config block syntax:

<monitor_name param1="value1" param2="value2">
    <updater_name param1="value1" ... param99="value99" />
    <updater_name param1="value1" ... param99="value99" />
</monitor_name>

As you can see, updaters are defined in the context of a monitor. In other words, a monitor can have zero or more updaters associated with it, but an updater is always associated with one and only one monitor. Each time a monitor detects an IP address change, it notifies its associated updaters.

The parameters of the monitors and updaters are entirely dependent on the implementation of that particular monitor or updater. See below for documentation on individual parameters.

Multimonitor config block syntax:

<multimonitor>
    <monitors interval="10:00">
        <monitor_name param1="value1" param2="value2">
        <monitor_name param1="value1" param2="value2">
    </monitors>
    <updaters>
        <updater_name param1="value1" ... param99="value99" />
        <updater_name param1="value1" ... param99="value99" />
    </updaters>
</multimonitor>

The preceding configuration style can be used to set up redundancy among monitors. JDD will use the first monitor; then, if it fails, continue on to the second; and so on until the end of the list. At that point, JDD will sleep for the amount of time specified in the interval attribute, then start again from the top of the list.

In a multimonitor setup, all updaters are always invoked when IP address change is detected, regardless of which monitor in the list is currently active.

Module Reference

Note: All time parameters are specified in the following format:
[[[dd:]hh:]mm:]ss

For example, "10" is ten seconds, "5:30" is 5 minutes 30 seconds, and "1:12:05:30" is 1 day, 12 hours, 5 minutes, and 30 seconds.

Monitors

Element Name(s) Attributes
web_shat or
web_dyndns or
web_whatismyip

interval (required)
time between polls of IP address

All broadband routers
(any one of the following)
linksys
watchguard-soho
netopia-r910
smc-barricade
netgear-rt3xx
maxgate-ugate3x00
3com-3c886a
sohoware-nbg800
xsense-aero
alcatel-stp
allnet-1298
3com-oc-remote812
e-tech
cayman-3220h
vigor-2200usb
dlink-614

username (required)
router admin webpage username

password (required)
router admin webpage password

routerAddr (required)
hostname or IP address of router

interval (required)
time between polls of IP address

Updaters

Element Name Attributes Subelements
dyndns

system (required)
The system you wish to use for this update: 'dyndns' will update a Dynamic DNS hostname, 'custom' will update a Custom DNS hostname, while 'statdns' will update a Static DNS hostname. (Chances are you want 'dyndns'.)

username (required)
Your DynDNS username.

password (required)
Your DynDNS password.

wildcard (optional)
Enable/disable wildcards (ON to enable). If omitted, will default to OFF. The wildcard aliases *.yourhost.ourdomain.ext to the same address as yourhost.ourdomain.ext.

mx (optional)
Specifies a Mail eXchanger for use with the hostname(s) being modified. The specified MX must resolve to an IP address, or it will be ignored. Note: Providing no MX setting (or an MX that doesn't resolve properly to an A record) will cause the hostname's MX record(s) to be removed. A NOCHG option similar to that of wildcard will be provided in the future, but is not available yet.

backmx (optional)
'true' or 'false'. Request that the MX in the previous parameter be set up as a backup MX.

offline (optional)
'true' or 'false'. Sets the hostname(s) to offline mode. This feature is only available to credited users.

host (at least one required)
Each hostname you wish to update with these parameters should be specified within a <host> tag.

 

TODO: Add dynu module reference.
TODO: Add details for writing your own modules.
TODO: Describe running as service in Linux, Win NT/2K/XP.