D15 Public version


The following version is the public version of the technical capabilities of the Registry. The reason for making one public version and one internal for ICANN is to protect parts of the technical system from intrusion. The proposed technical system has also in certain areas similarities with the existing systems of the mother company, which turns the confidentiality of some parts into a business necessity. It is of vital importance to protect the Registry from intrusion, and extensive knowledge of all parts would augment the risk for such. It has been put effort into making the public part of the system as comprehensive as possible.


The Global Name Registry (GNR) was established by Nameplanet.com for the purpose applying for and operating a personal delegated TLD. It is established as a completely separate entity to ensure that no possibility of conflict of interest could occur. As a consequence, GNR has no current ongoing operations. However, Nameplanet.com has extensive experience in areas relevant to the Registry and therefore a number of key personnel will be transferred to GNR. The following pages detail the experience that these GNR resources will be bringing from Nameplanet.com

Experience to be transferred:

·         Has successfully acquired 700,000 users after 8 months of operations, who are all using a personal domain name for a web-mail and web-page solution fully developed and operated in-house.

·         Currently operating an IBM 2.3 Terabyte ESS backend system, and a high availability active-active front-end system

·         Real-time encrypts private information.

·         The current system is handling more than 10,000 registrations day, with thousands of simultaneous users.

·         Extensive experience with backup

·         Extensive experience with running DNS, since the company is handling the full DNS service for the personal domains of all 700,000 users.

·         Has entered into strategic technical partnership with IBM and minimized variations in equipment used.

·         Has ensured 99.8% uptime since service was launched February 1.


DNS experience

Nameplanet.com has as its core proposition to end users the free usage of a domain name that corresponds to the user’s personal name for email and web page purposes. To be able to offer this service, Nameplanet.com has acquired extensive statistics about the most common last names in the world, for each of the countries in which the service is launched. A large number of domain names identical to the most common last names have then been purchased on different TLDs to be shared among different users, each using it for free. The result is that domain names are being shared among people with equal interests in it, i.e. Ken Williams and Sven Williams can both use the domain name williams.TLD for their personal purpose, instead of it being held by one user only.

To keep track of all domain names covering the last names of roughly 210 million people in the US only, as well as the DNS functionality of hundreds of thousands of domain names, Nameplanet.com has developed a custom database for administering the DNS servers, renewals, MX records etc. on the massive amount of domain names in use by currently more than 700,000 users, growing at 5% a week. This database makes Nameplanet.com confident that all possible actions are taken to ensure a stable operation of the domain names that the end users rely on. Large efforts have been deployed to ensure that all DNS updates, maintenance and transfers of data to DNS servers are done securely and without loss of functionality of the vital DNS servers.

Nameplanet.com has through its operations in the DNS space accumulated knowledge and contacts within the arena, both through commercial relationships with several Registrars, ccTLD managers, DNSO and ICANN. Participation at the ICANN Board meetings have given insight into the policies and operations of the DNS community and valuable experience.

Internet experience and database operations

The users of Nameplanet.com register online and immediately get assigned an address of the type firstname@lastname.com and a web page www.firstname.lastname.com, or other TLDs where the .com-version has not been available. Nameplanet.com has developed fully in-house a custom object-oriented database for the webmail users, and has ensured 99.8% uptime since launch in Februray 2000. This custom database currently serves thousands of simultaneous users, and has done tens of thousands of email account and web page account registrations per day. The high-performance web-servers and storage solutions scale to millions of users, and are handling increasing data volumes.

Data protection and Intellectual Property rights

By operating a web mail solution for 700,000 people, Nameplanet.com has taken very strong precautions in order to deal properly with the user private data, both technically and legally, in terms of storage, encryption, backup, protection and Intellectual Property rights in various jurisdictions.

Nameplanet.com has strong expertise of Intellectual Property rights with regards to domain names, as it has thoroughly investigated the risk of the business of sharing a domain name between people with the same last name. This expertise also applies to the UDRP as well as national Intellectual Property law of the US and major European countries.

D15.2.2 Registry-Registrar Protocol and interface

A new, Stateless Registry-Registrar Protocol

GNR is proposing a new protocol for the communication between the Registry and the multiple Registrars. This new protocol, called the Stateless Registry-Registrar Protocol, or SRRP, is designed to overcome most of the known problems with the existing RRP in use today, as defined in RFC 2832. The SRRP is suggested as a supplement to the RRP and the Registry will encourage the Registrars to use this protocol for communications with the Registry, although a supplementary interface will exist for the Registrars to use their existing RRP implementations.

In order to promote usage of SRRP, the Registry will provide the Registrars with APIs to the protocol to make it easy and fast to implement. Given its stateless nature, it is easier to implement for new Registrars than the RRP, and have advantages also in other areas:

·         Transfer commands may be approved by the Registrant through the domain password, and domain transactions may be performed without approval from the Registrar, from which the domain is being transferred .

·         The protocol uses coordinated universal time (UTC) for all operations.

·         The client may discover system defined default values and limits

·         The protocol provides the client with complete idem potency, and repeated commands will not alter data additionally.

·         It puts less strain on the server by using a stateless protocol model and moving some of the complexity to the clients.

·         The protocol is designed to minimize the number of database transactions in order to keep the performance high.

GNR will in the case of delegation submit the protocol for review as a RFC (attached).


Abstract of the protocol

The purpose of SRRP is to provide a stateless service for communications between the Registrar and the Registry. The design goal of the protocol is to provide a consistent service for a very large number of clients by not maintaining client state information on the server, and to reduce the policy enforcements done by the protocol to a minimum.

The protocol describes the communications between a Registrar, normally acting on behalf of a Registrant, and the Registry. The Registrar may perform operations such as creating domains, creating logical entities of name servers, assigning name servers to a domain, transferring a domain and querying the server for information about name server entities, domains or the server itself.

The SRR protocol is intended to fix several shortcomings of the RRP defined by NSI in RFC2832 by removing some of the less frequently used features and using a stateless protocol model. The goals of the protocol are:

·         Provide only the strictly required functionality

·         Provide a completely stateless service

·         Provide service to a very large number of clients

·         Be implementation and performance friendly



Terminology used


·         The “request message” or “client request” is the message sent from the client to the server, and consists of a one line “request header” and a multi line “request body”.

·         The “response message” or “server response” is always the response to a request message, and is sent from the server to the client. It consists of a one line “response header” and possibly a “response body”.

·         “LWS”, linear white space, is any combination of ASCII space (SP) and ASCII tabulator (TAB) characters.

·         “CRLF” is one ASCII carriage return (CR) character followed by one ASCII line feed (LF) character.

·         An “attribute/value pair” consists of a short textual string, termed “attribute”, an ASCII ‘=’ character, and another string, termed “value”.  The attribute/value pair is terminated by a CRLF sequence, and thus a line may only contain one attribute/value pair.

·         The “client” is the Registrar’s client software, and likewise the “server” is the Registry’s server software.

·         An “object” is a set of attribute/value pairs that the server operates on. Currently there are two kinds of objects: domain objects and cluster objects.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [1].

Protocol model

The protocol is a simple one way client-server protocol using a textual format for easier debugging. A transaction is always initiated by the client, and the server must answer every valid request message with a response message containing a response code indicating the outcome of the client request. A well behaved client SHOULD wait for a response from the server before it issues a new request.

The messages should contain only printable ISO-8859-1 characters, ie.  characters in the range 31-126 and 160-255, inclusive. Support for other characters sets or binary data are not supported in the current version of SRRP, but may be added later by using a character encoding.

The Registrar is identified to the Registry by an attribute/value pair in the request body, and authenticated by a similar attribute/value pair.  As the protocol does not itself provide any other security measures, the client MUST connect to the server using a secure, reliable communication method such as SSL [2] or an encrypted tunnel.


Protocol objects


The domain objects are a logical grouping of attribute/value pairs that are manipulated using SRRP.

Domain objects


The domain object is a collection of information defining a registered domain in the system. The domain object should contain the following attributes:

·         Exactly one “registrar-id” attribute identifying the owner of the object.

·         Exactly one “domain-name” attribute containing the name of the domain.

·         Exactly one “expiry-date” attribute containing the expiry date for the registration. If the client does not specify a date, a system default should be used.

·         Exactly one “status” attribute defining the current status of the object. 

·         This should be set to a system default if not specified by the client.

·         Exactly one “expiry-date” attribute containing the expiry date for the registration. If the client does not specify a date, a system default should be used.

·         Exactly one “cluster-id” attribute identifying a cluster object for this domain object.


Cluster objects


The purpose of the cluster object is for the Registrar to create a single object to which the Registrar can attach domain names, thereby facilitating the handling of large volumes of domain names using the Registrar’s DNS servers.

The cluster object is a collection of name server information. Both the name and the address of the name server are stored for every name server in the cluster. The name servers are stored in attributes starting with “nsi-“ where “i” is any positive integer starting with one (1), possibly limited by the server. For instance, the first name server in a cluster object will have its IP address in the attribute “ns1-address” and its name in the attribute “ns1-name”. This pair is termed the “name server entry”.

The client should store the name servers in increments of one, as the server MAY choose to stop looking for name servers when it finds an empty name server entry, thereby assuming that the name server cluster is full.

The cluster object consists of any number of name server entries starting with “nsi-“ where i is a positive integer starting with one (1) and increasing with increments of one (1) for every name server entry.

Request message format


The issued request message consists of a header line containing the command to be performed, a command argument and the version number of the protocol. These fields are separated by one or more LWS characters, and the header line is terminated by one CRLF character sequence.

Following the header line, the client may add one or more lines of attribute/value pairs, the request body. While the protocol does not require the client to issue any attribute/value pairs, the authentication credentials are specified using attribute/value pairs in the request body, and these are required by every command currently specified. The order of the attribute/value pairs in the request body is arbitrary.

The request message is terminated by the ASCII end of file (EOF) character, and the server MUST disconnect from the client whenever it encounters EOF.

Example request message:



registrar-auth= pass-phrase





Please note the usage of ‘=’ and space characters in the registrar-auth attribute value. This is valid because there must be exactly one attribute/value pair on every line, and everything from the first ‘=’ up to the CRLF is considered part of the attribute value.


Response format


For every valid request message received from a client, the server MUST issue a response message starting with a one line header containing a valid response code and a short description of the response code, separated by one or more LWS characters and terminated by a CRLF sequence.

If the client request was completed successfully and the server needs to send additional information in the response message, it must send this information in one or more lines of attribute/value pairs contained in the response body. The response body is terminated by an EOF character, also marking the end of the response message. If the command failed, the response code is a 3XX (Temporary failure) or 4XX (Permanent failure), the server MAY add one or more “text” attributes in the response body further describing the error condition.

The response body for a successful command MUST contain only attributes defined for that particular command. The order of the attributes in the response body is arbitrary with one exception: the order of the special “text” attribute is important as these are used for human readable data.  The server MUST send the “text” attributes in the order they are stored or retrieved, and likewise the client MUST read them in the order received.

Example response message for a QUERY CLUSTER command:

200 Command completed successfully








The response code of 200 indicates that the command was successfully completed, and the response body contains the data returned from the command, which is a set of attribute/value pairs.

Example response message for a QUERY DOMAIN command:

200 Command completed successfully







text=Last-change: CREATE DOMAIN

text=Changed-date:2001-02-13 10:15:12 UTC

text=Changed-by: registrar 123456789


This is a more complex response, containing both normal attributes and ordered “text” attributes. If the domain did not exist, the response would be a 401 Domain not registered, possibly with one or more “text” attributes giving a human readable explanation of the error.


Client requirements


The client MUST NOT make any assumptions about the length of the value pairs. The ordering of the attributes is irrelevant except for the “text” attribute where the client MUST keep the order.


Server requirements


The server SHOULD issue a response message to every well formed client request message. A client request message is considered well formed when it contains an initial header line consisting of three fields separated by one or more LWS characters, and the last value is recognized as an SRRP protocol version number. If the client request message is not well formed, the server MUST drop the connection immediately.

The server MUST answer the client request with a response message using the same version of SRRP as the client request message. If the server is unable to answer the request using the same protocol version as the client, it must issue a 413 Unsupported protocol version message.


SRRP commands


This section contains the commands defined for use in client request messages and their expected response. All of these messages MUST contain a “registrar-id” attribute identifying the Registrar issuing the command, and a “registrar-auth” authenticating the Registrar. Clients may only view and/or change their own objects, and attempts to operate objects belonging to other Registrars should result in a 411 Access denied error message.

Note that the ordering of the attribute/value pairs is not significant except for the “text” attributes.



The create commands are used for adding an object to the Registry. In the current release of SRRP, the “domain” and “cluster” object types are supported, containing a domain registration and a series of name server registrations, respectively.



The CREATE DOMAIN command attempts to register the domain name contained in the “domain-name” attribute in the request body.

The request body MAY also contain any of the following attributes:

·         Exactly one “expiry-date” attribute giving the requested expiration date of the registration..

·         Exactly one “cluster-id” attribute pointing to a cluster object containing the name servers for this domain..

·         Exactly one “status” attribute giving the current status of the domain.

·         Exactly one "domain-auth" attribute containing a Registrar assigned  password for this domain.

·         Zero or more (possibly server limited) name server entries each consisting of the attributes “nsi-address” and “nsi-name” where “i” is a positive integer.


If the user specifies any name server entries, the server must attempt to create a cluster object for these. If successful, it MUST return the following attribute/value pairs:

·         Exactly one “cluster-id” attribute containing the cluster ID of the newly created cluster object. The client must store this value as it is the only way of keeping track of the cluster object.

·         Exactly one “expiry-date” attribute containing the expire date for the domain.

·         Exactly one “status” attribute containing the status of the domain.


Note that the server may limit the minimum and/or maximum number of nameservers the user is allowed to specify. The server should notify the client of any limitations on the number of name servers in the STATUS DEFAULTS response body.

If the client specifies both a “cluster-id” attribute and any number of name server entries, the server SHOULD ignore the name server entries and use the cluster ID.

If the cluster ID does not exist in the system, the response message should be a 402 Cluster not registered. If the expiry date is invalid, the response message should be a 405 Invalid expire date. If the “status” attribute contains an unknown status value, the response message should be a 404 Invalid attribute value. If the client specified too few or too many name servers, the server should respond with a 406 Invalid number of name servers error message. If the client attempts to register a domain which is blacklisted, the server should issue a 409 Blocked domain error message. If the client does not have the necessary credit to register a domain, the response message should be a 410 Credit failure error.




registrar-auth= pass-phrasecluster-id=987654321



In this example, the Registrar 123456789 adds the domain example.com using the default expiry date and status and a pre-defined cluster object.










Here, the Registrar specifies two name servers in the request body. If the number of name servers (two) is valid, the response might look like this:

200 Command completed successfully





The client would now own the cluster object identified by 987654321 containing the two name servers ns1.example.com and ns2.example.com and their IP addresses.



Cluster objects for name servers may be added by using the CREATE CLUSTER command. A number of name server entries each consisting of the attributes “nsi-address” and “nsi-name” where “i” is a positive integer. The minimum and/or maximum number of name server entries may be limited by the server, and the server should show these limits in the STATUS DEFAULTS response body. The server must create a cluster object for this client, and respond with a “cluster-id” attribute in the response body containing the ID of the newly created cluster object. The client must store the cluster ID as this is the only way of keeping track of the cluster object.

If the client specified too few or too many name servers, the server should respond with a 406 Invalid number of name servers error message.Example:











A typical response message would look like this:

200 Command completed successfully



The cluster identified by the cluster ID 987654321 is now assigned to the Registrar identified by the Registrar ID 123456789, and contains three name servers.



The SET command is functionally equivalent to the CREATE command, except for that it will overwrite any previous data contained in the attribute.



If not specified, the expiry date is set to a system default time, ie.  a year after the registration was performed. However, the Registrar may change the expiry date himself by issuing an SET EXPIRE command with the domain in the “domain-name” attribute and the requested expiry date in the “expiry-date” attribute. The previous expiry date of the domain object will be overwritten by the new one.

The value of the “expiry-date” attribute should be the year month and day of the requested registration expiry date, specified with a four digit year number, a two digit month number and a two digit day number, separated with ASCII ‘-‘ characters. The client MUST specify the expiry date in UTC (Universal Time Coordinated).

The system may have an upper limit of the length of a registration, and if the Registrar attempts to set an expiry date past this boundary, the server must respond with a 405 Invalid expire date error message.






domain-name= example.com


This will set the expire date of the domain example.com to June 2007.




The SET CLUSTER combination will specify a cluster of nameservers, identified by the “cluster-id” attribute in the request body, for the domain object specified by the “domain-name” attribute.

If the domain and/or cluster object is unknown, the server must respond with a 401 Domain not registered error message.  If the cluster object is unknown, the server must respond with a 402 Cluster not registered error message.








Here the client will change the “cluster-id” attribute for the domain example.com to 987654321, if both the domain and cluster objects exist.



The client may change the status of a domain object by using the SET STATUS command. The following values are valid:

·         “inactive” signaling that the domain is not active.

·         “active” signaling that the domain is active.






domain-name= example.com



In this example, the client deactivates the domain “example.com” by setting its status to “inactive”.



The SET NAMESERVER command is used for changing all of the name server entries in a cluster object. The request body should contain exactly one “cluster-id” object identifying the cluster object and a number of name server entries defining the new name servers for the cluster object.  The name server entries consist of the attributes “nsi-address” and “nsi-name” where “i” is a positive integer. The minimum and/or maximum number of name server entries may be limited by the server, and the server should show these limits in the STATUS DEFAULTS response body.

The new name server entries should completely replace all previous name server entries.

If the cluster ID does not exist in the system, the response message should be a 402 Cluster not registered. If the client specified too few or too many name servers, the server should respond with a 406 Invalid number of name servers error message.











This will completely remove any name server entries from the cluster object in question, and replace them with the two name servers above.



The client may change the domain password of a domain object using the SET PASSWORD command. The new domain password should be given in the "domain-auth" attribute.

The purpose of the domain password is to authorize domain transfers between registrars. The transfer request message should contain the domain password for the requested domain, and the server should only perform the transfer when the password is correct. Example:










The DELETE command is used for deleting objects.



The DELETE DOMAIN command will attempt to delete a domain object. The request body must contain exactly one “domain-name” attribute specifying the domain to be deleted.

If the domain object cannot be found, the server must respond with a 401 Domain not registered error message.







This will delete the domain example.name provided that the Registrar attempting the operation has the proper authorization.



The DELETE CLUSTER command will attempt to delete a cluster object. The request body must contain exactly one “cluster-id” attribute identifying the cluster object to be deleted.

If the cluster object cannot be found, the server must respond with a 402 Cluster not registered error message. If a client attempts to delete a cluster object, which is in use by one or more active domain objects, the server should return a 408 Removal not permitted error message. The client will have to assign another cluster ID to the domain objects using this cluster object, or set their status to “inactive” before attempting the operation again.

Note that all the name server attribute groups contained within the cluster object will be deleted too.







This will delete the cluster object identified by the “cluster-id” attribute.



The QUERY commands are used for fetching all the available information about an object.



The QUERY DOMAIN command will attempt to retrieve some or all of the information for a domain. The request message must contain exactly one “domain-name” attribute giving the name of the domain object to query, and zero or more “get-specific” attributes naming the specific attributes to fetch.

If no “get-specific” attributes are present in the query, the server must return all available information for the domain object. If one or more “get-specific” attributes are specified, the server must return the values of all the attributes named by the “get-specific” attributes or an error message.

If the server is unable to return the required information, it must return a 301 Attribute temporarily unavailable. If one or more of the “get-specific” attributes contains an unknown attribute, the server must return a 403 Invalid attribute. If the client attempts to query a domain which is not registered, the server must return a 401 Domainnot registered.

Normally Registrars should only be able to query their own domains, and attempts to query other Registrars’ domains should result in a 411Access denied error..

If there are no “get-specific” attributes in the query, the server MUST return at least the following information:

n         The current Registrar id in the “registrar-id” attribute.

n         The domain name in the “domain-name” attribute.

n         The expiry date in the “expiry-date” attribute.

n         The current status of the domain in the “status” attribute.


If the server is unable to retrieve this information, it MUST respond to the client with a 301 Attribute temporarily unavailable, indicating the failure to retrieve the required information about the domain.

The response to a query without any “get-specific” attributes SHOULD also contain the following information:

n         The creation date of the domain in the “created-date” attribute.

n         The cluster ID of the cluster object for this domain in the “cluster-id” attribute, if set.

n         Any other relevant information about the domain contained in ordered “text” attributes.


Example query retrieving only the “expiry-date” attribute:




domain-name= example.com



This command should return the “expiry-date” attribute for the domain example.com, and a successful response might look like this:

200 Command completed successfully



Example query retrieving all the available information:




domain-name= example.com


This command will try to retrieve all the information for the domain example.com. If it is successful, the output might look like this:

200 Command completed successfully

domain-name= example.com






text=Change: SET STATUS (to inactive)

text=Changed-date:2001-04-03 12:46:01 UTC

text=Changed-by: registrar 123456789

text=Change: TRANSFER DOMAIN (from registrar 234567890)

text=Changed-date:2001-02-13 10:15:12 UTC

text=Changed-by: registrar 123456789



The QUERY CLUSTER command is used for retrieving information about the name server entries of a cluster object. The request must contain exactly one “cluster-id” attribute identifying the cluster object.

The server must return all the name server entries in the cluster.

Example query:






This request indicates that the client wants a list of the name servers in cluster object. The output could look like this:

200 Command completed successfully









The TRANSFER command is used for requesting and approving the transfer of a domain from one Registrar to another.


This command is used for requesting a transfer of a domain belonging to another Registrar to the requesting Registrar. The request body must contain the requested domain name in the attribute “domain-name” and the domain password in the "domain-auth" attribute.

If the domain is not registered, the server should issue a 401 Domain not registered. If the domain password did not properly authorize the transfer, the server should issue a 412 Authorization failed error message.

Note that information regarding domain transfers, such as domain passwords and notification about lost and obtained domains, is not handled by SRRP. Out of band communications means should be used for this purpose.








Here, the domain example.com is requested transferred to the requesting Registrar. If the domain password is correct, the domain server should immediately transfer the ownership of the domain to the requesting Registrar.



The STATUS commands give information about the implementation and configuration of the server.



The STATUS DEFAULTS command is used for retrieving various default values, such as default status and default registration period, from the server.

The response body MUST contain the following attributes:

·         The default status for new registrations in the “default-status” attribute

·         The default registration period, in months, for new registrations in the “default-period” attribute.

·         The maximum user definable registration period, zero (0) if unset or unlimited, in the “maximum-period” attribute.

·         The default domain transfer response in the “transfer-default” attribute. Valid values are the ASCII strings “yes”, “no” or “unset”.

·         The transfer timeout period in the “transfer-timeout” atribute. If this is set to zero (0), the feature is disabled and both this attribute and “transfer-default” SHOULD be ignored.

·         The minimum number of name servers allowed in the “minimum-ns” attribute, zero (0) if unspecified.

·         The maximum number of name servers allowed in the “maximum-ns” attribute, zero (0) if unspecified.


The server MAY add additional “text” attributes for returning server specific defaults. The client MUST NOT rely on these “text” attributes.

Example command:





A typical response message would look like this:

200 Command completed successfully










Clients may use a STATUS command with the SERVER argument to fetch information about the server implementation. The information is returned in one or more “text” attributes. If the server does not wish to return any information, it can do so by returning a 200 Command completed successfully and leave the response body empty.

