PHP cURL: CLI DtDNS Updater 1

From The Uniform Server Wiki
Jump to navigation Jump to search


MPG UniCenter

UniServer 5-Nano

cURL CLI DtDNS Updater - Part 1

Boundaries between CLI and Server scripting at times are a little blurred it can be easier to develop scripts on a server that are destined for CLI implementation.

This page is no exception, on our simulation server we are going to look at simulating DtDNS’s update page. It’s easier to see what’s going on if we use a test server to access this page using Curl and then convert the script to CLI.

Simulation has the advantage all testing is local removing bandwidth from live servers and possibly incurring the wroth of a draconian dragon (having your IP address band from their servers).


Any provider worth their salt will provide material necessary to use their service. It should be easily accessible for example perform a Goggle search for “dtdns IP updater specification” hey that’s neat gives try that with “dyndns IP updater specification”

OK Not so easy, but the information is there and

Anyway my point is you need a specification otherwise you cannot create a simulation script. We are targeting DtDNS have the specification how often does it change, always a reasonable indicator that they have not got it right. OK last changed 02/12/05 although internal server operation may change the external user interface has not.

That means you can reliably code to their specification.

Simulation Script Information

Ideally we would like to test against a real page however after reading the specification transpires a ColdFusion template is used. This has been configured in such a way to the outside world it looks like a CGI script were values are passed using the GET method.

This template is accessed using one of two URLs


Although it is possible to run files with extension cfm as PHP scripts its easier to just use a php extension. Anyway there is nothing to prevent us creating a simulation script.

For connivance I have reproduced part of the specification for name-value pairs and returned messages below (Note I added message 8 this seems to have been missed from the spec.):


name-value pairs



This is a required field that will specify what the member's hostname (or domain) is. This value should ALWAYS be a fully qualified domain name. It should be a sub domain of one of the available DtDNS domains, or a full domain that DtDNS is hosting. Please check the hostname for invalid characters and spit out an error if you find any. See O'Reilly's DNS and BIND 3rd ed. for a complete discussion on what characters are and aren't valid in hostnames and domain names.

  • NOTE: Hostnames are now passed using the full hostname and the domain name it's on, not just the hostname (,, etc.). Full domain names are passed using just the domain name (ex:,, etc.).



This is a required field that will specify the member's password. This will be compared to what is stored in the userbase for the specified hostname. If they do not match, an error (specified below) will be returned.



This field will specify what IP address to update to. If no IP field is specified, the server will take the IP address the request was recieved from.

We will attempt to determine if the user is behind a proxy server by testing several common header variables.

We recommend giving the user the option of not sending the IP address with IP updates if they are behind a NAT router. Hardware clients that do not act as a direct bridge should send the user's WAN address, and hardware clients that act as bridges should not send an IP address.

DtDNS now provides an "offline IP" for our members to use. By pointing their hostname or domain to this IP address, anyone trying to visit their web site on port 80 will see a standard offline message or be redirected to a URL configured via the web site. The offline IP address is



This is an OPTIONAL parameter to include the name of your update clinet. Please keep this under 10 characters, and all in one word if possible. This can be used for tracking purposes, and general statistics. 'Unknown' will be placed in the database if no client is specified. If you use the User-Agent HTTP header, please use the same value in this field.


returned messages

  Messages Description


No hostname to update was supplied.

This message is returned when no ID is specified.


No password was supplied.

Returned when no PW is given.


The hostname you supplied is not valid.

Returned when ID is not a valid hostname or domain on the system.


The password you supplied is not valid.

Returned when the value of PW does not match the password defined for the value in the ID tag.


This account has not yet been activated.

Returned when the account has not been activated for usage.


Administration has disabled this account.

Returned when the disabled bit is active for the specified ID, meaning that the hostname
or domain name has been disabled for some reason.


Illegal character in IP.

Returned when a non-numeric or period character is detected in the IP field when the user
has their account setup for A name resolution. Having a non-standard IP when set to A
resolution causes the service to not update the IP database. Also returned when a number
in the IP address is higher than 255.


Host name now points to IP

Returned when an update is accepted (IP changed). For example

Host now points to 888.129.139.179


Valid Names and Labels

Although things have moved on there are still implementation that use the old RFC 952 and RFC 1123 (1999!) specification that define what a valid name (Label) is. Note a domain in this context includes any sub-domains eg = (label).(label).net

