GnuDIP Logo

GnuDIP Release 2.3.5 - TODO File

GnuDIP is now only minimally maintained. New development will not occur unless a new developer steps forward.

These items are just here as food for thought.

Better Documentation

In particular the "Help" available from the Web Tool could be better.

A MacPerl Client Package

There is a port of Perl for MacOS called MacPerl.

Perhaps someone could create a MacPerl client package similiar to the Windows ActivePerl client package.

Navigation Buttons in the GUI

The GUI interface might be more user friendly with navigation buttons. It should be noted that this would have the drawback of accumulating cached pages on the browsers "Back" button.

Have the Client Check for a Default Gateway

The GnuDIP client at present attempts to connect to the GnuDIP server whenever it determines that the address it recorded at the time of the last update is no longer valid, or it has no recorded address. But this will be the case if the external connection no longer exists. So when the client is being run at intervals, in order to "poll" for IP address changes, the client will repeatedly attempt a connection, timing out each time. Perhaps a check could be made to see if there is a "default gateway" to the internet before attempting to connect to the GnuDIP server.

A Mechanism to Link Non-GnuDIP Host Names to a GnuDIP Host Name

Some sites use DNS CNAME records to point non-GnuDIP host names at a GnuDIP ("canonical") host name. The objective is to provide dynamic IP support for these non-GnuDIP domain names.

This can be problematic in some circumstances. For example:

It would be better if the CNAME record could be replaced with an A record.

To remedy this, GnuDIP could maintain a list of host names for which an A record update should be done, whenever an A record update is done for the GnuDIP host. This list would be maintainable only by a GnuDIP administrative user. It would be up to the GnuDIP site operator to set up the appropriate non-GnuDIP dynamic domains.

It would be possible in principle to implement this as a separate software component, by providing a "drop in replacement" for the nsupdate command. To make this more efficient, GnuDIP could be modified to be able to either invoke nsupdate, or alternatively send the update information to a UNIX domain socket. The "add on" component could then provide a daemon to process these updates, rather than a replacement for nsupdate.

Please note that since this blurb was first written, the script gnudip/sbin/ has been written, to filter the commands being passed to the nsupdate command, in order to insert non-GnuDIP aliases for GnuDIP host names. See the comments in the script, as well as the example and comments in gnudip/etc/gnudip.conf, gnudip/etc/minidip.conf and gnudip/etc/multinsupd.conf. This script goes a long towards addressing this blurb. There is however no web GUI.

Per User TTL Specification

The web interface could allow an administrator to set a TTL value on a per user basis. Users that are observed to have a high DNS volume could have their TTL value raised, to increase caching and reduce the load on the GnuDIP DNS server. This would have the drawback of making the dynamic DNS service for that user less responsive to IP address changes.

Please note that since this blurb was first written, changes have been made to allow a user level TTL override to be done from the gnudip.conf (or minidip.conf) file, in the same way as for domain level override. There is however no web GUI.

Automatic Server Abuse Detection and Prevention

An effort could be made to detect server abuse automatically, and take steps to stop it. For example:

  1. The server could record the most recent login attempt, successful or not, for all host names, not just registered hosts. A separate table would be used for this. There would be a system (or per host) parameter for the minimum acceptable time between updates. If an update arrives for a host within this interval, the server would disable the host (creating it if necessary!).

    Note that automatic disabling of a host would not be done for updates for a valid user but with an invalid password. Otherwise it would be possible for a third party to disable any GnuDIP host's DNS entry. This would be done only when the host does not exist or the login succeeds. It may also be desirable to have a flag for hosts that the administrator can set to exempt a host from this regimen.

  2. A utility could be written to scan the BIND named log for activity for GnuDIP users. At intervals the activity levels for each user could be assessed, and adjustments to the TTL value for each user adjusted to reduce the DNS load.

Use of Windows IP Interface Change Notification

On later versions of Windows, it is possible for a daemon process to request a notification when a change occurs to any IP interface. The GnuDIP client could use this when running in "daemon mode", in addition to the current polling. This would provide more timely detection of IP address changes.

However the author does not own a recent enough version of Windows to test this, and is not going to give any more money to Bill Gates until he absolutely has too.

General Enhancements

Internal Restructuring

More Sample Scripts for the Use of a DNS Server on the Client Machine

As discussed in owndomain.html, users may use their own domain name with a dynamic IP address if they are willing to run BIND on the client machine.

More documentation and sample scripts could be written explaining how to do this.

Documentation and samples for tinydns and other DNS server software could also be written.

Sample Scripts for Querying NAT Devices for their External IP Address

The current support for operation of the client behind closed NAT devices should handle all but very exceptional cases.

However if the NAT device itself is behind an IP masking/anonymizing proxy, the GnuDIP server will not be able to see the external IP address of the NAT device, and so will not be able to return it to the client.

In this situation it would be necessary for the client to directly query the NAT device for its external IP address.