The server MAY return information on a STATUS SERVER command, but the client MUST NOT rely on this information.






The response message may look like this:

200 Command completed successfully

text=Standard SRRP server version 1.0.4p3

text=Compiled 2001-01-29 03:58:32 GMT+1


Response codes


Success codes (2xx)


There is only one success code, and it indicates unconditional success.

200 Command completed successfully


This response code indicates unconditional success when executing the requested command. It is the only success code.

Temporary error codes (3xx)


Temporary error codes indicate that the requested command could not be executed due to a temporary failure. The client MAY retry the command later.

300 Internal server error

The server suffered from a fatal internal error, and the client is advised to notify the server administrator and retry the operation later. The server SHOULD present contact information in the error message, log the error and notify the server administrator.

301 Attribute temporarily unavailable

This error code indicates that the server was unable to return a mandatory attribute due to a temporary failure.

Permanent error codes (4xx)

Permanent error codes indicate that the requested command could not be executed due to a permanent failure. The client SHOULD NOT retry the command.

400 Domain already registered

This error code signals that the client has attempted to register an object that is already registered.


401 Domain not registered

This indicates that the client attempted to operate on an domain which is not registered.


402 Cluster not registered

This indicates that the client attempted to operate on an cluster which is not registered.


403 Invalid attribute

The request body contained one or more invalid attributes, indicating a client error or protocol mismatch.


404 Invalid attribute value

The request body contained one or more invalid attribute values. This could be a character string where the server expected a number, or an incomplete data string.


405 Invalid expire date

The client specified an expiry date which was either in the past or too far in the future.


406 Invalid number of name servers

The client specified either too few or too many name servers.


407 Mandatory attribute missing

This indicates that a mandatory attribute was missing.


408 Removal not permitted

The client attempted to remove an entity which is required, for instance a cluster object which is in use by one or more domain objects.


409 Blocked domain

The domain which the client attempted to register was blacklisted by the server.


410 Credit failure

The client attempted to execute a command for which there was not enough credit.


411 Access denied

The client attempted an unauthorized operation. The server should log such errors.


412 Auhorization failed

The authorization credentials specified by the client did not match, or the registrar ID was unknown.


413 Unsupported protocol version

The client specified an unsupported  protocol, either too new or old.



ABNF Definition of SRRP


This is a formal definition of SRRP using standard ABNF as defined in [3].

Lexical definitions


SP = %x20         ; ASCII space

HT = %x09         ; ASCII horizontal tab

DOT = %x2e        ; ASCII “.”

EOF = %x00        ; ASCII end of file

DASH = %x2d       ; ASCII “-“

SL = %x2f         ; ASCII “/“

EQ = %x3d         ; ASCII “=”

CR = %x0D         ; ASCII carriage return

LF = %x0A         ; ASCII linefeed

LWS = SP / HT     ; linear white space

CRLF = CR LF      ; carriage return line feed sequence

UALPHA = %x41-5a     ; ASCII A-Z

LALPHA = %x61-7a     ; ASCII a-z


DIGIT = %x30-39               ; ASCII 0-9

PCHAR = ALPHA / DIGIT / DASH        ; protocol characters

UCHAR = %x20-%ff                    ; user characters


Basic grammatical definitions

ip-address = 1*3DIGIT DOT 1*3DIGIT DOT 1*3DIGIT DOT 1*3DIGIT

protocol = “SRRP” SL version

version = main-version DOT sub-version

main-version = 1*DIGIT

sub-version = 1*DIGIT

date = year DASH month DASH day

year = 4DIGIT

month = 2DIGIT

day = 2DIGIT


response-header = success-header / tempfail-header / permfail-header

success-header = success-code LWS response-text

tempfail-header = temporary-fail-code LWS response-text

permfail-header = permanent-fail-code LWS response-text

success-code = “2” 2DIGIT

temporary-fail-code = “3” 2DIGIT

permanent-fail-code = “4” 2DIGIT

response-text = *PCHAR


standard-response-message = response-header [CRLF response-body]

response-body = 1*text-pair

error-response-message = (tempfail-header / permfail-header)

[CRLF response-body]


Attribute/value set definitions


attribute-value-pair = attribute EQ value CRLF

attribute = 1*PCHAR

value = *UCHAR


text-pair = text-attribute EQ text-value CRLF

text-attribute = “text”

text-value = *UCHAR


cluster-id-pair = cluster-id-attribute EQ cluster-id-value CRLF

cluster-id-attribute = “cluster-id”

cluster-id-value = 1*PCHAR


status-pair = status-attribute EQ status-value CRLF

status-attribute = “status”

status-value = “active” / “inactive”


registrar-id-pair = registrar-id-attribute EQ registrar-id-value CRLF

registrar-id-attribute = “registrar-id”

registrar-id-value = 1*PCHAR


registrar-auth-pair = registrar-auth-attribute EQ registrar-auth-value CRLF

registrar-auth-attribute = “registrar-auth”

registrar-auth-value = *UCHAR


expiry-date-pair = expiry-date-attribute EQ expiry-date-value CRLF

expiry-date-attribute = “expiry-date”

expiry-date-value = date


domain-name-pair = domain-name-attribute EQ domain-name-value CRLF

domain-name-attribute = “domain-name”

domain-name-value = 1*UCHAR


domain-auth-pair = domain-auth-attribute EQ domain-auth-value CRLF

domain-auth-attribute = "domain-auth"

domain-auth-value = *UCHAR


get-specific-pair = get-specific-attribute EQ get-specific-value CRLF

get-specific-attribute = “get-specific”

get-specific-value = 1*PCHAR


name-server-entry = ns-address-pair ns-name-pair

ns-address-pair = ns-address-attribute EQ ns-address-value CRLF

ns-address-attribute = “ns” 1*DIGIT “-address”

ns-address-value = ip-address

ns-name-pair = ns-name-attribute EQ ns-name-value CRLF

ns-name-attribute = “ns” 1*DIGIT “-name”

ns-name-value = UCHAR


registrar-auth-entry = registrar-id-pair registrar-auth-pair


Message definition

message = (create / set / delete / query / transfer / status) EOF

create = create-domain / create-cluster

set = set-expire / set-cluster / set-status / set-nameservers

delete = delete-domain / delete-cluster

query = query-domain / query-cluster

transfer = transfer-request / transfer-response

status = status-defaults / status-server


create-domain = create-domain-request / create-domain-response

create-cluster = create-cluster-request / create-cluster-response

set-expire = set-expire-request / set-expire-response

set-cluster = set-cluster-request / set-cluster-response

set-status = set-status-request / set-status-response

set-nameservers = set-nameservers-request / set-nameservers-response

set-password = set-password-request / set-password-response

delete-domain = delete-domain-request / delete-domain-response

delete-cluster = delete-cluster-request / delete-cluster-response

query-domain = query-domain-request / query-domain-response

query-cluster = query-cluster-request / query-cluster-response

transfer-domain = transfer-domain-request / transfer-domain-response

status-defaults = status-defaults-request / status-default-response

status-server = status-server-request / status-server-response



create-domain-request = create-domain-request-header CRLF


create-domain-request-header = “CREATE” LWS “DOMAIN” LWS protocol

create-domain-request-body = registrar-auth-entry domain-name-pair

domain-auth-pair [expiry-date-pair] [status-pair] (cluster-id-pair /




create-domain-response = create-domain-success / error-response-message

create-domain-success = success-header CRLF cluster-id-pair status-pair




create-cluster-request = create-cluster-request-header CRLF


create-cluster-request-header = “CREATE LWS “CLUSTER” LWS protocol

create-cluster-request-body = registrar-auth-entry *name-server-entry



create-cluster-response = create-cluster-success / error-response-message

create-cluster-success = success-header CRLF cluster-id-pair



set-expire-request = set-expire-request-header CRLF set-expire-request-body

set-expire-request-header = “SET” LWS “EXPIRE” LWS protocol

set-expire-request-body = registrar-auth-entry expiry-date-pair




set-expire-response = standard-response



set-cluster-request = set-cluster-request-header CRLF set-cluster-request-body

set-cluster-request-header = “SET” LWS “CLUSTER” LWS protocol

set-cluster-request-body = registrar-auth-entry cluster-id-pair



set-expire-response = standard-response



set-status-request = set-status-request-header CRLF set-status-request-body

set-status-request-header = “SET” LWS “STATUS” LWS protocol

set-status-request-body = registrar-auth-entry domain-name-pair status-pair


set-expire-response = standard-response



set-nameservers-request = set-nameservers-request-header CRLF


set-nameservers-request-header = “SET” LWS “NAMESERVERS” LWS protocol

set-nameservers-request-body = registrar-auth-entry cluster-id-pair




set-expire-response = standard-response



set-password-request = set-password-request-header CRLF


set-password-request-header = "SET" LWS "PASSWORD" LWS protocol

set-password-request-body = registrar-auth-entry domain-name-pair




set-password-response = standard-response



delete-domain-request = delete-domain-request-header CRLF


delete-domain-request-header = “DELETE” LWS “DOMAIN” LWS protocol

delete-domain-request-body = registrar-auth-entry domain-name-pair



delete-domain-response = standard-response



delete-cluster-request = delete-cluster-request-header CRLF


delete-cluster-request-header = “DELETE” LWS “CLUSTER” LWS protocol

delete-cluster-request-body = registrar-auth-entry cluster-id-pair



delete-domain-response = standard-response



query-domain-request = query-domain-request-header CRLF


query-domain-request-header = “QUERY” LWS “DOMAIN” LWS protocol

query-domain-request-body = registrar-auth-entry domain-name-pair




query-domain-response = full-domain-response / specific-domain-response /


full-domain-response = success-header CRLF *attribute-value-pair

specific-response = success-header CRLF attribute-value-pair



query-cluster-request = query-cluster-request-header CRLF


query-cluster-request-header = “QUERY” LWS “CLUSTER” LWS protocol

query-cluster-request-body = registrar-auth-entry cluster-id-pair



query-cluster-response = standard-response


; TRANSFER DOMAIN REQUESTtransfer-domain-request = transfer-domain-request-header CRLF


transfer-domain-request-header = “TRANSFER” LWS “REQUEST” LWS protocol

transfer-domain-request-body = registrar-auth-entry domain-name-pair



transfer-domain-response = standard-response



status-defaults-request = status-defaults-request-header CRLF


status-defaults-request-header = “STATUS” LWS “DEFAULTS” LWS protocol

status-defaults-request-body = registrar-auth-entry



status-defaults-response = status-defaults-response-message /


status-defaults-response-message = success-header CRLF


status-defaults-response-body = default-status-pair / default-period-pair /

maximum-period / transfer-default / text-pair /

transfer-timeout / minimum-ns / maximum-ns

default-status-pair = default-status-attribute EQ default-status-value CRLF

default-status-attribute = “default-status”

default-status-value = “active” / “inactive”

default-period-pair = default-period-attribute EQ default-period-value CRLF

default-period-attribute = “default-period”

default-period-value = 1*DIGIT

maximum-period-pair = maximum-period-attribute EQ maximum-period-pair CRLF

maximum-period-attribute = “maximum-period”

maximum-period-value = 1*DIGIT

transfer-default-pair = transfer-default-attribute EQ transfer-default-value


transfer-default-attribute = “transfer-default”

transfer-default-value = “yes” / “no” / “unset”

minimum-ns-pair = minimum-ns-attribute EQ minimum-ns-value CRLF

minimum-ns-attribute = “minimum-ns”

minimum-ns-value = 1*DIGIT

maximum-ns-pair = maximum-ns-attribute EQ maximum-ns-value CRLF

maximum-ns-attribute = “minimum-ns”

maximum-ns-value = 1*DIGIT



status-server-request = status-server-request-header CRLF


status-server-request-header = “STATUS” LWS “SERVER” LWS protocol

status-server-request-body = registrar-auth-entry



status-server-response = status-server-response-message /


status-server-response-message = success-header CRLF


status-server-response-body = *text-pair


RRP to SRRP mapping

As RRP is a state based protocol, i.e. requires the server to maintain state information for every connected client for as long as he is connected, it is impossible for a RRP client to talk directly to an SRRP server. The only way to allow for RRP clients to talk to SRRP servers, would be to use an RRP/SRRP gateway to maintain the state required by the RRP client, and issue SRRP messages for every RRP operation the client performs. This is, however, outside of the scope of this document.



 [1]  Bradner, S., “Key Words for Use in RFCs to Indicate Requirement

Levels”, BCP 14, RFC 2119, March 1997.

[2]  A. Frier, P. Karlton, and P. Kocher, “The SSL 3.0 Protocol”,

Netscape Communications Corp., November 18, 1996.

[3]  Crocker, D. (Editor) and P. Overell, “Augmented BNF for Syntax

Specifications: ABNF”, RFC 2234, November 1997.



Error handling

In the case where the Registry receives an SRRP command from a Registrar that writes something to the database, there is always the possibility that an error will occur so that the Registrar client software never receives the returned success message. If this is the case, it is up to the Registrar client software to detect that this return message is never received, and then to act upon this, either by attempting to register the domain again, or by querying the Registry database to see if the correct information was entered. The Registry will not try to intercept or correct such errors.


Mapping from SRRP to the RRP as defined in RFC 2832

RRP/SRRP mapping


RRP and SRRP have a different approach to the same problem, and as RRP clients are already widespread there may be an application for an RRP-to-SRRP gateway. This is, however, a very tricky issue as there is no direct mapping between RRP and SRRP.


Basic gateway operation

The gateway will receive one RRP-command and must report back to the client if it was successful or not. Some commands do not have an SRRP-equivalent, and the gateway must choose between reporting back an error or a fake success code. Normally, the first alternative is preferred.

In other cases, the commands have SRRP-equivalents which function in a different manner. In this case the gateway will have to perform a translation between the RRP-commands and the SRRP-commands, if necessary by maintaining state information itself.

There are three basic problems that have to be overcome:

·         Some operations, which require several RRP-commands, must be done in a single SRRP-command.

·         SRRP groups name servers into clusters, RRP does not

·         Some RRP-commands do not have a direct equivalent in SRRP, and vice versa.



Mapping multiple RRP-commands on to one SRRP-command

This problem is simplified by the fact the RRP may send several commands in batch, and this batch may be used by the mapping function of the gateway. For instance, take this RRP-session:












The client creates two name servers identified by their DNS-name. The gateway should accept both these commands, translate them into a SRRP-message that might look like this:










This transaction would work nicely; the “registrar-id” and “registrar-auth” attributes are known by the gateway from the establishment of the session, through the “Id” and “Password” parameters in the RRP “session” command.

As the SRRP-server may impose a minimum number of name servers for a cluster object, the gateway must check this with the server through the “STATUS DEFAULTS” command, and if necessary cache the required number of RRP-commands.

In SRRP, name servers are grouped in logical entities termed clusters. As RRP has no mechanism for such a grouping, the name servers are grouped in a cluster as they are created. If the client specifies too few name servers before issuing another command, the gateway must signal an error to the client.

The gateway must maintain the relationships between the name server names (which are used as identifiers in RRP) and their assigned cluster IDs (which are used as identifiers in SRRP) internally.

This mapping is essential as every RRP-request will refer to the name server name of one or more name servers, while the SRRP-request sent by the gateway must refer to the name server’s cluster ID.


Handling name server clusters through RRP

When dealing with clusters, the SRRP server leaves most of the work to the client. No matter what a client wants to do with a name server’s cluster, it has to obtain a list of name servers through the QUERY CLUSTER command, manipulate it and write it back to the server. This moves some of the complexity from the server to the client, but increases overall flexibility and simplicity.

However, this makes things more complex for the gateway as there is no natural mapping from a RRP-command referring to a name server and the cluster of name servers used by SRRP. Thus, the gateway has to maintain a mapping between the name server names used by RRP and the clusters they belong to on the SRRP server.

For example, when deleting a name server through the RRP “del” command, an RRP client would perform a command like this:





The gateway must use its internal name server map to get the cluster ID that this name server belongs to. Then it must retrieve all the name servers in this cluster:







This will give the gateway a complete list of all the name servers in the cluster. It must now remove the name server in question from the list, and issue a SET NAMESERVERS command to update the cluster:











The name server ns1.example.com will now be deleted.


Handling unsupported RRP commands

Some RRP commands are impossible to support in SRRP, others are not necessary. An example of the first is the “transfer” command in RRP, and the “session” command of the latter.

If the command is unsupported, the gateway should simply issue a meaningful error code. If the command is not supported because it is useless for a stateless protocol, it should be accepted with a success code.

Some commands, notably the “session” command, provides necessary information, namely the user ID and password of the client. This information is needed by the gateway for further communication on behalf of the client, and it must store this for later use. The gateway may also perform a harmless command to actually verify the user ID and password, though it will be noticed on the next client command if it is a mismatch.


RRP to SRRP command mapping

RRP command          SRRP command(s)                  Comment


command  entity

add      Domain        CREATE DOMAIN

add      NameServer    CREATE CLUSTER

query    Domain                                         [3]

query    NameServer                                     [3]

del      Domain        DELETE DOMAIN

del      NameServer    SET NAMESERVERS                  [1]

describe               STATUS SERVER

mod      Domain        SET STATUS, CREATE CLUSTER

mod      NameServer    SET NAMESERVERS                  [1]

quit                                                    [2]

renew    Domain        SET EXPIRE

session                                                 [2]

status   Domain        QUERY DOMAIN

status   NameServer    QUERY CLUSTER

transfer request                                        [3]

transfer response                                       [3]



1)       As SRRP does not actually support deleting a single name server, the gateway will have to obtain the name servers contained in the cluster (for instance through the QUERY CLUSTER command), and use the SET NAMESERVERS command to set all the name servers of the cluster except the deleted one.

