Download from the SourceForge project site here.
Please report bugs and add feature requests in the project trackers at http://sourceforge.net/projects/ddnssync/.
Excuse the (lack of) formatting, but I believe the content is more important than the presentation. ;-) Actually, I do plan on making these pages pretty some time in the near future.
ddnssync is a PHP5 based dynamic DNS client. It is designed to support multiple DDNS services and multiple network address detection methods. Currently, there are three types of network detection methods supported and one DDNS service supported. Details on configuring these settings is detailed below.
I designed the application to make it extermely easy to add support for new network address detection methods and to support various DDNS services. It is my hope and expectation that community contributions will be made to help make this application support as many devices and DDNS services as possible. Adding support for a new device or a new DDNS service is as easy as writing a subclass that follows the predefined public interface. External docs will be added at some point as a guide, but I feel the existing classes are documented sufficiently enough by myself such that anyone wishing to contribute new subclasses should be able to do it quite easily.
Functionally, the code base is quite stable at this point. This means I'm quite confident that the application will update your DDNS service (only Sitelutions is supported at this time) with little issue. Of course, bug reports on the functionality are welcomed, as I'm sure they exist.
Finally, why another DDNS client? Well, this project started out as a way to consolidate clients that I was using for Sitelutions and DynDNS. Some of my clients used DynDNS while others were using Sitelutions for their DNS hosting. I wanted a single client that I could support for all of my clients so I started this project. Just when I was ready to write the support for DynDNS, I was told that I could not get a client authorization token required to update DynDNS records, which meant no support for DynDNS. So instead I moved all of my clients to Sitelutions and hence why only one DDNS service is supported at this time - I only use the one service. However, I would like to see many other services supported by this client, but that will require contributions from you.
Here's some answers to some commonly asked questions.
Why do you not support DDNS service X? Why don't you support hardware router Y? You claim this client supports multiple devices and DDNS services, but I only see one DDNS service and a couple of devices supported!
Simply put, personally I only need support for Sitelutions and local ethernet detection because that's all I use. I also wrote support for the HTTP method because I have needed it in the past and may need it again. However, I designed the application to make it very easy to add support for any device, any OS, and any DDNS service. If you ask nicely, I can probably write a class for any DDNS service that publishes its update protocol, however it won't be a priority of mine and so you'll proably get it done faster, but feel free to open a bug for it. Device support is a little different. It is very difficult to write and test support for a Linksys router, for example, if I don't have a Linksys router in my posession. So don't expect support to magically appear from me and it has never been my plan to support all of these devices myself - instead I feel I've designed a very flexible application that makes it easy for the community to contribute support for any device, OS, or DDNS service.
Ok, you've convinced me, how do I contribute support for device X or DDNS service Y?
That's the spirit! ;-) Basically, grab the latest tarball of the source (if you're writing something from scratch then any recent tarball will do) and unpack it. If you're writing support for a new network device then look inside the device directory. All you have to do is write a subclass of Device that implements the public interface as defined in Device.php. If you're writing support for a new DDNS service then look in the dns directory. All you have to do in this case is write a subclass of DDNS that supports the public interface as defined in DDNS.php. In either case, I think you'll find the interfaces easy to follow. Feel free to look at any of the subclasses that are already there for more detailed examples. Once you've written and _thoroughly_ tested your class simply open a ticket in the project tracker and attach your new file to it. After it's reviewed and accepted it will be added to CVS. Please note that no new device/DDNS classes will be accepted without proper documentation so remember to include the docs with your patch (see the web and docs directories for examples of expected documentation).
Why another DDNS client?
As stated above, this started out as a project to consolidate clients I was using for Sitelutions and DynDNS. I wanted one client to do it all. Unfortunately, DynDNS wasn't all that cooperative with my efforts so I then moved all of my client's domains to Sitelutions and decided to finish the code. With enough community contributions, this client could support anything and everything on any OS, etc. That's kind of the ultimate path I see for this. On the otherhand, if no one else likes it then I have a Sitelutions client that I like, which is good enough for me. ;-)
I found a bug! I have a feature request!
Excellent! Simply add it to the project bug tracker at http://sourceforge.net/projects/ddnssync/. Sending bug and feature requests via email is not a good idea as they'll likely get lost in the clutter that is my inbox.
Why must my PHP binary use the CLI SAPI? What's wrong with the CGI SAPI?
Only the CLI SAPI ensures that the command line arguments will be passed to the script. The CGI SAPI does not promise this and therefore I chose only to support the CLI SAPI, which makes sense since this is a command line application. If you know your CGI binary is configured to support command line arguments then you can force the install and you should have no problems, but I don't recommend it (since I never tested this code once with the CGI SAPI).