Labels can contain letters, numbers, and hyphens, and may not start with a hyphen. Periods are used to separate labels in a domain name. The total length must range between 3 and 63 characters (excluding the extension).

A to Z ; upper case characters
a to z ; lower case characters
0 to 9 ; numeric characters 0 to 9
-      ; dash
  • A label can start or end with a letter or a number
  • A label MUST NOT start or end with a '-' (dash)
  • A label MUST NOT consist of all numeric values
  • A label can be up to 63 characters

The above is a safe bet, however specification RFC 2181 provides expanded capabilities and essentially says anything goes,

If you want to validate to RFC 2181 be prepared for some real pain!


Example client host validation

The follow examples shows code you could use for client verification. Expert regexer’s probably can do this in a single line. I like to split into small more manageable chunks.


$host = ""; // Change this for testing

// === Check for vailid host =================================================
if(preg_match("/^[A-Za-z0-9\-.]+$/",$host)){ // Allowed characters
  // Invalid period either end not allowed set flag

  // Looks ok now split at periods to give array each element contains a Label  
    $host_array = explode(".",$host); // into an array

      // Scan each element for "-" either end of element not allowed set flag  
      foreach($host_array as $el){ 
         $failed=true;  // not allowed set flag    
      }// end foreach

    // Last element is tld allowed characters lower cae alpha 
  }// end ese
}// end if allowed characters

 print "<br />==== Errors In Host =======<br />";
// === END Check for vailid host =============================================
 print "<br />=== Host OK =====<br />";


Simulation Script

Our simulation script as a minimum should validate all mandatory values and any additional items you consider important its a personal choice. Remember its the Curl script we want to check.

That said because DtDNS has provided an excellent and easy to understand specification its worth matching responses as outlined. The following is my attempt at a working simulation script:

Create a new text file in folder C:\curl_2\UniServer\www named autodns.php with the following content:


$hostname         = "";  // Host name you created at DtDNS
$password         = "me123";          // Account password you set

$information      = true;  // true = display information false = for real tests set to false
$activated        = true;  // Account active = true, Account not active = false
$account_disabled = false; // Admin disabled = true, not disabled = false

 print "<p><b>Information</b></p>";
 if(isset($_GET['id']))      $id     = $_GET['id'];
 if(isset($_GET['pw']))      $pw     = $_GET['pw'];
 if(isset($_GET['ip']))      $ip     = $_GET['ip'];

 // Check if a client was supplied
  $client = $_GET['client'];
  $client = "Unknown";

 print "<pre>Host     (id)    = $id<br />";
 print "Password (pw)    = $pw<br />";
 print "Ip       (ip)    = $ip<br />";
 print "Client   (client)= $client </pre>";
}//End Information

// === Check for id host name
 $id = $_GET['id'];
 print "No hostname to update was supplied.";

// ===  Check for pw host name
 $pw = $_GET['pw'];
 print "No password was supplied.";

// === Check id (hostname) matches
 print "The hostname you supplied is not valid.";

// === Check pwd matches
 print "The password you supplied is not valid.";

// === Check if account activated
 print "This account has not yet been activated.";

// === Check if Admin disabled account
 print "Administration has disabled this account.";

// === Check if a IP was supplied
 $ip = $_GET['ip'];

 // === Validate
   print "Illegal character in IP";
   //Gets the IP address
  $ip = getenv("REMOTE_ADDR") ;

 print "Host $id now points to $ip.";



Start server curl_2 copy and paste the following into your browser address bar:


Browser displays:


Host     (id)    =
Password (pw)    = me123
Ip       (ip)    =
Client   (client)= UniServerV1

Host now points to

Change the variables and generally check whats displayed.

When you have finished testing set $information = false; the simulation script hide the extra information.

Note: If you are simulaing a real DtDNS account remember to change the following:

  • $hostname = ""; // Host name you created at DtDNS
  • $password = "me123"; // Account password you set



The above simulation script is important it allows you to make mistakes while testing without incurring the wrath of a draconian dragon. I am not sure what form DtDNS’s dragon takes however I do know DynDNS implements an abuse counter once triggered time delayed logins starts.

With the above in place we can develop our Curl update script on test server curl_1 and convert to CLI, this is covered on the next page.