Ideally, all closed NAT devices would implement MIB-II / SNMP. Most Linux distributions do not install this capability by default. One must install net-snmp in order to support this. This fact causes the author to wonder whether very many vendors of NAT devices have implemented this.

A sample script is currently provided in the client package to query for the external address of a host using MIB-II/SNMP (""). It uses a pure Perl SNMP implementation to retrieve the routing table entry interface number for address, and then scans the IP address table entries for a matching interface number. The client script can invoke this sample script using the "-q" option.

An SMTP Monitor Daemon

This would be a process to run continually, connecting to the SMTP port for particular GnuDIP users, to ensure that mail sent to their host name will be correctly received. When an SMTP agent does not respond correctly to a TCP connection, the monitor would automatically change the address for the associated GnuDIP user to a "dead" IP address, so that packets sent to it are dropped.

This would ensure that the originating SMTP agent sends E-mail to the "backup" SMTP agent instead and that the backup SMTP agent does not bounce this E-mail.

Original addresses would be cached. For subsequent checks for that GnuDIP user, if the address has not been reset by an update from the associated GnuDIP client, the original address would be retested and restored if found to work again.

An Extension to GnuDIP to Handle Any Domain Name

This could be built as separate add-on component for GnuDIP to make thngs simpler. We will refer to it here as "MyGnuDIP".

Zones have to be individually defined in the BIND named.conf file, or files that it includes. These files must be parsed by named whenever it starts up, or whenever an "rndc reconfig" command is issued to add or remove zones. Almost a megabyte of sequential files would need to be parsed when a new domain is created, once there are about five thousand users. This does not scale well.

Nevertheless, MyGnuDIP could maintain a sequential file of zone definitions which has an "include" statement for it in the named.conf file, and generate an "rndc reconfig" command whenever this was changed.

It would also be necessary to create a protocol and daemon software to propogate new zones to slave servers.

And of course an elaborate (depending on how much detail of the contents of the zone the user may maintain) web interface would have to be built. The blurb "Mechanism to Link Non-GnuDIP Host Names to a GnuDIP Host Name" above would be rolled into this functionality. MyGnuDIP "A" records would refer to a GnuDIP domain name, and would be updated whenever the corresponding GnuDIP "A" record was updated.

To make sure no one else can "hijack" a domain they do not own on the MyGnuDIP server, the following scheme could be used. A user can claim an existing domain name if an SOA query for that domain does not return the name of the MyGnuDIP master DNS server. It is true that a user could have a struggle with someone else until they get the domain name "nailed down". The E-mail address could be used to nofify people when their domain name is claimed.

The SOA query would be done using the BIND dig command.

It should also be noted here that:

C Packaged by GNU Autoconf for the (X)INETD Server

The Perl version of this server has to be compiled each time the server is run.

One could write a C version of this server. Also, most open source C system software now uses GNU autoconf to facilitate portability.

This may be less of a concern once the Perl byte-code compiler and interpreter modules reach maturity. It may in fact not be a major issue in any case.

C Packaged by GNU Autoconf for the GnuDIP Client

The Perl version of the client has to be compiled each time it is run.

Also, because the Perl "infrastructure" must be in place for it to work, it does not lend itself to being invoked from another program, such as a GUI front-end (e.g., C/KDE, C/GNOME, C/MFC, C/wxWin, VB, Delphi).

One could write a C version of this server. Also, most open source C system software now uses GNU autoconf to facilitate portability.

Note that cygwin makes the usual GNU C development environment available for Windows.

The client functionality could also be made available as a C API available through shared libraries (for Linux "shared library" == "*.so"; on Windows "shared library" == "*.dll").

This would allow people to develop nice looking GUI-s using the plethora of GUI development tools now available, without having to understand all of the nasty networking/DNS issues associated with GnuDIP.

Windows GUI Client

Windows users like and are used to GUI interfaces.

To avoid completely rewriting the Windows client, one could use the Tk and Win32::API Perl modules to write a Windows GUI client. This could be packaged for installation using Microsoft Software Installer (MSI) and/or Inno Setup. The necessary pieces from ActivePerl could be included to make it stand-alone.

The Web Tool provides a reasonably easy to use the GUI interface for manual updates. This is particulary true if the user sets up a Desktop Shortcut for their "Quick Login" URL. If the user wants to be able to manually update several servers at once, they can install the Perl client and set up a Desktop Shortcut to "gdipc.bat". Also, experience at legacy GnuDIP sites showed that most GnuDIP users used the browser to update, even though there was a Visual Basic GUI client available.

The main advantage of a GUI windows client may be to provide an alternative method to "gdipc.bat" for automatic detection and reporting of IP address changes. A Windows GUI could remove the need to use a DOS box, notepad and the Windows Task Scheduler GUI interface for configuration. The need for these activities may deter some less technical users from using "gdipc.bat".

Please note that since this blurb was first written, an Open Source Windows GUI client has been written using Delphi - see However a fully Open Source client requiring only other Open Source tools (e.g. cygwin) may still be desirable.