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
·
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.
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.
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.
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.
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).
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
·
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].
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.
The
domain objects are a logical grouping of attribute/value pairs that are
manipulated using SRRP.
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.
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.
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:
CREATE DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth= pass-phrase
domain-name=example.com
status=inactive
cluster-id=987654321
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.
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
ns1-address=192.168.4.5
ns1-name=ns1.example.com
ns2-address=192.168.4.6
ns2-name=ns2.example.com
ns3-address=10.10.56.11
ns3-name=ns1.example.net
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
domain-name=example.com
registrar-id=123456789
expiry-date=2003-02-09
created-date=2001-02-09
cluster-id=987654321
status=active
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.
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.
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.
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.
Examples:
CREATE DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth= pass-phrasecluster-id=987654321
domain-name=example.com
In this
example, the Registrar 123456789 adds the domain example.com using the default
expiry date and status and a pre-defined cluster object.
CREATE DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
domain-name=example.com
ns1-address=114.72.91.131
ns1-name=ns1.example.com
ns2-address=114.72.91.132
ns2-name=ns2.example.com
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
cluster-id=987654321
expiry-date=2004-03-12
status=active
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:
CREATE CLUSTER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
ns1-address=114.72.91.131
ns1-name=ns1.example.com
ns2-address=114.72.91.132
ns2-name=ns2.example.com
ns3-address=114.72.91.133
ns3-name=ns3.example.com
A
typical response message would look like this:
200 Command completed successfully
cluster-id=987654321
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.
Example:
SET EXPIRE SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
expiry-date=2007-06-04
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.
Example:
SET CLUSTER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
domain-name=example.com
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.
Example:
SET STATUS SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
domain-name= example.com
status=inactive
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.
Example:
SET NAMESERVERS SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
ns1-address=171.81.19.159
ns1-name=ns1.example.com
ns2-address=171.81.19.160
ns2-name=ns2.example.com
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:
SET
PASSWORD SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
domain-name=example.com
domain-auth=domain-pass-phrase
domain-pw-set=new-domain-pass-phrase
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.
Example:
DELETE DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
domain-name=example.name
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.
Example:
DELETE DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
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:
QUERY DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
domain-name= example.com
get-specific=expiry-date
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
expiry-date=2004-12-20
Example
query retrieving all the available information:
QUERY DOMAIN SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
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
registrar-id=123456789
expiry-date=2004-12-20
created-date=2001-01-20
cluster-id=987654321
status=inactive
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:
QUERY CLUSTER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
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
ns1-address=128.39.19.168
ns1-name=ns1.example.com
ns2-address=128.39.19.169
ns2-name=ns2.example.com
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.
Example:
TRANSFER DOMAIN SRRP/1.0
registrar-id=234567890
registrar-auth=pass-phrase
domain-name=example.com
domain-auth=domain-pass-phrase
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:
STATUS DEFAULTS SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
A
typical response message would look like this:
200 Command completed successfully
default-status=active
default-period=66
maximum-period=120
domain-transfer=unset
transfer-timeout=0
minimum-ns=2
maximum-ns=8
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.
Example:
STATUS SERVER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
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
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 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 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.
This is
a formal definition of SRRP using standard ABNF as defined in [3].
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
ALPHA = UALPHA / LAPLHA ; ASCII a-z / A-Z
DIGIT = %x30-39 ; ASCII 0-9
PCHAR = ALPHA / DIGIT / DASH ; protocol characters
UCHAR = %x20-%ff ; user characters
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-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 = (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 = create-domain-request-header CRLF
create-domain-request-body
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 /
*name-server-entry)
; CREATE DOMAIN RESPONSE
create-domain-response = create-domain-success / error-response-message
create-domain-success = success-header CRLF cluster-id-pair status-pair
expiry-date-pair
; CREATE CLUSTER REQUEST
create-cluster-request = create-cluster-request-header CRLF
create-cluster-request-body
create-cluster-request-header = “CREATE LWS “CLUSTER” LWS protocol
create-cluster-request-body = registrar-auth-entry *name-server-entry
; CREATE CLUSTER RESPONSE
create-cluster-response = create-cluster-success / error-response-message
create-cluster-success = success-header CRLF cluster-id-pair
; SET EXPIRE REQUEST
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
domain-name-pair
; SET EXPIRE RESPONSE
set-expire-response = standard-response
; SET CLUSTER REQUEST
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
domain-name-pair
; SET CLUSTER RESPONSE
set-expire-response = standard-response
; SET STATUS REQUEST
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 STATUS RESPONSE
set-expire-response = standard-response
; SET NAMESERVERS REQUEST
set-nameservers-request = set-nameservers-request-header CRLF
set-nameservers-request-body
set-nameservers-request-header = “SET” LWS “NAMESERVERS” LWS protocol
set-nameservers-request-body = registrar-auth-entry cluster-id-pair
*name-server-entry
; SET NAMESERVERS RESPONSE
set-expire-response = standard-response
; SET PASSWORD REQUEST
set-password-request = set-password-request-header CRLF
set-password-request-body
set-password-request-header = "SET" LWS "PASSWORD" LWS protocol
set-password-request-body = registrar-auth-entry domain-name-pair
domain-auth-pair
; SET PASSWORD RESPONSE
set-password-response = standard-response
; DELETE DOMAIN REQUEST
delete-domain-request = delete-domain-request-header CRLF
delete-domain-request-body
delete-domain-request-header = “DELETE” LWS “DOMAIN” LWS protocol
delete-domain-request-body = registrar-auth-entry domain-name-pair
; DELETE DOMAIN RESPONSE
delete-domain-response = standard-response
; DELETE CLUSTER REQUEST
delete-cluster-request = delete-cluster-request-header CRLF
delete-cluster-request-body
delete-cluster-request-header = “DELETE” LWS “CLUSTER” LWS protocol
delete-cluster-request-body = registrar-auth-entry cluster-id-pair
; DELETE CLUSTER RESPONSE
delete-domain-response = standard-response
; QUERY DOMAIN REQUEST
query-domain-request = query-domain-request-header CRLF
query-domain-request-body
query-domain-request-header = “QUERY” LWS “DOMAIN” LWS protocol
query-domain-request-body = registrar-auth-entry domain-name-pair
[get-specific-pair]
; QUERY DOMAIN RESPONSE
query-domain-response = full-domain-response / specific-domain-response /
error-response-message
full-domain-response = success-header CRLF *attribute-value-pair
specific-response = success-header CRLF attribute-value-pair
; QUERY CLUSTER REQUEST
query-cluster-request = query-cluster-request-header CRLF
query-cluster-request-body
query-cluster-request-header = “QUERY” LWS “CLUSTER” LWS protocol
query-cluster-request-body = registrar-auth-entry cluster-id-pair
; QUERY CLUSTER RESPONSE
query-cluster-response = standard-response
; TRANSFER DOMAIN REQUESTtransfer-domain-request = transfer-domain-request-header CRLF
transfer-domain-request-body
transfer-domain-request-header = “TRANSFER” LWS “REQUEST” LWS protocol
transfer-domain-request-body = registrar-auth-entry domain-name-pair
; TRANSFER DOMAIN RESPONSE
transfer-domain-response = standard-response
; STATUS DEFAULTS REQUEST
status-defaults-request = status-defaults-request-header CRLF
status-defaults-request-body
status-defaults-request-header = “STATUS” LWS “DEFAULTS” LWS protocol
status-defaults-request-body = registrar-auth-entry
; STATUS DEFAULTS RESPONSE
status-defaults-response = status-defaults-response-message /
standard-error-message
status-defaults-response-message = success-header CRLF
status-defaults-response-body
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
CRLF
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 = status-server-request-header CRLF
status-server-request-body
status-server-request-header = “STATUS” LWS “SERVER” LWS protocol
status-server-request-body = registrar-auth-entry
; STATUS SERVER RESPONSE
status-server-response = status-server-response-message /
standard-error-message
status-server-response-message = success-header CRLF
status-server-response-body
status-server-response-body = *text-pair
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.
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.
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.
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.
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:
add
EntityName:NameServer
NameServer:ns1.example.com
IPAddress:161.92.114.198
.
add
EntityName:NameServer
NameServer:ns2.example.com
IPAddress:161.92.114.199
.
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:
CREATE CLUSTER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
ns1-name=ns1.example.com
ns1-address=161.92.114.198
ns2-name=ns2.example.com
ns2-address=161.92.114.199
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.
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:
del
EntityName:NameServer
NameServer:ns1.example.com
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:
QUERY CLUSTER SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
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:
SET NAMESERVERS SRRP/1.0
registrar-id=123456789
registrar-auth=pass-phrase
cluster-id=987654321
ns1-name=ns2.example.com
ns2-address=135.94.18.121
ns3-name=ns3.example.com
ns3-address=135.94.18.121
The name
server ns1.example.com will now be deleted.
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 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]
Comments:
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
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.
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.
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.
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.
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.
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.