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 is not possible to have a CNAME and an SOA record for the same name. So the zone for site.com cannot have a CNAME record for site.com.

• It is not possible to have a CNAME and an MX record for the same name.

• If mail is sent to a host name defined in a CNAME record, a standards compliant MTA will re-address the mail to the canonical host name, so that the receiving MTA must accept mail addressed to the canonical/GnuDIP host name.

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/multinsupd.pl 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

• support for IPv6

  This will eventually be necessary.

• instructions for byte compiling the GnuDIP Perl scripts

  Hopefully the Perl byte code generation and reload facilities will soon be easily usable. When that occurs, the necessary steps for GnuDIP should be documented.

  Precompilation should improve the start up time for the (X)INETD server script and the web tool when it is not running under mod_perl.

• multiple language support

  A set of patches could be developed which alter the base file set for other languages. Those text strings in HTML, E-mail and messages from the client as well as documentation, intended to be seen by end users. would be translated.

  People who wish to provide a GnuDIP service for speakers of a particular language could then apply the patch for the desired language.

Internal Restructuring

• improvements to name space management for functions

  Each Perl module in GnuDIP has its own name space for variables. Variables that are to be visible to more than one module must be declared as "global". This is very convenient. However this is not so for function names, and the GnuDIP code has grown to a size where this is a hassle, and possibly a deterent to making code changes. It would be desirable to use the Perl "package" statement in each GnuDIP module to provide the same sort of "local" name space for function names. It would then be necessary to use the "Exporter" Perl module to export those function names meant to be global.

  This would be quite a sweeping change, and would require careful testing. It would be a good project for someone who wanted to become familiar with the GnuDIP code, and add new features to it.

• multiple language support

  The GnuDIP code could stand to be restrucured with multiple language support in mind. A user of the Web Interface should be able to select their prefered language, and see all prompts and help screens in that language. The GnuDIP client should also support multiple languages.

  As part of this, all messages would have to be extracted to a separate Perl module, and imbedded in HTML by using Perl variables. The "Help" pages would have to be presented by a simple CGI script in order that different versions of the HTML files would be provided depending on the language chosen. The prefered language could be saved in an HTTP cookie.

  Initially, there would only be an English version of all messages and HTML files, unless the person who did this spoke some other language(s). But it would become simple for non-technical people to provide new translations.

• atomic file replacement for "flat file database" mode

  The code that reads and overwrites the files used in flat file database mode simply overwrites the existing files. In principle, this could result in file corruption if two processes update a file at the same time.

  The author decided that this was not a problem in this case because each file is very small, and will probably be read or written in a single I/O, and because the usage pattern of these files would make it extremely unlikely that a collision would occur. The preferences file, once set up, is never rewritten in normal operation. A user file is only rewritten if a transaction has provided the correct user password. So a user file could only be trashed if someone knowing the password for the user manages to run two updates for the same user within milliseconds. And if they achieve this, only that user file would be damaged (serves them right!).

  However, instead of directly overwriting files, a new file with a randomly generated name could be created, and then this file renamed, thereby overwriting the directory entry. The Perl documentation however warns that there can be portability issues with rename - even cautioning that some Unix variant may not clobber an existing file. If so, then this could end up being more trouble than it is worth.

• move the GnuDIP "*.pm" files from lib to lib/gnudip

  There is a potential at the moment for some GnuDIP module name to block some other non-GnuDIP module.

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 ("snmpqry.pl"). It uses a pure Perl SNMP implementation to retrieve the routing table entry interface number for address 0.0.0.0, 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:

• Many installers of GnuDIP may not want such a feature.

  There are a number of Virtual Domain/DNS providers who provide a free GnuDIP-style service as a "loss leader", to get you in the door. They then charge for custom DNS hosting.

  There is also some promotional advantage to them to have other people using a subdomain of their domain.

  So many sites may not want this "MyGnuDIP" add-on, unless it has hooks for billing code to be added (ugh!).

• The same end result can be achieved by setting up a DNS server on the client machine.

  This is discussed in owndomain.html.

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 http://gnudip2.sourceforge.net/dynclient/. However a fully Open Source client requiring only other Open Source tools (e.g. cygwin) may still be desirable.