RE: I think we need a more detailed spec

From: Colin Viebrock (colin@easydns.com)
Date: Wed Mar 22 2000 - 12:20:49 EST


With credit to Mike (who included this file in his PHP implemenation of the
client) and a few additions of my own.

This is what I'm using to get started on my implementation. Perhaps it can
be part of a more formal spec of the protocol.

__________________________________________________________________
Colin Viebrock easyDNS Technologies
                                               control your domain
                                            http://www.easyDNS.com

Encryption
==========

  - encryption is DES, CBC cipher mode

Messages
========

  - first two bytes are the length of the message in bytes (not
    including these two bytes), big-endian order (perl/php 'n' format
    for pack()/unpack())

  - the rest of the message consists of the (possibly) encrypted
    message

  - messages are sent raw binary (i.e. not hex-encoded or anything else)

Authentication
==============

  - Server sends message containing server version information

  - Client sends message containing "OpenSRS CLIENT <versionspec>"
    (<versionspec> currently == "3.0")

  - Client sends "login <option> <username>" to server.
    + The only valid option right now is "-des". Maybe this will
      change to allow other encryption formats (e.g. Blowfish, unencrypted,
      etc).

  - Server sends a challenge to the client

  - Client encrypts the challenge w/private key. This is the session key.
    + All communication after this point is encrypted with the session key.

  - Server sends a second challenge to the client (encrypted)

  - Client sends the md5 of the second challenge to the server (encrypted)
  
  - Server sends a response to the client. If the response begins
    with the character '2', we're authenticated. Otherwise, we're not.

Command Protocol
================

  - Client connects to the server

  - Client authenticates to the server (see above).

  - Client sends name-value pairs in query string format to the server
    + 'action' specifies the action to take
    + '_registrant_ip' is the IP address of the browser being used
    + other keys are presumably in the docs

  - Server sends response to the client
    + first line is of the form (<respcode> <resptext>)
    + next line is query-string'ed parameters
    + multiple values of the same key are null ("\0") separated.

  - Lather, rinse, repeat

  - Client disconnects from the server

Lookups
=======

  - Client sends "check_domain <domain> <username> <affiliate_id>\n";

  - Server sends response terminated by "\r\n.\r\n"
    + first line is <respcode> <resptext>
    + respcode = 210: domain available
    + respcode = 211: domain taken
    + respcode other: error



This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT