en

Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

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

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

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

(8 August 2003)


Functional Specifications

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 Top Level Id

Domain Top Level Name

10

NAME

DOMAIN SECOND LEVEL :

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

Domain 2nd Level Id

Domain 2nd Level Name

Defensive Registration

10

SMITH

N

11

JONES

N

12

BLOGGS

N

13

PATEL

Y

DOMAIN THIRD LEVEL :

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

Domain 3rd Level Id

Domain 3rd Level Name

Defensive Registration

10

JOHN

N

11

ANDREW

N

12

JAYNE

N

13

JAMES

Y

DOMAIN TABLE :

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

Domain Id

Top Level Id

2nd Level Id

3rd Level Id

Registrar Id

Status

Expiry Date

Creation Date

Transfer Date

Modification  timestamp

10

10

10

10

12

Active

2003-03-01

2001-03-01

N/A

2001-03-12-12:44:12

11 10 12 11 12 Active 2003-03-01 2001-03-01 N/A 2001-03-12-12:44:12
12

10

13

 

12

Active

2005-03-01

2004-03-01

N/A

2004-03-12-12:44:12

SUSPENDED DOMAINS :

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

Domain Id

Registrar Id

Status

Modification Timestamp

Dispute Ref

10

12

In Dispute

2002-03-12-12:01:01

121

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.

Defensive Id

Registrar Id

2nd Level Id

3rd Level Id

Defensive String

Any String

Modification Timestamp

Creation Date

Expiry Date

11

12

13

 

ICANN

Yes

2001-03-12-01:01:22

2001-03-12

2004-03-12

EMAIL FORWARDING TABLE:

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

Email Id

Top Level Id

2nd Level Id

3rd Level Id

Registrar Id

Address to forward to

Status

Expiry Date

Creation Date

Modification Timestamp

10

10

10

10

12

john@acme.co.uk

Active

2003-03-01

2001-03-01

2001-03-13-12.56.23

11

10

12

11

12

jhs2@acme.co.uk

Active

2003-03-01

2001-03-01

2001-03-12-09.08.55

EMAIL CLIENT DETAILS :

Email Id linking to the Contact Details table.

Email Id

Registrant Id

Contact Id

Technical Id

Billing Id

10

121

12

12

12

NameWatch Watched String Storage

WatchedString

Level

Status

Frequency of reports

Contact ID

Registrar ID

Creation

Modification

Expiry

IBM

second

active

weekly

1134

110

2001-08-10-12:12:34

2001-08-10-12:12:34

2003-08-10

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

WatchedString

Level

Status

Frequency of reports

Contact ID

Registrar ID

Creation

Modification

Expiry

IBM

second

active

weekly

1134

110

2001-08-10-12:12:34

2001-08-10-12:12:34

2003-08-10

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

Name Server Id

Registrar Id

Name Server Name

Status

Modification Timestamp

111

12

ns1.workemail.co.uk

ACTIVE

2001-03-12-11.10.19

112

12

ns2.workemail.co.uk

ACTIVE

2001-03-12-11.10.20

113

11

Ns1.acme.co.uk

ACTIVE

2001-03-12-11.10.21

IP ADDRESS :
IP Id lookup to real IP address.

Name Server Id

IP Address

Modification Timestamp

111

10.10.10.111

2001-03-13-12.11.01

112

192.168.1.106

2001-03-13-12.14.54

113

192.154.12.121

2001-03-13-13.43.47

111

10.10.11.112

2001-03-13-15.15.21

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

TranX Id

Registrar Id

Object Id

Object Reference

TranX Type

Modification Timestamp

Cost

Discounted Cost

123

12

10

DOMAINS

Purchase

2001-03-12-12:44:12

500

500

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

Registrar Id

Transaction Id

Balance

Modification Timestamp

10

10

99845

2001-03-12-02:20:21

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

Registrar Id

Registrar Name

Business Address

Contact information

Modification Timestamp

Status

12

Acme Registrations

1, New Road, New Town, CountryX.

z@acme.registrar.net

2001-02-28-11:12:13

Active

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

Registrar Id

Contact Id

Contact Type

12

1001

Administration

13

1002

Technical

12

1003

Technical

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

Domain Id

Registrant Id

Contact Id

Technical Id

Billing Id

10

121

12

12

12

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

Contact Id

Contact Handle

Registrar Id

Status

Name

Address

City

State

Post Code

Country

Phone

Fax

Email

Modification

13

JJA00013

12

active

Jayne Jones

12, Old St.

CityY

Kent

PP1 2PP

UK

+44. 123 123 123

 

j123@workemail.co.uk

2001-03-13-11:59:09

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.

Figure 1


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


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 12-Aug-2003

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