Proposed Unsponsored TLD Agreement: Appendix C, Part 3 (.name)

Proposed Unsponsored TLD Agreement: Appendix C, Part 3 (.name) (8 August 2003)

Part 3 - Shared Registration System and Database

General Overview

The logical database will consist of a single database image with redundancy built into the system. There will be a secondary database server standing by to take over should the primary fail. In addition, the database will be also be recoverable to an off-site location should a disaster scenario arise.

The main database will be DB2 running on the AIX operating system on IBM hardware. The secondary server will be of identical specification in both hardware and software. It has been scaled to achieve the performance indicated in Appendix D - Performance Specification. The selection of hardware and third party software was taken to allow for future scaling to protect the initial investment associated with building the Registry.

The database will be the primary container of all registered transactions and domain names. The Registry Server will be responsible for the communication with the database via stored programs and procedures. Recoverability of the database is enhanced through the use of redundant systems, which extends to the use of Whois replication out in production, as well as to the disaster recovery site.

When a transaction request is received that will update the database, the Registry Server will write a message to a secure log. The request is then translated into a common format for use by the Registry Server backend. It is then translated into a SQL transaction for processing by the database engine. The tables have been created to minimize the level of code required to check for integrity as this is left to the database server itself where possible. Upon completion of the SQL transaction, another message is written to the secure log. This results in several layers of logging which may be used to ensure data integrity on a regular basis by confirming that the request and data correlate against each other. Should the SQL transaction fail in processing with an error that is not catered for, activity against the database will be suspended until such time as the fault is determined and rectified. Recovery will be a manual procedure as there may be many possible solutions depending on the circumstances.

The Registrar is to assume its transaction request has failed unless the Registrar is notified otherwise in the reply from the Registry Operator. To improve redundancy the data must be stored in another location as well. Upon completion of the SQL transaction to the main site, a message will be queued for synchronous delivery to the disaster recovery site. Only if the disaster recovery site confirms receipt of the message is the transaction allowed to proceed and reply made to the Registrar.

Name store overview

All data necessary for the correct operation of the registry will be stored in the database in appropriate tables and categories. Database systems will support all aspects of registry services, including domain-name registration, the SLD E-mail forwarding service, Defensive Registrations, the NameWatch service, zone-file generation, Whois services, data escrow, registrar reports, and billing.

The precise data structure is under development. The following list of data items is intended as a guide to the final fields expected to be stored, but is not comprehensive or complete. It is subject to change due to external and internal factors including, but not limited to, cost, performance, requests, and ongoing standardization activity.

• domain names
  
  
• domain name status
  
  
• domain name expiry date
  
  
• domain name creation date
  
  
• domain name nameserver
  
  
• suspended domain names
  
  
• registrar details
  
  
• registrar IP address
  
  
• registrar credit status
  
  
• registrar credit balance
  
  
• transaction id
  
  
• transaction timestamp
  
  
• registrar contact point
  
  
• e-mail forwarding information

Additionally, the database will store information on the registrant. This will include name, address, telephone and email. Other details pertaining to the registrant's financial status with the Registrar are not to be stored by the Registry Operator, thus allowing the Registrar to registrant relationship to remain private. The Registry Operator will additionally store similar data, where applicable, for the administrative, technical, and billing contacts.

Database structure

The following is the Registry Operator's structure for the database containing the relevant business data. It is subject to change following testing and activation in production. Registry Operator will provide ICANN with updated specifications of the structure as implementation proceeds.

The tables are named as follows with a brief description describing some of the relevant fields contained herein. These tables are for illustrative purposes as they are subject to change following reviews and performance considerations. Certain fields where passwords may be stored are not shown.

DOMAIN TOP LEVEL:

.NAME in the Registry Operator's case, linking to a key.

DOMAIN SECOND LEVEL :

A last name, or a first name, linking to a key.

DOMAIN THIRD LEVEL :

A first name, or last name, linking to a key.

DOMAIN TABLE :

A Registrar Id, domain level keys and relevant time-stamp information.

SUSPENDED DOMAINS :

Domain level Id for those which domains deemed to be suspensed.

DEFENSIVE REGISTRATIONS :

Unique string to be checked before registration, which domain levels it applies to, and are the other levels to be checked via an "any string" match.

EMAIL FORWARDING TABLE:

Email Address to forward the mails destined for thirdlevel@secondlevel.toplevel

EMAIL CLIENT DETAILS :

Email Id linking to the Contact Details table.

NameWatch Watched String Storage

NAMESERVER LOOKUP :
Domain Id matches to one or more Nameserver Ids.

NAMESERVER :
Registrar Id, time-stamp on modification, IP addresses.

IP ADDRESS :
IP Id lookup to real IP address.

TRANSACTION :
Transaction id for each update to domains or payment.

PAYMENT :
Stores the relevant credit balance before and after payments from each Registrar.

REGISTRAR :
Registrar contact details with time-stamp information, linking to a unique key value.

REGISTRAR CLIENT DETAILS :
Registrar Id lookup to Contact Clients table.

CLIENT DETAILS :
Will hold references to the CONTACT DETAILS table, the main basis of links required to rebuild the WHOIS contact details.

CONTACT DETAILS :
Name, handle, address, telephone, facsimile and email linked to a unique key value. Not all fields are mandatory.

Enforcement of Format Requirements and Naming Restrictions

The functional specification for the registry system specifies the required format of various data elements (domain names, SLD E-mail forwarding addresses, etc.) and restrictions on permissible names. Some examples, www.<x>.name will not be allowed, or <x>.uk.name. See Appendices L, K, and X for details. The data storage system will perform appropriate checks to ensure that only properly formatted data elements consistent with specified restrictions will be entered into the database. Moreover, program logic will ensure that generated Whois data and zone files are consistent with format requirements and naming restrictions even in the event noncompliant data is stored in the database.

Summary of Relationship of Database Tables

The relationships between the various tables are illustrated below.

Links not shown for the sake of clarity are those from the Defensive Registration table to the Registrar table, and those individual links from Top Level Domain, Second Level Domain and Third Level Domain to the SLD E-mail Forwarding Table. The Namewatch table has not been illustrated on this diagram as it has no effect on the SRS in normal operations and is used for report generation only. This diagram will be updated as implementation proceeds and provided to ICANN.

Previous Version:

2 July 2001

Page Updated 12-Aug-2003

(c) 2001, 2002, 2003  The Internet Corporation for Assigned Names and Numbers. All rights reserved.