2)       Has no direct equivalent in SRRP, as this command is specific for state based protocols.

3)       Not supported or incompatible command


D15.2.6 Billing and collection systems

The prime principle of registrations is that the domain name registrations are prepaid, either in the form of a credit limit, or an actual prepayment of a certain size. This can be in combination with an insurance bond from the Registrar, like today’s 100,000 USD demanded from ICANN.

The billing and collection systems need not be complicated since the Registry’s billing relations are with the Registrars alone.

Billing process for domain name registration:

·         Request registration (Password acknowledged)

·         Credit check in database

·         Insert domain name

·         Acknowledge registration

When a registration is done, the Registrar’s account balance is debited with the price for one registration. Registrations continue as long as the balance is positive, or until a credit limit, if any, is exceeded.

Once a month, the Registrar is billed with the amount necessary for next month’s registrations. This amount can be chosen by the Registrar itself and can vary from month to month. Any negative balances, if allowed, will be payable on 30 days notice.

The billing system and account system will be delivered from SAGE, from the Line 50 series. The system is simple, stable, and used by more than 2 million small and medium sized enterprises around the globe. There will be an automated generation of invoices according to the Registrar’s balance, and payments from Registrars are expected by wire transfer. (documentation from SAGE is attached in Appendix.D.2.3)

The billing at the end of the month happens in the following way:

·         Accountant generates list of all registrars, with no of domain names registered this month, and total no of registrations (for verifications). For each registrar, a list of every domain registered for this billing period will be taken out.

·         The data goes in to the billing system and invoices are generated, printed out and sent by email and physical post.

The security of the system is assured by its manual nature. As long as the number of registrars is feasibly handled with automated generation of invoices and report generation from the database, the process can be handled by an accountant. Additional recruiting of accountants can scale to higher number of Registrars. The financial controller will ensure that no errors are committed as is common practice among financial controllers.

The Registrar can access the billing information and account status through the secure www interface (SSL), and request the information needed. The support team, key account manager and accountants are also available on telephone support for this purpose, should extra information be needed.


D15.2.7 Data escrow and backup


 GNR ltd will with all means possible try to ensure high data integrity and security, and we will create very strict disaster recovery plans for data stored by GNR ltd. One central component to ensure this goal is the backup solution and the policies associated with these.

Internal backup

The backup solution takes care of all internal backup needs at GNR ltd. The system is built on components delivered from IBM and on software from Tivoli. This combination of software and hardware ensures a highly secure and automated backup system. Backup policy is implemented using the Tivoli backup software and takes care of issues like scheduling tape sets for offline storage use. Backups are taken while the system is running, so operations need not be stopped or halted for backup.

External backup

Since the nature of tape backup is a point in time process, GNR ltd will implement essential systems to make sure that critical data is not lost between backup-cycles. All records needed to reconstruct the system will be considered as critical data. The way GNR ltd will ensure that this is accomplished is to make a real time offsite journal of all changes made to the database records in the Registry system. This will enable GNR ltd to reconstruct the whole Registry if a disaster affects the operation.

Data Escrow

In addition to what GNR ltd feels is a safe and flexible backup-solution, we place additional data security by depositing data to an escrow service. This will place additional data security on the organisational level in that we actually deposit data in case a conflict occurs. The escrow function will be taken care of by an escrow company, and will work by GNR ltd submitting data to the escrow service on a predefined schedule. The escrow agent will ensure that data is protected and is made available to the correct owner if a legal dispute should occur.

Data is transferred in a strongly encrypted form to the Escrow agent.


D15.2.14. Technical and other support.

The key account team will handle support for Registrars and the Support Team will be assigned complimentary responsibilities. The Key Account Managers will mainly handle pre-sales, although they will keep the primary relationship with the Registrar and will be available also for other matters. The Support Team will handle post-sales requests when a Registrar is in operation, as well as requests from general Internet users.

Every Registrar will have the possibility to contact the Registry via email or telephone to request assistance in matters like technical implementation, registration status, credit increase, billing status, etc.

The Support Team will be using the Ejournal request management system, a system for managing large amounts of requests. The main focus of the system is handling email to non-personal accounts such as support@company.com or sales@company.com, however, the system is also capable of handling phone requests, internal todo documents and other tasks that need to be tracked. The system offers several tools, both automatic and interactive, which help meeting the following overall goals:

a)      Minimizing the time spent replying or managing each request.

b)      Guaranteeing that no request is left unanswered.

c)      Offering full control over incoming and outgoing communication. This includes:

i)         Detailed information for each request, including exact timestamps, detailed logging and complete listing of messages.

ii)       Flexible reports and statistics, offering an overview of all requests being handled.

Personnel will be accessible within business hours in the location they work from, extended so as to provide for a telephone support window for all time zones. For some time zones, however, email support will be the preferred solution and can be just as efficient.

The Registrars will additionally have access to a web-based information system running on SSL, where they can access information regarding registered domains, nameservers, billing status, etc. The web interface will provide information only, and cannot be used for critical and sensitive tasks such as changing passwords, registering domains etc, for which the VPN interface will be used instead.

Key Account will initially be available in English only, given the general nature of the contracts the Registrar is entering into during the ICANN Accreditation and the initial Registry relationship. However, it is expected that as the number of Registrars grows all across the world, new languages may become available thanks to the recruitment of new Key Account Managers with different language skills for the purpose of a closer relationship to the Registrar. The general Support Team will initially be giving support in 7 languages - English, Spanish, French, German, Swedish, Norwegian and Danish - outsourced from Nameplanet.com, the mother company. It is a goal for the Global Name Registry to have good language support for the requests it is receiving.

As a general rule, most support requests from Registrants will be referred to the corresponding Registrar.

The Registry will mainly be dealing with transfer requests from Registrants, witch involves contact with the Registrars. However, the Registrants domain password can be made available from the Registry if the Registrant chooses to get it in that way.