GnuDIP Logo

GnuDIP Client-Server Update Protocol


There are in fact two update protocols. The original protocol involves a direct TCP connection by the client to the server. There is also an adaptation of the original protocol to HTTP (web server protocol). The HTTP protocol is more convenient for authors of generic Windows dynamic DNS update clients, such as DynSite.

With either of these protocols it is not possible for wire tappers to determine the clear text password, nor is it possible for them to "spoof" the update server using captured and modified update messages.


The Original Direct TCP Connection Protocol

ASCII is (of course) used for representing printable characters.

The client makes a TCP connection to the appropriate port on the server host. This port is normally 3495, but a GnuDIP site could choose another port.

As soon as the connection is established the server will send a randomly generated 10 character "salt" string. This is used in the following algorithm for hashing the password:

The update message character string is then transmited to the GnuDIP server. This must be in one of these forms:


The HTTP Based Protocol

The HTTP version of the protocol requires the client issue an HTTP GET request, parse the response, use MD5 to obscure the password, issue a second HTTP GET request and parse that response. We first give a conceptual overview, then a concrete example.

If a GnuDIP site operator follows the default installation procedure, the path part of the URL (the part after the host name) for the HTTP update server CGI script will be /gnudip/cgi-bin/gdipupdt.cgi.

In the first HTTP GET request, no query string (the part of an URL after the "?") is provided. It is interpreted as a "request for a salt". The response contains three pieces of data:

  1. a randomly generated 10 character "salt" string
  2. a "time salt generated" value
  3. a "signature"
These values are passed in HTML meta tags, as in this example:
<meta name="salt" content="XLCDgXvzSo">
<meta name="time" content="1002164730">
<meta name="sign" content="8278f108c83d822048ce0375bede5c15">
Each meta tag will be on its own line and left justified on the line. The white space gaps before "name=" and "content=" will each consist of a single space. The tags will be in the order shown. There will be no other HTML meta tags in the response.

The salt is used in the following algorithm for hashing the password:

Now the second HTTP GET request is issued. In this request the query string (the part of an URL after the "?") contains the following parameters:

  1. the "salt" from the first response ("salt=")
  2. the "time salt generated" value from the first response ("time=")
  3. the "signature" from the first response ("sign=")
  4. the GnuDIP user name ("user=")
  5. the GnuDIP domain name ("domn=")
  6. the MD5 digested password created above ("pass=")
  7. the server "request code" ("reqc="):
  8. the IP address to be registered, if the request code is "1" ("addr=")
A request with a request code of "1" and an address of "0.0.0.0" will be treated as an offline request.

This is an example of a query string:

salt=XLCDgXvzSo&time=1002164730&sign=8278f108c83d822048ce0375bede5c15&user=macdonnell&pass=305dff8b78e694a02eafb0c19e48292f&domn=dyn.mpis.net&reqc=0&addr=192.168.0.4

The response to the second request contains:

  1. the return code
  2. the IP address that the server registered, for request code "2"
These values are again passed in HTML meta tags, as in this example:
<meta name="retc" content="0">
<meta name="addr" content="24.81.172.128">
Each meta tag will be on its own line and left justified on the line. The white space gaps before "name=" and "content=" will each consist of a single space. The tags will be in the order shown. There will be no other HTML meta tags in the response.

This protocol allows the GnuDIP server to "time out" the prompt. If the response does not come within 60 seconds (for example), it would be denied. The signature is generated using a key known only to the server. This allows the server to know that the "salt" and "time generated" value are valid, without having to maintain state information on the server side.

There is a transcript of three actual protocol exchanges (done using the Perl GnuDIP client) in protocol_sample.txt.