Also, Global Name Registry will fully support EPP as defined by Draft-IETF-Provreg-EPP-06, although Global Name Registry will use higher version numbers if and when they become appropriately available, and will migrate all its EPP interfaces to the EPP standard when finally stable and recommended by IETF.

Global Name Registry will initially only support the RRP, but after an initial period, both the RRP and the EPP will be fully and simultaneously supported. This gives registrars flexibility to choose to migrate when they wish. Also, this dual support minimizes the risk of any instability since Registrars can attempt migration and move back to RRP in case of problems. The Registry Business Logic is enforced by an isolated protocol independent layer shared by all interfaces to the registry. This ensures a fair treatment of the Registrars independently of their protocol of choice. Any changes made to Registry Policy will be simultaneously reflected in both protocols. The layering also simplifies the addition of new protocols (e.g. new versions of the EPP protocol) at a later stage.

Figure 1 High level SRS layering

A more detailed description of the Layering of our SRS application can be found in Section C22.

Registry Registrar Protocol (RRP) Layer

The RRP server will be implemented according to RFC 2832, with emphasis on compliance with the Verisign implementation already in use by the Registrars. To ensure a smooth transition from Verisign to Global Name Registry for the registrars, all issues not specified in the RFC but implemented by Verisign will thus be implemented to reflect the current functionality. This includes issues like out-of-band communication by email in the case of transfers, etc. For a fuller discussion on Registrar Transition from Verisign to Global Name Registry, see Section C18.2.

Although it is impossible to guarantee 100% compatibility with all existing RRP clients, Global Name Registry will put great effort into the compatibility issues surrounding the transfer from Verisign. All clients built on the Verisign RRP SDK in its latest revision will be supported.

For more information about the RRP protocol layer, see Section C22.

Extensible Provisioning Protocol (EPP) Layer

The EPP protocol will be implemented according to the IETF-ProvReg EPP Draft 0.6. No extensions to the protocol will be needed for initial .org operation.

Protocol Independent Layer

The Protocol Independent Layer will be implemented as an object oriented C++ API library on which to build all our SRS applications. Global Name Registry is very experienced with C++ and C++ embedded SQL. Every application existing in the SRS at any given time will use the same library version to access the Registry Data to enforce equal policy treatment for all services. The interface exposed by the API will be a superset of the functionality needed by all protocols supported by the SRS. Any translations needed from the internal data representation to the client will be done by the Protocol Layer.

For more information about the protocol independent layer, see Section C22.

Protocol specific Procedures and rules

An important part of the SRS (as defined in Section C17.1) is the business logic that translates a Registrar request, whether through RRP or EPP, to transactions in the Oracle database. Some of this logic is handled by the EPP servers, as described in Section C17.2, other by the business logic layer or the stored procedures in the database.

For a number of business operations (both billable and non-billable), the following high level rules and policies apply to the operations in the database. This is a non-layer-specific rule-set, and may be implemented both in the actual database, in the business logic, or in the front end servers (EPP or RRP) (the latter only for protocol specific rules)

Business operations include:

1. Register (for billable objects)

2. Create (for non billable objects)

3. Delete

4. Modify

5. Transfer

6. Renew (for billable objects)

7. Information query (CHECK or INFO or POLL or for TRANSFER)

8. Grace Period implementation

9. Bulk Transfer

The procedures and rules of these functions are described in the following:

Domain names

Format

A domain name is of the format “example.org”. A domain name of this format will sometimes be called a Fully Qualified Domain Name (FQDN)

Eligibility requirements and dispute resolution

The domain name is subject to Eligibility Requirements and Dispute Resolution.

Uniqueness/Multiplicity

A FQDN is unique in the .org zone. Two identical FQDNs can not simultaneously exist on .org.

String restrictions

The following restrictions apply to a domain name:

Length restriction

Maximum length of the second level is 63 characters, resulting in a maximum length for the FQDN of 63+4 = 67 characters
Minimum length of the second level is 2 characters.

Character set restrictions

Only the domain name character set (See definition in Appendix) is allowed for the FQDN

Reserved strings, words, numbers, combinations

o Certain strings are reserved as described in “Reserved Strings”

Associations

Contact information (optional, existing for thick objects only)

Registrant
Administrative Contact
Technical Contact
Billing Contact

Sponsoring Registrar
A minimum of two and maximum of 13 hosts

An Auth-info – used to authenticate certain operations on the object
Status(es) – used to describe its status in the Registry
A creation date, modification date and expiry date

· Children nameservers of the domain (e.g. "ns1.example.org" for the domain "example.org")

Whois

The domain name appears in the .org Whois service, as specified in the Whois specification.

DNS

The domain name resolves in the .org DNS

Registration

Registration is for 1-10 years, in one-year intervals

Registrations are subject to Grace Periods.

Modifications

All associated information described under “Associations”, including contact IDs, can be modified, unless the domain name has status.

The domain name can be modified, unless it has any statuses that prohibit this operation. Such status will for the Registrar be protocol specific (EPP or RRP) but will have a consistent internal specification (non-protocol specific).

(note that Deletions, Transfers and Renewals are described separately and are not considered as “modifications”)

Renewals

The domain name can be renewed, unless it has any statuses that prohibit this operation. Such status will for the Registrar be protocol specific (EPP or RRP), but will have a consistent internal specification (non-protocol specific). Protocol-specific statuses are described in more detail in Section C17.2

A request for renewal that would set the expiry date to more than 10 years into the future will be denied. However, a request that would set the expiry date to 10 years plus a fraction of a year, will set the expiry date to 10 years in the future, and any remaining time will be forfeited.

For example, 10 year renewals are possible if the expiry date of the domain name is less than 1 year in the future. In this case, the expiry date will be set to 10 years into the future, and any remaining time will be forfeited.

Automatic renewal will happen when a domain name expires. In the case of Auto-Renewal of the domain name, a separate Auto-Renew Grace Period will apply.

Renewals are subject to Grace Periods as described below.

Transfers

The domain name can be transferred, unless it has any statuses that prohibit this operation. Such status will for the Registrar be protocol specific (EPP or RRP) but will have a consistent internal specification (non-protocol specific). Protocol-specific statuses are described in more detail in Section C17.2

Under thick EPP operations, a Transfer can only be initiated when the appropriate Authentication information is supplied. The only Registrar to which the Authentication information for Transfer is available is the Current Registrar. A Registrar other than the Current Registrar, wishing to initiate a Transfer on behalf of a Registrant must obtain the Authentication information from the Registrant.

The Authentication information shall be made available to the Registrant upon request. The Registrant is the only party other than the Current Registrar that shall have access to the Authentication information.

The section “Object Transfer under EPP” below describes in more detail how Transfers are performed with the relevant protocols.

Under RRP, a Transfer will be automatically accepted if the losing Registrar does not explicitly deny the Transfer within the applicable Transfer Pending Period.

Registrar Transfer entails a specified extension of the expiry date for the object. The Registrar Transfer is a billable operation and is charged identically to a renewal for the same extension of the period. This period can be from 1 to 10 years, in 1 year increments.

Since Registrar Transfer involves an extension of the registration period, the rules and policies applying to how the resulting expiry date is set after Transfer, are adopted from the Renewal policies on extension.

A domain name cannot be transferred to another Registrar within the first 60 days after Registration. This also continues to apply if the domain name is renewed during the first 60 days.

Transfer of the domain name changes the sponsoring Registrar of the domain name, and also changes the subordinate, local hosts (not foreign hosts, on other TLDs) associated with the domain name.

Deletion

The domain name can be deleted, unless it has any statuses that prohibit this operation. Such status will for the Registrar be protocol specific (EPP or RRP) but will have a consistent internal specification (non-protocol specific). Protocol-specific statuses are described in more detail in Section C17.2

A domain name is also prohibited from Deletion if it has any in-zone child hosts. For example, the domain name example.org cannot be deleted if an in-zone host ns.example.org exists.

The Deletion mechanism marks the name for deletion, and invokes the Deletion Mechanism. The current version of the Deletion Mechanism is described in the “Deletion Pending Period” section below. Future versions of the Deletion Mechanism may change the way a domain is deleted.

Contact objects (only exist in the Registry in “thick” mode)

Transfer

Transfer of contact objects is allowed provided that no other objects are associated with the Contact object being transferred

Deletion

Deletion of contact objects is allowed provided that no other objects are associated with the Contact object being deleted

Billing

A contact object is not a billable object.

Usage

A contact object can be referred to by Registrars other than the Sponsoring Registrar.

Associations

An Auth-info – used to authenticate certain operations on the object
A creation date and modification date
Status(es)

· Sponsoring Registrar

Host objects

Types of host objects

There are two types of hosts: In-zone hosts and out-of-zone hosts.

In-zone hosts

An in-zone host is a Host object where the host address is on .org.

Creation

Creation of an in-zone host is only allowed if the host address is on a domain name object owned by the Registrar.

For example, only the Registrar owning the domain name object example.org can create the host ns.example.org .

Uniqueness/Multiplicity

Only single entries of in-zone hosts can exist in the Registry.

Usage

Any Registrar can refer to a host object in this category.

Deletion

Deletion of an in-zone host is allowed provided that no other objects are associated with the host.

Transfer

Explicit transfer of an in-zone host is not allowed (only implicit transfer through transfer of the domain name on which the host resides).

Associations

· A host can be associated with up to 13 IP Addresses

· A creation date and modification date

· Status(es)

· Sponsoring Registrar

· Parent domain (e.g. "example.org" for "ns1.example.org")

Out-of-zone hosts: Host objects where the host address is not on .org

Creation

Any Registrar can create an out-of-zone host.

Uniqueness/Multiplicity

Multiple identical entries of out-of-zone hosts can exist in the Registry, however, out-of-zone hosts are unique per Registrar.

Usage

Only the Registrar owning a host object in this category can refer to it.

Deletion

Deletion of an out-of-zone host is allowed provided that no other objects are associated with the host.

Transfer

Explicit transfer of an out-of-zone host is not allowed.

Associations

· A creation date and modification date

· Status(es)

· Sponsoring Registrar

Common rules for both types of hosts

String restrictions

Length restriction

Maximum length of the host name is 254 characters

o Minimum length of the host name is determined by the minimum length of a second level and third level as specified for the domain names.

Billing

A Host object is not a billable object.

Registrar objects

Associations

The ICANN Accredited Registrar is associated with at least one of each of the following contact points. Up to 13 instances of each contain point can be associated.

Administrative Contact in the Registrar
Technical Contact in the Registrar
Billing Contact in the Registrar

· Registrar Balance

Create

A Registrar object can only be created by the Registry.

Modification

Modification of a Registrar object is allowed, by the Registrar.

Transfer

Transfer of a Registrar object is not allowed.

Deletion

Deletion of a Registrar object can only be done by the Registry.

Billing

A Registrar object is not a billable object.

General rules for Registry Objects

General rules for objects

An object cannot be viewed (under EPP: “INFO”) by anyone else than the sponsoring Registrar. However, the availability check (under EPP: “CHECK”) is available for all objects. (In EPP 0.6 an "info" is allowed if correct AuthInfo is given in the request)
Grace Periods apply for certain objects

Add Grace Periods

All registrars and all registrations will have a 5 day (120-hour) add grace period.

The Add Grace Period is a specified number of hours following the initial registration of a domain. The current value of the Add Grace Period for all registrars is 5 days (120 hours). If a Delete, Extend (Renew), or Transfer operation occurs within the 5 days (120 hours), the following rules apply:

Delete

If a registration is deleted within the Add Grace Period, the sponsoring registrar at the time of the deletion is credited for the amount of the registration. The domain is deleted from the Registry database according to the Deletion mechanism in use at the time. See Overlapping Grace Periods for a description of overlapping grace period exceptions.

If a domain name is deleted after the 5-day (120 hours) grace period expires, it will be placed on HOLD for 5 days and then deleted through the system.

Renew

If a registration is extended within the Add Grace Period, there is no credit for the Add. The account of the sponsoring Registrar at the time of the extension will be charged for the initial add plus the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a total of ten years, as specified by the registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer)

Registrar Transfers may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the registrar sponsoring the domain name registration and will be enforced by the SRS.

Bulk Transfer (with ICANN approval)

Bulk transfers with ICANN approval may be made during the Add Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial add.

Renew/Extend Grace Period

All registrars and all registrations will have a 5 day (120-hour) Renew/Extend grace period.

The Renew/Extend Grace Period is a specified number of hours following the renewal/extension of a domain name registration period. The current value of the Renew/Extend Grace Period is 5 days (120 hours). If a Delete, Extend, or Transfer occurs within that 5 days (120 hours), the following rules apply:

Delete

If a registration is deleted within the Renew/Extend Grace Period, the sponsoring registrar at the time of the deletion receives a credit of the renew/extend fee. The domain is deleted from the Registry database according to the Deletion mechanism in use at the time.

See Overlapping Grace Periods for a description of overlapping grace period exceptions.

Extend (Renew)

A registration can be extended within the Renew/Extend Grace Period for up to a total of ten years. The registrar's available credit will be charged for each of the additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer)

If a registration is transferred within the Renew/Extend Grace Period, there is no credit. The expiration date of the registration is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years.

Bulk Transfer (with ICANN approval)

Bulk transfers with ICANN approval may be made during the Renew/Extend Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Renew/Extend operation.

Transfer Grace Period

All Registrars and all registrations will have a 5 day (120-hour) Transfer grace period.

The Transfer Grace Period is the 5 days (120 hours) following the transfer of a domain. If a Delete, Extend, or Transfer occurs within that 5 days (120 hours), the following rules apply:

Delete

If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See Overlapping Grace Period for a description of overlapping grace period exceptions.

Renew

If a domain is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a maximum of ten years, as specified by the registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer):

If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain is extended by one year up to a maximum term of ten years.

Bulk Transfer (with ICANN approval)

Bulk transfers with ICANN approval may be made during the Transfer Grace Period. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.

Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations as initiated by ICANN according to the Registry-Registrar Agreement. Upon completion of the Bulk Transfer, any associated fee is not refundable.

Overlapping Grace Periods

If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply except as follows:

If a domain name is deleted within a multiple of Renew/Extend Grace Periods (upon several subsequent Renewals), then the registrar is credited the extend amounts, taking into account the number of years for which the registration and extend were done.

If a domain is deleted within the Add Grace Period and the Extend Grace Period, then the registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done.

Grace Periods Overlap Exception

If a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example if a domain is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first and second transfers, then only the last transfer is credited to Registrar C.

If a domain is extended/renewed within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

Note: If several billable operations, including transfers, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current Registrar.

Transfer Pending Period

The Transfer Pending Period is a specified number of hours following a request from a registrar (“Gaining Registrar”) to transfer a domain in which the current registrar of the domain (”Losing Registrar”) may explicitly approve or reject the transfer request.

The current value of the Transfer Pending Period is 5 days (120 hours) for all registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the Losing Registrar.

If the Losing Registrar does not explicitly approve or reject the request initiated by the Gaining Registrar, the registry will approve the request automatically after the end of the Transfer Pending Period. During the Transfer Pending Period:

TRANSFER request or RENEW request is denied.

DELETE request is denied

MODIFY request is denied (modification of associated contact handles or Host handles)

Bulk Transfer operations are allowed.

Delete Pending Period

The Delete Pending Period is a specified number of hours following a request to delete a domain in which the domain is placed in HOLD status without removing the domain from the Registry database. In this status, the domain name can not be re-registered.

The current value of the Delete Pending Period for all registrars is 5 days (120 hours).

Registrars may request retraction of a delete request by calling Registry Operator Customer Service staff within the Delete Pending Period. The Registrar will need to provide the security phrase to the Registry Operator staff member prior to the staff member performing this retraction. This operation cannot be performed by the Registrar. Retraction requests processed during the delete pending period are currently at no cost to the registrar. If, by the end of the Delete Pending Period, no action is taken the domain will be deleted from the Registry database and returned to the pool of domain names available for registration by any registrar.

Renew requests are denied.

Transfer request is denied.

MODIFY request is denied (modification of associated contact handles or Host handles).

Bulk Transfer operations are allowed.

Object Transfers under EPP

(Upon changes to the EPP standard, the exact procedure described below may change, however according the same principles)

The EPP <transfer> command is used to manage changes in Registrar sponsorship of a known object. Registrars may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request using the "op" command attribute of the <transfer> command.

The EPP <transfer> command can only be used to explicitly transfer Domain, Emailforwarding and Contact objects. Nameserver (host) objects are implicitly transferred when a domain is transferred between registrars.

Initiation of Transfers

A Registrar that wishes to assume sponsorship of a known object from another registrar uses the <transfer> command with the value of the "op" attribute set to "request". Once a transfer has been requested, the same Registrar may cancel the request using a command with the value of the "op" attribute set to "cancel". A request to cancel the transfer must be sent to the Registry before the current sponsoring Registrar either approves or rejects the transfer request and before the Registry automatically processes the request due to inactivity on the part of the current sponsoring Registrar.

Approval/Rejection

Once a transfer request has been received by the Registry, the Registry will notify the current sponsoring Registrar of the requested transfer. This notification will be put in the message queue of the affected Registrar and be retrieved when the Registrar later uses the EPP <poll> command. The current status of a pending <transfer> command for any object may be found by the losing and gaining registrar using the <transfer> query command.

The current sponsoring Registrar may explicitly approve or reject the transfer request. The Registrar may approve the request using a <transfer> command with the value of the "op" attribute set to "approve". The Registrar may reject the request using a <transfer> command with the value of the "op" attribute set to "reject".

Authorization

Every <transfer> command must include an authorization identifier to confirm transfer authority. This element contains authorization information associated with the object, or alternatively for domain and email forwarding objects, authorization information associated with the registrant or associated contacts as specified in the EPP drafts.

The Authorization identifier information must not be disclosed to any other Registrar or third party. A Registrar that wishes to transfer an object on behalf of a third party must receive authorization identifier information from the third party before a command can be executed.

Automatic Transfer

The Registry will automatically approve all transfer requests that are not explicitly approved or rejected by the current sponsoring Registrar within five calendar days of the transfer request. The losing registrar will be notified of the automatic transfer via email and through the EPP.

Transfer Notification

Transfer notifications will be put in a message queue in the Registry System. These notifications can be retrieved and acknowledged through the EPP <poll> command at any time. Information about the request can also be found using the <transfer> query command.

Protocol Details

When using the EPP <transfer> command for domain objects, the Registrar will specify the fully qualified domain name of the object for which a transfer request is to be created, approved, rejected or cancelled. For email forwarding objects, the fully qualified email address of the object should be specified, and for contact objects the contact ID that serves as a unique identifier should be specified.

For domain objects and email forwarding objects, the Registrar may also provide an element that contains the number of years to be added to the registration period of the object if the transfer is successful. The minimum and maximum allowable values for the extension is one year and ten years, respectively, and the default value is one year. Registry operator policy restricts the maximum outstanding expiration period for domain objects and email forwarding objects to ten years. A transfer with an extension period that exceeds this limit will be rejected. Exception: If the addition of the minimum allowable value of extension would extend the registration period past the maximum outstanding expiration years, the transfer will go through, but with no registration extension.

Every EPP <transfer> command issued by a Registrar must contain an "op" attribute that specifically identifies the transfer operation to be performed. Valid values, definitions, and authorizations for all attribute values are defined in the EPP specification.

Reserved Strings

Global Name Registry would reserve certain strings from registration if this would help to ensure stability of the .org name space and operations. In particular, this may concern multi-lingual registrations (if any) already made in the .org zone by Verisign as a result of MLD trials conducted earlier. Global Name Registry proposes to establish such a list of reserved names in cooperation with ICANN and any other relevant parties.

C17.3. Database capabilities

Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

C17.3. Database capabilities24

Overview. 24

The databases25

Intercontinental Registry Replication. 26

Messages used for replication. 27

Global Name Registry operates Multiple databases28

Some considerations in Moving from a “Thin” SRS Database to a “thick” SRS Database 29

Reporting (handled by separate database)29

Data Validation and consistency checking. 30

Database Structure and Table structure. 30

Scalability of the database. 31

performance. 33

Database Hardware, Size, Throughput, and Scalability34

Hardware platform and specifications34

Database design parameters34

Load optimization. 36

Database Administration. 36

Database Backup/Restore. 37

Disaster Recovery37

Database Security & Access Privileges37

Overview

Global Name Registry is running a number of large databases today for .name, and will provide for .org an enterprise-strength, fault-tolerant database system capable of managing large databases and high transaction-processing loads reliably, with scalable growth to accommodate change.

The databases currently in operation by Global Name Registry include the .name DNS (a database of domain names mapping to IP addresses), Whois (a database of contact information, nameserver information and domain name information), .name Mail (a database of email addresses and forwarding addresses to which incoming email is forwarded), and SRS (the authorative database of domain name registrations on .name)

The database system supports asynchronous replication of data between two SRS data centers, which are geographically dispersed. The benefit to the Internet community is reliable, stable operations and scalable transaction-processing throughput to accommodate Internet growth.

Global Name Registry anticipates moving the .org database from its current structure, a so-called “thin” database, where no contact information is stored, to a “thick” database, where contact information is stored with each object. The thick database structure has a number of advantages for the community, as explained in Section C18 to this application. Section C18 details how the transition of the database from thin to thick will happen.

The databases

The SRS built by Global Name Registry runs on a database consisting of three separate database servers in addition to an array of whois database servers. Splitting the database tasks on multiple servers results in a highly dedicated and optimized system. The servers are each performing different tasks, which greatly increases the SRS performance and optimizes data quality and access speed. In particular, all check queries done by the Core SRS will be handled by the scalable array of Whois servers, discussed in the "Database scalability using Whois" Section.

Figure 2 Core SRS database distribution at main site

In addition, Global Name Registry operates a second database-set, also consisting of three database servers and a Whois array, running on the Global Name Registry failover site. This failover site, and its role in taking over the SRS operations in case of main site failure, is described in another part of this application.

The databases in operations are Oracle installations running on the AIX operating system on IBM hardware. It has been scaled to achieve high performance consistently during operations and protect the data quality in the Registry. The selection of hardware and third party software allows for future scaling to protect the initial investment associated with building the Registry.

The Whois array is a GNR-db implementation running on the Linux operating system on IBM hardware. This database is constructed to allow for extreme query performance combined with ease of data propagation and a high degree of reliability. The array will by updated by the Update Handler mechanism described in C17.1 and C17.4.

The database is the primary container of all registered transactions and domain names. A Business Logic layer is responsible for the communication with the database via custom C++ applications and stored programs and procedures, all developed by Global Name Registry. Recoverability of the database is enhanced through the use of redundant systems and failover databases, which includes Whois databases as well as the Core SRS database.

In designing the database(s), Global Name Registry has made significant efforts and consideration to split the database and associated logic onto several dedicated systems. Among others, there is a separate database (both in terms of hardware and software) for reporting, a separate database for data validation and consistency checking, and separate servers run different parts of the logic and business rules that access the database. More on this can be explored in sections C22 and C17.2 (RRP and EPP server descriptions).

The two Global Name Registry sites replicate data continuously to ensure that in disaster scenarios, the database stays intact and correct. In such scenarios, the Core SRS can do a failover to the disaster recovery site and run without loss of consistency and authority.

Intercontinental Registry Replication

The authorative database will be replicated to our main failover site in Norway using a persistent MQ. The choice of technology is based on the following main goals:

1. Minimal latency in Core SRS message processing

2. Reliability in message distribution

3. Redundancy in failover situations

Using the replicated database, the backup site will itself maintain the other databases needed for a swift failover, running the same software as on the main site.

Figure 3 Database distribution and replication main site – backup site

Messages used for replication

Archive Log Message

The Archive Log Message will consist of an Oracle Archive Log and corresponding status information including a strictly increasing Archive Log ID, and a reference to the last Update Message ID processed in the current Archive Log batch.

Single Update Message

The Single Update Message will be used to complete the backup database in case of a SRS failover. The message includes the update to be done in the database, and a strictly increasing Update Message ID. The messages will be held internally by the Replicator Software until an Archive Log containing the update is successfully processed by the backup database. To bring the backup database up to current state, the Replicator Software will make sure that no Single Update Messages are left in the MQ, and then execute all the Single Update Messages received since the last successful Archive Log. This ensures that even in the case of failover, the database will be consistent up to the last second.

DB Validation Message

To validate the consistency of the backup database against the main authorative database, the Core SRS system will initiate a DB Validation using a DB Validation Message during a regularly scheduled maintenance window. The message itself contains an Archive Log ID and MD5 sums for all tables included in the database. The process of validation will include the following steps on the main site:

1. Stop updates

2. Send Archive Logs to backup site

3. Dump all tables to clear text

4. Restart updates

5. Generate MD5 sums, and send DB Validation Message to backup site

Upon receiving a DB Validation Message, the Replication Software will insure that the backup database is in the state according to the Archive Log ID supplied, dump the tables to clear text, and check that the MD5 sums match up with the expected result.

Global Name Registry operates Multiple databases

There are a multiple of databases in operation by Global Name Registry at all times:

1. SRS Database —This database’s primary function is to provide highly reliable persistent storage for all of the registry information required to provide domain-registration services. The SRS database is highly secured, with access limited to authenticated registrars, trusted application-server processes, and the registry’s database administrators.

2. Billing Database —This database ensures that billing is handled for all Registrars, and is an integral part of the SRS database. However, this database communicates with Global Name Registrys financial systems operated by the Financial Controllers, rather than with the EPP server (as the SRS database does). Registrars can download and view their billing data through a secure web site at all times.

3. Whois Database —The Whois database is a searchable database that any Internet user can access to view details of the domain name stored in the SRS. The Whois database maintains data about registrars, domain names, nameservers, IP addresses, and the associated TLD contacts. The Whois database is continuously updated from the SRS database through a data quality assurance and replication process. In addition, there are feedback loops that continuously monitor the quality of the Whois data.

In addition to these databases, Global Name Registry maintains various internal databases to support various operations, e.g., authorizing login userids and passwords, authorizing telephone conversations with pass phrases and passwords, authenticating encryption keys, maintaining access-control lists, content databases for i.e. www operations, MX databases for email provisioning, etc.

The Whois and DNS database systems are handled in other chapters of this application. Therefore, in the following, we have chosen to focus on the SRS database system which acts as the authorative repository of all .org domain names and associated objects. This will sometimes be called the “SRS database”.

Some considerations in Moving from a “Thin” SRS Database to a “thick” SRS Database

Global Name Registry anticipates moving the .org database from a “thin” database, where no contact objects are stored in the Registry, but rather held by the Registrar(s) for each of their domain objects, to a “thick” database, similar to the .name database, where each domain name is associated with the relevant contact objects also held in the database. The benefit of a thick database is that Whois can be centralized by the Registry and allows for faster, easier and a much more consistent access to Whois information.

The transition from "thin" to "thick" will be a gradual process. At first, all objects transferred from Verisign will exist in the Global Name Registry without contact information. When Registrars start using the EPP protocol for accessing the Registry they will be able to add contact information to the domains. When all Registrars are converted to the EPP protocol, all new registrations must contain contact information. To migrate existing objects, there will also be a requirement that all domains to be renewed must contain contact information. Realizing that a abrupt switch from "thin" to "thick" database is not possible, the next best thing would be a time limited one-way road towards a complete "thick" registry.

In the following, the database aspects related to continuing operations on the existing (“thin”) .org data structure is described. Until a transition is completed, Global Name Registry will run the .org database as it is run by Verisign today – without extended and centralized information. However, in some of the sections below, considerations that have to be made for the database when moving from “Thin” to “Thick” are discussed. It should be noted that Global Name Registry has extensive experience in building and operating a thick database, since the .name Top-Level domain most likely is the “thickest” and most comprehensive TLD database in existence today, with a multitude of interrelated services (e.g. domain names, email and Defensive Registrations) and associated contacts and statuses.

Reporting (handled by separate database)

The reporting will be handled by a separate database as shown in figure 1. This will be an aggregated database, where all information needed by the reporting software will be easily accessible. The Report Data Aggregation Process is run once per day, and extracts all transactions from the previous run. The Reporting Database will also keep history of Registrar balances for easy extraction.

The separate reporting database will allow for online reporting capabilities without straining the authorative database with massive queries.

Data Validation and consistency checking

The Global Name Registry system for data validation and consistency checking is thoroughly described in Section C17.1

Database Structure and Table structure

All data on .org domain names, hosts, audit tables, account data, domain history, etc, is stored in the database. This authorative data is used for most or all of the previously described operations and rules in the SRS, and some of this authorative data is replicated to the external services, like Whois, DNS, and zone file access.

The following table structure is a proposed structure for how the .org data may be structured internally in the database:

Figure 4: Illustration of data model

Additionally, when “Thick”, 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.

The audit table will include all changes made to the objects in the database, and the amount of data held in the table will constantly increase. To keep the database to a manageable size, this table will once a month be purged to include the last two years history only. All older records will be written to a flat file archive outside the database. They can, if necessary, be retrieved by Customer Services operational interface.

Scalability of the database

In planning for growth, Global Name Registry operates a database system with the ability to add resources on an as-needed basis without interrupting processing. The database platform is extensible in several ways, including the following:

· Size of storage and backup– the physical size of the database continuously increases and therefore the need for disk storage (and backup) increases. The database servers have no internal storage and are connected to the external ESS. The ESS (Enterprise Storage System) from IBM is a fully redundant, internally mirrored, RAID’ed storage solution which currently has 1.5 Tb of storage space, and can be easily expanded to 22 Tb. The backup solutions have to follow the storage space, and the Global Name Registry backup robots back up the database while it is hot, and completes a daily backup cycle onto tape, which is transported to an offsite secure location every week.

· Memory—As the volume increases, so does the need for increased buffer and lock-pool storage. The database platform has 8 GB of internal RAM, and scales to 16 Gb.

· CPUs – additional CPUs can be added as appropriate. The current hardware runs on four-way processors, and can scale up to 32 processors if system CPU load becomes an issue

· Adding database servers – Global Name Registry has the option to add dedicated database servers when needed to improve performance. The separation between the data validation database, the reporting database and the main/authorative database allows Global Name Registry to scale on any of the two former databases by adding servers to take off load from the main database. For example, information queries (that do not change the content of the database) can be uniquely sent to a set of reporting databases that are constantly updated from the main database, thus offloading the check volumes on the main database. See also the separate "Database scalability using Whois" section.

· Adding logic processing units – Given the separation Global Name Registry has made between various parts of the logic that assesses the Registrar queries, Global Name Registry can move additional load on to the linearly scalable front ends and business logic processors to alleviate the load on the authorative database. This comes in addition to adding database servers for specific purposes like reporting.

Database scalability using Whois

To ease the stress on the authorative database and allow for unlimited horizontal scalability of check queries, we would use an array of Whois servers to answer any check query done in the Core SRS. This will enable the Global Name Registry .org SRS to handle large amount of checks and failed adds, which constitutes most of the queries from the Registrars. In particular during an "add storm" for a popular domain, this schema will guarantee a responsive system throughout the ordeal.

The Whois array will be updated as part of the standard Update Handler procedure described in Section C17.1, and will usually be updated within seconds of changes to the main database, and at most within 15 minutes. The array of servers will not be in public Whois production, but exclusively used by the Core SRS to relieve the authorative database.

Figure 5 Core SRS – Whois communication

The possible problems of using a non-authorative data source as the preferred data source for checks in the .org namespace should be investigated. The two conditions that need attention are the following:

1. Object present in authorative database, but not in Whois

2. Object not present in authorative database, but still present in Whois

1. Object present in authorative database, but not in Whois

Check: Core SRS will report the domain as available. A simple check will never guarantee the availability of a domain, but be a good indication. In this case the indication will include all operations since the last update, most likely only seconds ago.

Add: The add command will always do an additional check against the authorative database before a transaction is initiated. The overhead of a simple check is far less than that of a failed add transaction. During an "add storm" we want to keep the number of transactions started for a given domain to an absolute minimum.

Should the number of double checks turn out to be a performance problem, it can be reduced be giving the update message from an add command priority through the Update Handler system.

2. Object not present in authorative database, but still present in Whois

Check: The result from the Whois-array will be considered authorative, and Core SRS reports the name as not available.

Add: The result from the Whois-array will be considered authorative, and Core SRS reports the name as not available.

Fairness: Since all Registrars share the same pipe to the Whois array, no Registrar will receive any systematic advantage of a more up to date Whois server.

performance

The database and SRS system is designed to provide the following functions:

1. Persistence—storage and random retrieval of data

2. Concurrency—ability to support multiple users simultaneously

3. Distribution (data replication)—maintenance of relationships across multiple databases

4. Integrity—methods to ensure data is not lost or corrupted (e.g., automatic two-phase commit, physical and logical log files, roll-forward recovery

5. Availability—support for 24 x 7 x 365 operations (requires redundancy, fault tolerance, on-line maintenance, etc.

6. Scalability—unimpaired performance as the number of users, workload volume, or database size increases

The system is designed for high performance and scalability. Global Name Registry has scalability plans in place for scaling further from tens of millions of registered names and onwards. Scalability is handled in more detail in Section C17.10.

Database Hardware, Size, Throughput, and Scalability

The following table lists design parameters for the initial design of the three major databases. The parameters are based on projected volumes in the first two (2) years. Scalability term in the table refers to the database’s ultimate capacity expressed as a multiple of the initial design capacity in terms of size and transaction processing power.

Hardware platform and specifications

For the SRS database platform, Global Name Registry uses the following proven hardware platform (the same platform is currently operated by Global Name Registry)

Database design parameters

SRS Database
Hardware	· IBM B80 PowerPC 64 Bit high end transaction server · 4 processor RISC CPU I 450 Mhz · 64-bit architecture · Fitted with 8 Gb of memory, extensible up to 16Gb. · Connected to an Enterprise Storage Solution (ESS) from IBM, with 1.5 Tb of hot-backed up RAID1 storage · Triple, redundant hot-swappable power supplies · Dual-attach 1000 BaseTX/FX Ethernet Adapter · Event-management software for remote management
Software	· Oracle 8i · IBM AIX Operating system
Capacity of Domain registrations	20 million
Database throughput	1500 transactions per second
Storage available	Up to total ESS volume of 22 Tb
Database scalability strategy	Scales from 8 (current) to 32 processors Scales from 8 (current) to 16 Gb memory Clustering using Oracle clustering technology

Reporting database
Hardware	· IBM B80 PowerPC 64 Bit high end transaction server · 2 processor RISC CPU I 450 Mhz · 64-bit architecture · Fitted with 1 Gb of memory, extensible up to 16Gb. · Connected to an Enterprise Storage Solution (ESS) from IBM, with 1.5 Tb of hot-backed up RAID1 storage · Triple, redundant hot-swappable power supplies · Dual-attach 1000 BaseTX/FX Ethernet Adapter · Event-management software for remote management
Software	· Oracle 8i · IBM AIX Operating system
Capacity of Domain registrations	20 million
Database throughput	1000 transactions per second
Storage available	Up to total ESS volume of 22 Tb
Database scalability strategy	Scales from 2 (current) to 32 processors Scales from 1 (current) to 16 Gb memory Clustering using Oracle clustering technology

QA database
Hardware	· IBM B80 PowerPC 64 Bit high end transaction server · 2 processor RISC CPU I 450 Mhz · 64-bit architecture · Fitted with 1 Gb of memory, extensible up to 16Gb. · Dual 37Gb Internal SCSI RAID controlled harddrives · Triple, redundant hot-swappable power supplies · Dual-attach 1000 BaseTX/FX Ethernet Adapter · Event-management software for remote management
Software	· Oracle 8i · IBM AIX Operating system
Capacity of Domain registrations	20 million
Database throughput	1000 transactions per second
Storage available	Up to total ESS volume of 22 Tb
Database scalability strategy	Scales from 2 (current) to 32 processors Scales from 1 (current) to 16 Gb memory Clustering using Oracle clustering technology

Whois database
Hardware	· IBM x330 server · Intel Pentium III Dual CPU 1Ghz · Fitted with 1 Gb of memory, extensible up to 8Gb. · Connected to an Enterprise Storage Solution (ESS) from IBM, with 1.5 Tb of hot-backed up RAID1 storage · Double, redundant hot-swappable power supplies · Dual-attach 1000 BaseTX/FX Ethernet Adapter
Software	· Global Name Registry Whois DB · Linux operating system
Capacity of Domain registrations	20 million
Database throughput	Average of 110 reads per second per server, total of 330 reads/second on UK main site Average of 100 inserts per second
Storage available	Up to total ESS volume of 22 Tb
Database scalability strategy	Scales from 2 (current) to 32 processors Scales from 1 (current) to 8 Gb memory Can add virtually unlimited number of servers in load balancing to increase read capacity Can use solid state storage instead of hard drives to increase insert transaction capacity

Load optimization

The SRS database is optimized to handle large quantities of data and support both a thin and a thick data model. Global Name Registry has extensive experience with the thick data model from running the .name Registry. The multitude of objects on .name (including the .name Email and the Defensive Registrations) make the .name Registry a complex structure which has to support a number of applications and operations.

Further, the database is optimized for a high number of users and transactions. In designing the database, Global Name Registry has taken into consideration that the volume of SRS transactions contain a high ratio of Reads versus Writes. (“CHECK” vs “REGISTER”). The database is designed to have the highest possible response time for all operations and scale well for future applications and volumes.

Database Administration

Global Name Registry personnel who administer and maintain the database will perform their tasks at times and intervals scheduled to ensure maximum system availability. Typical database-administration tasks include the following:

· Monitoring and tuning

· Dumping of audit tables to disk, and storing

· Starting and stopping

· Backing up and recovering

· Adding additional data volumes

· Defining clustering strategies

· Reorganizing

· Adding and removing indexes

· Evolving the schema

· Granting access

· Browsing and querying

· Configuring fault tolerance

Database Backup/Restore

The backup of the database is assured both by the mirroring of the main database to the QA database, and also by storing backup images of the database both on disk (in the ESS) and on tape. Please see Section C17.7 for more detail on how the database is backed up.

Disaster Recovery

The main database asynchronously replicate over to the QA database. Additionally, the database in the Disaster Recovery Site is replicated from the main site for the unlikely event of a catastrophe that forces a failover. This procedure is described in more detail in Sections C17.14, C17.15, C17.16.

Database Security & Access Privileges

Security is described in more detail in other parts of this application. A brief summary of the database security measures includes:

· Database servers are physically protected by locks, cages and hosting suites in the hosting center.

· Only database administrators have privileges on the database.

· Global Name Registry does logging/auditing/monitoring of all database access to ensure there is no unauthorized access.

· Registrar access to the database is only via the protocol interface.

· Global Name Registry has routine auditing/monitoring features to ensure there is no unauthorized activity, and will periodically review security features to ensure that the system is functioning as needed

C17.4 Zone file generation

Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

C17.4 Zone file generation. 38

The update process and zone file generation. 38

Frequency40

Security and authentication. 42

Backup and recovery42

Zone file access42

For this section, refer also to C17.5, as the generation of Zone files and their distribution is closely linked due to the real time characteristics of the zone file update process. For an overview of the end to end process of zone file update, see Section C17.1.

The traditional way of propagating changes in the Authorative Registry Database to the Master DNS servers, where master zone files are completely regenerated at periodical intervals and then distributed to the resolving servers by means of for example FTP or other transportation technologies, implies in most cases a up to 24 hours delay before changes in the SRS are reflected in the resolving services.

To avoid this delay, and assure a faster and more efficient propagation of changes to the resolving services, Global Name Registry has designed and currently operates for .name a system that solves the problem of zone file generation and zone file distribution (treated in succeeding chapter C17.5) in a slightly different way than the traditional one. Global Name Registry therefore rarely uses the concept of zone file generation in isolation, but rather considers the fuller process associated with real-time object updates.

This Section C17.5 and the following C17.6 present a focused view on the DNS as described in chapter C17.1, concentrating on what can be called respectively the zone file generation part and the zone file distribution part of the specified system. Note that figures in this Section are occasionally split in two, and the remaining part appears in C17.6.

The update process and zone file generation

Since there never will be a complete zone file regeneration, unless in case of major inconsistencies or disaster recovery where the zone file is rebuilt from information contained in the Authorative Registry Database, we will here define the zone file generation process to be the process initiated by the Update Message Generator in the Core SRS (see Section C17.1, under Core SRS) and ending in the updating of the zone file held in the Master Servers memory.

From a deployment view the involved parts of the DNS system can be illustrated as in the figure on the following page (non-relevant system components are shaded):

Figure 1: Zone file generation - a deployment view

For details concerning hardware specifications see chapter C17.1, section 2.4 – The DNS Package.

Frequency

As the system is designed to provide near real time reflection of changes made to the Authorative Registry Database in the Resolving Services, the actual zone file update frequency depends on the frequency of changes made in the Authorative Registry Database.

For the purpose of the zone file residing on the Master DNS, this is more a matter of latency than of frequency, as the zone file is continuously updated whenever changes occur. The latency aspect is described in more detail in Chapter C17.1 section 1.2.2 - Real time and asynchronous communication between Registry Systems.

In cases of heavy system load some latency may be caused by the accumulation of MQ Messages in the different queues that a message may pass on its way to the DNS Update Server. However, under normal operational conditions there should only be a minor delay caused by the processing time associated with the different steps a message undertakes. The update latency under normal operating conditions would in most cases be measured in seconds. See chapter C17.10 for some more details about congestion control.

The process of updating the DNS Masters zone file is illustrated in the figure on the following page (non-relevant processing steps are shaded):

Figur 2: Zone file generation - a process view

This is a stepwise explanation of zone file update process run by the DNS Master server as illustrated above:

1. The update process MQ2DNS sends out dynamic DNS update messages to the DNS Master server according to RFC2136.

2. Master BIND9 receives dynamic updates on port 53 as a series of DNS "update" requests, and sends out reply messages acknowledging them or reporting errors. Multiple updates may be sent in one message. Each update message (potentially containing 1 or more updates) causes BIND9 to update the zone file in memory, making the requested changes and increasing the serial number of the SOA record by one, and also the journal file is updated to reflect the changes between the previous zone and the new one.

3. The zone is then updated/distributed as described in C17.6

Security and authentication

As illustrated in preceding figure, all communication between the main site where the Update Handler resides and the Regional sites where the DNS system (Local Update Server and DNS Master Server) reside run over secure TCP/IP connection (VPN), thus preventing tampering with the information.

Point-to-point authentication and integrity checking according to RFC2845 using shared secret keys to establish a trust relationship between two entities is used to safeguard the communication between the MQ2DNS process and the Bind9 process both running on the DNS Master Server. This prevents any succeeding intruders from sending fake DNS update messages.

An outmost important component assuring the validity and consistency of the zone file information is the Automated Consistency Validation system, described in detail in chapter C17.1 section 2.6. This systems main task is to assure the consistency between information stored in the Authorative Registry Database and information available through the Resolving Services, hereunder the DNS service.

Backup and recovery

The DNS zone file is not backed up. Rather, all the information contained in the zone file is backed up regularly and any DNS server zone file can be restored at any time. If a DNS server crashes or otherwise becomes corrupt so as to be restored, a full reload is initiated from the Master DNS server. The Master DNS server can in turn be fully reloaded from the database, which is carefully backed up regularly as described in C17.7.

Since a local zone file backup would always be out-of-date, not backing up the zone files leads to far higher consistency.

See chapter C17.7, C17.9 and C17.15 for more on system backup and recovery.

Zone file access

There are three ways of “accessing the zone file”:

1) Registrars can modify the contents of the zone file by entering updated through the protocol interface to the SRS, or

2) any entity can download a copy of the zonefile from the Global Name Registry Zone File Access FTP server, which is updated every 12 hours, or

3) ICANN or IANA can transfer the zonefile from one of the DNS servers to a specified IP address at any point in time.

There is no other way of accessing the zone file as the zone file is the prime responsibility of the Registry and it is therefore strictly controlled and protected.

C17.5 Zone file distribution and publication

Locations of name servers, procedures for and means of distributing zone files to them.

C17.5 Zone file distribution and publication. 44

Locations of DNS servers44

Distribution of Zone File. 46

Frequency49

Security and authentication. 49

For this section, please refer also to C17.4, as the distribution of zone files and their generation is closely linked due to the real time characteristics of the zone file update process. For an overview of the end to end process of zone file update, see preceding chapter C17.1.

What we will do in this chapter is to present a focused view on the DNS package described in chapter C17.1, concentrating on what can be called the zone file distribution part of the specified system.

Locations of DNS servers

Global Name Registry will operate five regional DNS server sites for .org distributed throughout the world:

· United Kingdom (UK), this is the main site

· Norway (NO), this is the disaster recovery site

· Hong Kong (HK)

· USA – east coast (US-e)

· USA – west coast (US-w)

New locations may be added as load grows.

Each site consists of a Local Update Handler, responsible for the distribution of MQ Messages to the local Resolving Services, a Master DNS Server which acts as a stealth primary DNS server, and a cluster of Slave DNS servers responsible for providing the public accessible DNS resolving service. The deployment diagram on the following page gives an overview of the servers residing at each site (system components not directly relevant to the zone file distribution process are shaded):

Figure 6: Zone file distribution - a deployment view

For details concerning hardware specifications see chapter C17.1, section 2.4 – The DNS Package.

Each of the regional sites is identically configured, containing a cluster of DNS servers running standard Bind9 software answering query request on port 53 behind a set of redundant firewalls and load balancers. In addition there is a Master DNS Server, responsible for the propagation of zone file changes to each of the Slave DNS Servers.

Distribution of Zone File

The DNS servers will all be continuously updated from the Master DNS Server, which is running as stealth primary DNS. We use BIND9, developed by ISC, which supports the DNS extensions necessary to allow Incremental Zone Transfers (IXFR). The sole mission of the Master DNS Server is to notify the Slave DNS Servers of zone file updates, and provide the updated zone file information when the Slaver DNS Servers request it.

The figure on the following page describes the distribution process from the Registry System to the DNS Slave Servers (non-relevant processing steps are shaded):

Figure 7: Real time zone file distribution - a process view

What happens in the DNS Master to Slave Server zone file distribution process as illustrated above is:

Upon having updated its local zone file and journal, the Master DNS Server (master) sends out a notify message, according to RFC1996, which instructs the Slave DNS Serves (slave) to initiate an immediate refresh of the zone.

The slave contacts the master server to get the current SOA record. If the serial number of the returned record is greater than that held on the slave, the slave would send out an IXFR request (as per RFC1995) to the master, with the serial number of its zone file in the request.

The master takes the two serial numbers and consults the journal to determine the necessary changes - if it doesn't have enough information, it will send a full zone transfer. If it has history information for all changes between the two serials, it can send an IXFR consisting of only the changed records.

Each slave, once it has performed a zone transfer, will in turn send out a notify, ensuring that if a packet is lost, multiple backup lines of communication will handle it.

In addition to this process triggered the DNS Notify message, the “refresh" value defined by the SOA record defines a timer, and when this timer is reset the same zone file distribution process is triggered. This timer mechanism prevents any two servers from being more than two hours, or whatever interval has been set, out at any time. A typical SOA might look like this:

name SOA ns1.nic.name. hostmaster.nic.name. (

200206010 ; Serial number

7200 ; Refresh

3600 ; Retry

86400 ; Expire

300 ; Negative cache

)

This negative cache value ensures that the near real-time updates will be found promptly by the resolving client.

Figure 8: Periodical zone file distribution - a process view

Frequency

The distribution of zone file updates is a continuous process triggered by the masters sending of DNS Notify messages. Under normal conditions, when any slave DNS server receives a DNS Notify message from the Master, it immediately triggers an update which synchronizes the slave with the Master.

Security and authentication

As is the case for what has been called the zone file generation process in the previous chapter, the distribution process is also secured by a number of means. The public query interface provided by the cluster of Slave DNS Servers is available only through a firewall, and any attempts on intrusion or blocking through (distributed) Denial Of Service attacks or other commonly known hacking patterns will be detected by intrusion detection systems which will take action. For a fuller description of the security precautions taken see chapter C17.9.

The Master DNS Server and the Slave DNS Servers use TSIG verification for the IXFR to ensure appropriate security and consistency. In particular, the signature with TSIG guarantees that no tampering has taken place during transmission. This is the same point-to-point authentication and integrity checking mechanism that is used for the MQ2DNS to Master DNS Server communication.

This prevents any one process but the Master DNS Server to update the Slave DNS Servers.

C17.6. Billing and collection systems.

This section details Global Name Registry’s billing capabilities both in terms of processes and accounting, and also further describes the Billing systems briefly presented in C17.1.

C17.6. Billing and collection systems.50

Global Name Registry billing and VAT Classification. 50

Overview of billing systems52

Mapping components to hardware – Deployment view of the Billing system. 54

The billing process – a process view of the Billing system. 55

Accessibility and Reporting. 58

Increasing credits and adding accounts58

Reporting to Registrars58

System security58

Basic Billing rules in the System. 58

Deferred revenue calculation. 59

VAT calculation and VAT information. 60

Global Name Registry billing and VAT Classification

When Global Name Registry launched the gTLD .name Registry in January 2002, it was the only company in the UK providing such supply. The gTLD operation was not an established category with the UK Customs, and as part of its preparations of the billing systems and processes, Global Name Registry desired to clarify the tax and VAT implications of its supply in advance to ensure correct, consistent and legal billing of its operations, including billing to Registrars.

With the assistance of its accounting firm, PricewaterhouseCoopers, Global Name Registry obtained advice on the proper classification from UK Customs and is now adequately classified for billing of gTLD operations according to UK VAT rules.

The letter on the following page is from UK Customs and demonstrates the advice on the Global Name Registry billing classification:

Overview of billing systems

The figure below illustrates the Billing system at a high-level view.

Figure 9: High-level system view for Billing

The Financial Controller is an employee of Global Name Registry who administers Registrar’s accounts and the billing of Registrars. He/she has an interface to the Authorative Registry Database where handling and editing of Registrar’s accounts can be done. This interface is offered by the Registrar Account Administration. The Financial Controller updates the balance of the Registrar’s account in the Registry System through this interface each time the Registry’s bank notifies him/her that funds have been received.

The Core SRS is an essential part of the Billing system because the Core SRS holds the accounts, Reporting Database, from which billing information is polled and debits of accounts are processed in the case of a billable operation.

The Registrar Account Info enables the Registrar to access the billing information and account status through a secure WWW interface, and request the information needed, or download an FTP file from an FTP server at UK main site. The support team, key account manager and accountants are also available as telephone support for this purpose, should extra information be needed.

The Financial System an off-the-shelf application, SAGE 100 from SAGE ltd. SAGE i.a. fetches statements and data from the Bank.

Each Registrar has a credit limit of $1000. This allows the Registrar balance to go negative, until a minimum of $1000 is reached, after which further billable operations will be denied. The negative balance has been granted by Global Name Registry to each Registrar to buffer away any unexpected fluctuations that otherwise would restrict the Registrar’s operations.

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

· An accountant generates a list of all Registrars, with the number of domain names registered during the corresponding month. For each Registrar, a list of every domain registered for this billing period will be included.

· Summary data goes into the financial system, SAGE 100, and invoices are generated, printed out and sent by email.

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 implement such controls as are necessary to ensure that no errors are made.

Mapping components to hardware – Deployment view of the Billing system

The figure below presents the components in the Billing System.

Figure 10: Deployment view of the Billing package

The Reporting Database in Core SRS offers an interface to the Account Info Generator, which is polling account and billing information from the Reporting Database. Account Info Generator generates reports to the Financial Controller and files with the Registrar’s account status and billing information. These files are pushed to an FTP server through the FTP Server IF, and to a WWW server through the WWW Server IF. Registrars can then access account information by downloading the file from the FTP server, or using a web-browser.

The communication between the Billing system and the Reporting Database in Core SRS runs over the secure internal Global Name Registry network. The Registrar inquiry goes via the WWW-interface, or the FTP server. The WWW session can be encrypted with SSL, at the Registrar’s option. The FTP file retrieved can be encrypted with the Registrar’s PGP key, at the Registrar’s option.

The billing process – a process view of the Billing system

In the two subsequent figures on the following pages the process of billing in relation to a billable operation are shown.

Figure 11: The Billing process in accomplishment of a billable operation

Figure 12: The Billing, debit process

The figure below illustrates the process of crediting an account.

Figure 13: The Billing, credit process

Accessibility and Reporting

Increasing credits and adding accounts

The Financial Controller has an interface to the Authorative Registry Database, where he/she can manually modify Registrar’s accounts, if needed. Adding and removing accounts has to be done manually, as well as modifying account information

Reporting to Registrars

Registrars can access information about their Registry account in two ways: downloading account information from an FTP server, or using a WWW interface where balance, transactions and statements are available.

System security

The only interface for changing the SRS credit information is held by the Financial Controller. The credit information can only be updated from one particular location in the Global Name Registry offices on a secure network. This secures the SRS credit information and ensures that no unauthorized changes to Registrar balances can be made.

The bank interface to SAGE is secure and encrypted with software and processes from Barclays Bank plc.

The Registrar WWW interface is running over SSL and is therefore reasonably secure. Balances can not be updated in the WWW interfaces, and it only offers reading of account information and transactions. Should the Registrar compromise its password to the www interface, it can be promptly changed by the Global Name Registry Customer Support Team.

Employees are trained and followed up on security compliance. This is described in more detail in Section C17.9

Basic Billing rules in the System

Global Name Registrys current billing system operate accounts for the registrars as follows:

· Registrar’s accounts start at 0, but all Registrars have a credit limit, and all Registrars have the same credit limit. This credit limit is currently 1000 USD. This allows Registrars to overdraw their accounts up to 1000 USD in the case. Global Name Registry grants this credit to Registrars in an attempt to reduce failed billable operations as a result of problems with fund transfers etc, but do not encourage Registrars to use it intentionally.

· For the purpose of .org operations, billable operations are described in Sections C25-C27.

· Should the account balance reach the credit limit, further billable operations will be denied.

· Any billable operation will reduce the balance.

· Any refund will increase the balance.

· Manual adjustments can be made by Global Name Registry Financial Controller(s) to increase the balance whenever a Registrar pays Global Name Registry, or to reduce the balance whenever a Registrar requests money back. Manual adjustments can also be applied for other reasons.

· Manual adjustments generate entries for all relevant audit tables in the Registry.

· All manual adjustments must include a field for free text description to describe the reason for the manual adjustment. This aids tracking and auditing of transactions.

· Grace periods are implemented as described in Section C17.3

Deferred revenue calculation

· Each billable transaction has a start-date and end-date

· Start date must be set to the current date at the time of the transaction except for renewals, where start-date must be set to the start of the renewed period. For example, if a domain is to expire at March 13th 2002, and is subsequently renewed for one year, the start-date is March 13th 2002, and the end date is Marc 13th 2003, regardless of the date the transaction actually occurred.

· End date must be set to the start-date + period of registration. For example: If the start date is April 5th 2002, and the period is 5 years, the end date should be set to April 5th 2007.

· Due to the expiration-date policies in the Registry, end dates may be truncated if the expiry date would have ended up more than 10 years (but less than 11 years) into the future. (As explained in the Section C17.3, transactions that seek to set the expiry date to more than 11 years in the future will be denied)

· "Period" should be taken to mean the amount of time (in days) that was bought with the transaction.

· Refunds as a result of delete during the applicable grace period(s) must also have start and end-dates set after the same rule. Example: If the start date original transaction was April 5th 2002 for 5 years, and the delete happened on April 8th 2002, the start date of the refund transaction should be April 8th 2002, and the end-date April 8th 2007.

VAT calculation and VAT information

The following rules apply for VAT codes and VAT calculation:

TAX CODE	VAT	COUNTRY	COMMENT
VAT_UK	17.50%	UK only	VAT number optional
VAT_UK_EU	17.50%	EU except the UK	VAT number has not been supplied
VAT_EU	0.00%	Any EU country	VAT number must be supplied
VAT_NONEU	0.00%	Any non-EU country	VAT number is optional

When working out the VAT per unit, the amounts of VAT is worked out to 4 digits after the decimal point and then rounded to 3 digits. For example, if the VAT is 0.0024, it is rounded to 0.002.

C17.7. Data escrow and backup.

Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.

C17.7. Data escrow and backup.61

Backup. 61

Overview. 61

Backup policy62

Tivoli Storage Manager Implementation. 63

Domains and Management Classes65

Storage Pools66

Schedules66

Administrative Schedules67

Procedures for taking tapes off-site. 67

Testing and QA of backup. 67

Backup agent contract/proposal68

Escrow. 68

Schedule for escrow deposits68

Escrow deposit format specification. 69

Distribution Of Public Keys.75

Escrow Transfer Procedure. 76

Escrow Verification Procedure. 76

Escrow Retrieval And Rebuild Procedure. 77

Escrow Agent Proposal78

Backup

Overview

The backup solution in use by Global Name Registry consists of a central backup server, software installed on the server and on all clients where data is taken from, as well as a tape library robot connected to the backup server. The diagram on the following page illustrates the backup solution:

Figure 14: Backup solution overview

The backup jobs run every 24 hours, and writes all files that shall be backed up to the Backup Server (IBM RS6000), after which the backup is written to tape by the tape robot holding more than 2TB of tape storage.

The TSM solution is based on a Network Storage Manager package sold by IBM. The solution is comprised of an IBM H70 running AIX 4.3.3 and a SCSI attached 3583 library with two LTO drives. The IBM hardware was delivered with AIX 4.3.3 and TSM 4.1.3.0 pre-installed. Sagitta carried out the physical installation and implemented the configuration.

Backup policy

The data backed up includes all data which is not part of the base build or application build. All data changed or added by applications is backed up. The following illustrates this backup policy:

Figure 15: All application data is backed up

The backed up data is therefore all the data necessary to reconstitute the Registry at one single point in time. All the non-backed up data are standard server builds and software that can be reinstalled from ESS or CDs by the Operations team.

Backup of the main database is stored on tape, but Global Name Registry is also holding at least two backups of the database on harddisk storage. This is in order to ease and speed up retrieval should restoration of the database be necessary.

The backup solution can back up a data volume filling its entire tape library of 2.3TB in less than 24 hours. With its current operations of about 140,000 domain names and .name email addresses, the full backup volume is around 200GB and is completed in less than 2 hours. Global Name Registry believes that the current backup solution is sufficient to back up the entire .org database in addition to the .name database (see Section C17.3 for the database sizing discussion), but should the backup volume grow to a level where full backups take more than 16 hours, Global Name Registry will add additional backup units to share the backup volume evenly between units. This can be easily handled by the Tivoli Backup Manager software.

Tivoli Storage Manager Implementation

Tivoli Storage Manager has been employed to provide automated backup and recovery for the Global Name Registry (GNR) Linux environment. All TSM clients serviced by the TSM server are doing LAN based backups and restores. All backups are flatfile backups.

A detailed listing of all configuration information completed on the TSM server can be found at appendix A and appendix B.

Backup overview

Figure 16:Diagram of the dataflow

During a backup cycle, the TSM server based on its predefined schedules will poll the TSM client to begin its backup. The characteristics of the backup are defined on the server, hence the server tells the client what should be backed up. The start of each backup will depend on the availability of the clients and balancing of the backup load on the TSM server.

Referring to the number 1 on the Figure above, user data (flatfiles) clients will backup across the LAN to the disk storage pool on the TSM server. Once backups has completed, data is migrated from disk to tape by the TSM server (number 2). Once the migration has completed, all data is copied from tapes in the primary storage pool to tapes in the copy storage pool. This is done as part of the administrative tasks performed every day (see later section). Thus, two copies of all backed up data exist.

Domains and Management Classes

One TSM domain is defined on the TSM server. This domain contains one policyset with one management class. See figure below for an overview.

Figure 17:Domain, Management Classes, Copygroup and storage pool structure

All clients are defined to the GNRDOM TSM domain. All backups end up in the DISKPOOL disk storage pool, which effectively means that all backups are backed up to disk. As the disk storage pool fills up, data is migrated to the LTOPOOL tape storage pool. Later all data in the LTOPOOL is copied to the COPYPOOL tape storage pool. Tapes belonging to the COPYPOOL should be taken off-site on a weekly basis.

The properties for the standard copy group in the default management class of the GNRDOM domain are:

· Versions exist: 3

· Versions deleted: 2

· Retain extra version: 180

· Retain only version: No Limit

Storage Pools

Storage pools are the management units that TSM uses to manage the data. Different types of data are assigned to different Storage pools, for easier collective management. There are two types of storage pools:

· Primary storage pool. Main storage pools are where the data is held and managed. A primary storage pool can be on either disk or tape.

· Copy storage pool. A storage pool, which is a complete duplicate of a primary storage pool. You can have a one to one relationship or a many to one relationship

The TSM client systems are backing up all flatfile data to primary disk storage pools defined on the TSM server and later migrated to tape. The primary storage pools are backed up to copy storage pools. Copying from primary to copy storage pools is done as part of the daily administrative tasks (see next section).

Schedules

A number of schedules are running on the TSM server. These are either client schedules that deal with client data backups or administrative schedules that perform several administrative tasks on the TSM server, e.g. TSM DB backup and copying of data from primary storage pools to copy storage pools.

Client Schedules

One client schedule is currently running on the TSM server. That is

DAILY_INCR, runs every day at 01:00. The schedule performs an incremental backup of all associated nodes.

Administrative Schedules

Three administrative schedules are running on the TSM server. They are

· start_admin_tasks, runs every day at 03:00. The schedule runs the TSM server script start_admin_tasks. This script verifies that all client backups have completed. Once that has happened, the start_admin_tasks script kicks off the do_admin_tasks script, which in turns does the migration from disk pool to tape pool, backs up the primary storage pool to the copy storage pool, backs up the TSM DB backup and expire inventory. A printout of all TSM server scripts can be found at appendix B.

· run_copypool_space_reclaim, runs every Saturday at 07:00. The schedule runs the TSM server script do_space_reclaimation with the argument copypool (do_space_reclaimation is a generic script, that will do space reclamation on the storage pool named by the argument passed to the script).

· run_ltopool_space_reclaim, runs every Saturday at 11:00. The schedule runs the TSM server script do_space_reclaimation with the argument ltopool.

Procedures for taking tapes off-site

All procedures for taking tape to an off-site location and bringing tapes back from the off-site location must be handled manually.

The scripts implemented on the TSM server will handle all preparation (TSM database backups and creation of copy storage pool volumes). But it is the TSM administrator responsibility to identify the volumes that must be taken off-site and update the volumes access value according to their location. It is also the TSM administrator responsibility to trace all off-site volumes, including TSM database backups. An unsupported script has be provided to help identify volumes that should go off-site and volumes that should be returned to site, but this script only works for data volumes (and only if volume access is updated correctly as tapes are taken in and out of the library) and does not work for tapes containing TSM database backups.

For DR purposes, a copy of the devconfig.out and volhist.out files must also go off-site along with the TSM database backup. These two files are only a few kilobytes each, therefore the easiest way of taking the files off-site is to mail them to an off-site location or print them at a remote printer.

Testing and QA of backup

Global Name Registry regularly tests reconstruction from backup to ensure that backup systems, methods and processes work properly. This ensures that in the event a real backup restoration should be necessary, all systems and personnel will be primed to restore the data with no errors.

Backup agent contract/proposal

Please see appendix 14 for the Backup agent, IronMountain, contract for offsite tape storage. Also see appendix 13 for the Sagitta report on Global Name Registry backup installation.

Escrow

The Escrow software developed by Global Name Registry is running on an IBM350 server, with 4 processors, RAIDed disks, 3 separate power supplies, 4GB RAM. The server is configured according to standard Global Name Registry configurations. It runs Linux operating system which is custom hardened and secured by Global Name Registry engineers.

Schedule for escrow deposits

Full Deposit Schedule

Full Deposits consist of data that reflects the state of the registry as of 12:00 GMT (“Full Deposit Time”) on each Sunday. Pending transactions at that time (i.e. transactions that have not been committed to the Registry Database) are not reflected in the Full Deposit.

Full Deposits start, according to the transfer process described in this document, within a four-hour window beginning at 06:00 GMT (“Full Deposit Transfer Time”) on the following Monday. The time for transferring data will change during the ramp-up period to a start time that is related to the optimal bandwidth, within the 24 hour time limit from the Deposit Time on each Sunday. The escrow agent will be notified about the change within the time that Global Name Registry and the escrow agent agree upon.

Incremental Deposit Schedule

Incremental Deposits reflect database transactions made since the most recent Full or Incremental Deposit. The Incremental Deposit for Monday includes transactions completed that had not been committed to the Registry Database at the time the last Full Deposit was taken. Incremental Deposits on Tuesday through Saturday includes transactions completed by 12:00 GMT on the day of the deposit that were not reflected in the immediately prior Incremental Deposit.

Incremental Deposits will start, according to the transfer process described in this document, within a four-hour window beginning at GMT on following day. The time for transferring data will change during the ramp-up period to a start time that is related to the optimal bandwidth, within 24 hours time limit from 06:00 GMT on each day, the Incremental Deposit will be made. The escrow agent will be notified about the change within the time that Global Name Registry and the escrow agent agree upon.

Escrow deposit format specification

This format is subject to change by agreement of Global Name Registry and ICANN as well as during the IETF standards process. In addition, Global Name Registry will implement changes to this format as specified by ICANN to conform to the IETF provreg working group’s protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard (RFC 2026, section 4.1.1).

Each Full and Incremental Deposit consists of a series of files that are generated in the Escrow Process.

Full Deposit Contents

The reports involved in a Full Deposit for .org will include, but not be limited to:

· Registrar Object Report - this will detail the contents of known registrars in the Registry Database.

· Domain Object Report - this will detail the contents of valid domains in the Registry Database

· Contacts Object Report - this will detail active contacts within the Registry Database

· Nameserver Object Report - this will detail all known nameservers within the Registry Database

Incremental Deposit Contents.

This will solely consist of a transaction report. The transaction report will detail the contents of all transactions records included in the Incremental Deposit.

Format of the Reports.

All reports are to be formatted in XML format. In compliance with the XML 1.0 specification, certain characters in the data must be "escaped", as described in item “Escape-Character Requirements” below. Each Report shall then be prepared according to the general XML format described in subsequent items below. Item “The Report Container” describes the report container that is common to all reports. Subsequent items describe the structure of the contents of the report container for each of the specific reports. The format of the reports may be amended or changed upon 90 days notice if the database structure or number or structure of objects change.

In compliance with the XML 1.0 specification, the following characters in any escrowed data elements must be replaced with the corresponding escape sequences listed here:

Character	Escape Sequence
"	"
&	&
'	'
<	<
>	&gt

The Escrow Container. At its highest level, the XML format consists of an escrow container with header attributes followed by escrow data.

Attributes:
Tld – the name of the top level domain
Date – date of the escrow export
Report – type of data contained in the escrow container
Type – type of export (Full or Incremental)
Version – version number of the escrow

Elements:
Registrar - container for registrar data
Domain – container for domain data
Nameserver – container for nameserver data
Contact – container for contact data
Transaction – container for transaction data

E.g. an example escrow container may have the following :

<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "org-escrow-export.dtd" >
<escrow tld="org" date="1-jan-2003 3:15:00AM" report="domain" type="Full" version="1.0" >

{Here is where the report containing the actual data being escrowed is placed. It contains one element for each object of the type (domain, SLD email, nameserver, contact, registrar, defensive registration, namewatch or transaction) covered by the report. The specific format for each report is described in the items below.}

</escrow>

The Registrar Element. The registrar element is a container consisting of the following data:

Attributes:
ID – unique identifier for this object type (corresponding to an entry in the IANA registrar-id database)
Status – the current status of the Registrar Element

Elements:
ContactID – contact point of registrar
URL – the home page for the company
Created - timestamp detailing when this record was created
Modified - timestamp detailing when this record was last altered

E.g. an example registrar container may have the following :

<url>www.acmeregistrar.co.uk</url>

</registrar>

The Domain Element. This element will be a container holding the following data:

Attributes:
ID - unique identifier for this object type
FQDN - Fully Qualified Domain Name
Status - the current position of the domain

Elements:
RegistrarID - the identifier for the registrar within the Registry Database
Created - the timestamp detailing when this record came into existence
Expires - when the active status of the domain will expire
Modified - the timestamp stating when this record was last altered
NameServerID - up to 13 different nameservers for this particular domain record
ContactID - up to 4 different types of contact id for this particular domain record

E.g. an example domain container may have the following :

</domain>

The Nameserver Element. This element consists of the following data:

Attributes:
ID - unique identifier for this object type
FQDN - Fully Qualified Domain Name for the nameserver
Status - current standing

Elements:
RegistrarID - the identifier for the registrar within the Registry Database
Created - timestamp detailing when this record was created
Modified - timestamp detailing when this record was last altered
Ipaddress - up to 13 unique IP addresses for each nameserver

E.g. an example nameserver container may have the following :

</nameserver>

The Contact Element. The contact element is a container consisting of the following data:

Attributes:
ID – unique identifier for this object type
Status - current standing

Elements:
Name - the name of the contact
RegistrarID- the sponsoring registrar for this record
Address - a free form field for the address of the contact
City - the town or city where the contact resides
State/Province - the state/province where the contact resides
Country - the country for this contact point
PostCode - the postal code where the contact resides
Telephone - the voice telephone number for this contact
Fax - a facsimile number for this contact
Email - an electronic address to reach the contact by
Created - timestamp detailing when this record was created
Modified - the timestamp detailing the time of the last update

E.g. an example contact container may have the following :

<name>John Smith</name>

<address>32, Hill Avenue</address>

<state>Beluga</state>

<emailaddress>john@smith.name</emailaddress>

</contact>

The Transaction Element. This element consists of the following data:

Attributes:
ID – unique identifier for this object type
Type - the action which was performed

Elements:
RegistrarID - the identifier for the registrar performing the update within the Registry Database
Object - the identifier to the object with the Registry Database
Timestamp - the time of the transaction within the database, and the moment this record came into existence

E.g. a transaction container may hold the following data :

</transaction>

DTD for escrow files

The following section illustrates the DTD for validating Escrow files.

<?xml version="1.0" encoding='UTF-8' ?>

<!ELEMENT escrow (registrar*, domain*, nameserver*,

contact*, transaction*)>

<!ATTLIST escrow

tld NMTOKEN #FIXED 'name'

date CDATA #REQUIRED

report (domain | nameserver | contact

| registrar | transaction) #REQUIRED

type (Full | Incremental) #REQUIRED

version CDATA #FIXED '1.0'>

<!ELEMENT registrar (contactid, url, created, modified)>

<!ATTLIST registrar

id CDATA #REQUIRED

status (inactive | ok) #REQUIRED>

<!ELEMENT domain (registrarid, created, expires, modified,

nameserverid*, contactid+)>

<!ATTLIST domain

id CDATA #REQUIRED

fqdn CDATA #REQUIRED

status (clientDeleteProhibited | clientHold

| clientRenewProhibited | clientTransferProhibited |

clientUpdateProhibited | inactive | ok | pendingDelete

| pendingTransfer | pendingVerification |

serverDeleteProhibited | serverHold

| serverRenewProhibited | serverTransferProhibited |

serverUpdateProhibited) #REQUIRED>

<!ELEMENT nameserver (registrarid, created, modified, ipaddress+)>

<!ATTLIST nameserver

id CDATA #REQUIRED

fqdn CDATA #REQUIRED

status (clientDeleteProhibited | clientUpdateProhibited

| linked | ok | pendingDelete |

pendingTransfer | serverDeleteProhibited

| serverUpdateProhibited) #REQUIRED>

<!ELEMENT contact (name, registrarid, address, city, state,

country, postcode, telephone, fax,

emailaddress, created, modified)>

<!ATTLIST contact

id CDATA #REQUIRED

status (clientDeleteProhibited | clientTransferProhibited

| clientUpdateProhibited | linked | ok |

pendingDelete | pendingTransfer | serverDeleteProhibited

| serverTransferProhibited |

serverUpdateProhibited) #REQUIRED>

<!ELEMENT transaction (registrarid, object, timestamp*)>

<!ATTLIST transaction

id CDATA #REQUIRED

type (INSERT | DELETE | TRANSFER | UPDATE) #REQUIRED>

<!ELEMENT name (#PCDATA)>

<!ELEMENT address (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT state (#PCDATA)>

<!ELEMENT country (#PCDATA)>

<!ELEMENT postcode (#PCDATA)>

<!ELEMENT telephone (#PCDATA)>

<!ELEMENT url (#PCDATA)>

<!ELEMENT created (#PCDATA)>

<!ELEMENT modified (#PCDATA)>

<!ELEMENT expires (#PCDATA)>

<!ELEMENT registrarid (#PCDATA)>

<!ELEMENT nameserverid (#PCDATA)>

<!ELEMENT forward (#PCDATA)>

<!ELEMENT ipaddress (#PCDATA)>

<!ELEMENT fax (#PCDATA)>

<!ELEMENT emailaddress (#PCDATA)>

<!ELEMENT report EMPTY>

<!ATTLIST report

type (DAILY|WEEKLY|MONTHLY) #REQUIRED>

<!ELEMENT string (#PCDATA)>

<!ELEMENT wildcard EMPTY>

<!ATTLIST wildcard

type (STARTS_WITH|CONTAINS|ENDS_WITH) #REQUIRED>

<!ELEMENT object (#PCDATA)>

<!ATTLIST object

type (DOMAIN | EMAIL | NAMESERVER |

CONTACT | NAMEWATCH | DEFREG) #REQUIRED>

<!ELEMENT timestamp (#PCDATA)>

Distribution Of Public Keys.

Each of Global Name Registry and escrow agent will distribute its public key to the other party (Global Name Registry or escrow agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party's public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow agent and ICANN shall exchange keys by the same procedure.

Escrow Transfer Procedure

Global Name Registry shall prepare and transfer the Deposit file by the following steps, in sequence:

1. The files making up the Deposit will first be generated according to the format specification. (See above, "Escrow Deposit Format Specification").

2. The Reports making up the Deposit will be concatenated. The resulting file shall be named according to the following format: "orgSEQN", where "SEQN" is a four digit decimal number that is incremented as each report is prepared.

3. Next the Deposit file will be processed by a program (provided by ICANN) that will verify that it complies with the format specification and contains reports of the same date/time (for a Full Deposit), count the number of objects of the various types in the Deposit, and append to the file a report of the program's results.

4. Global Name Registry may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 640MB each (except the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM or equivalent) must be included with the split files to isolate errors in case of transfer fault.

5. Thereafter encrypt the files using escrow agent's public key for PGP and signed using Registry Operator’s private key for PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. The file will be named in the form <TLD>CCYYMMDD.PGP (e.g. org20030810.PGP). (Note that PGP compresses the Deposit file(s) in addition to encrypting it (them).)

6. The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous file transfer, e-mail, or similar, which will be agreed by Global Name Registry and the escrow agent, starting within the specified time window. Global Name Registry appreciates that after a certain period of time, the size of the files requiring transfer to escrow may exceed a size that will be safe for electronic transmission. At that time manual procedures will be developed to ensure that the escrow transfer obligations of the Registry continue to be complied with.

Escrow Verification Procedure

Escrow agent will verify the format and completeness of each Deposit by the following steps:

1. When the transfer is done, all Deposit files will be moved to a not-publicly-accessible directory and the existence and size of each will be noted.

2. Each Deposit file will be decrypted using escrow agent's private key for PGP and authenticated using Registry Operator’s public key for PGP. The PGP software will additionally decompress the data therein.

3. If there are multiple files, they will be concatenated in sequence.

4. The escrow agent will run a program on the Deposit file (without report) that will split it into its constituent reports (including the format report prepared by Global Name Registry and appended to the Deposit) check its format, count the number of objects of each type, and verify that the data set is internally consistent. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. The program will encrypt the report using ICANN's public key for PGP and signed using escrow agent's private key for PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024 – byte length. (Note that PGP compresses the Deposit file(s) in addition to encrypting it (them).)

5. The decrypted Deposit file will be destroyed and the database dropped to reduce likelihood of data loss to intruders in case of partial security failure.

Escrow Retrieval And Rebuild Procedure

It is important to realize that reconstructing the Registry, any Registry, from an Escrow file, is likely to require good knowledge about the Registry data model and database structure. If this is the case, ICANN, a designated recipient or Global Name Registry can retrieve the Registry and rebuild from Escrow according to the following procedure:

1. Each of the latest Deposit file(s) will be retrieved from the Escrow agent through FTP download or by courier of an optical medium, whichever format was used to originally deposit the Deposit File(s)

2. Each Deposit file will be decrypted using either the escrow agent's private key for PGP or Global Name Registry’s private key for PGP. The PGP software will additionally decompress the data therein.

3. If there are multiple files, they will be concatenated in sequence to reconstitute the entire XML Escrow file.

4. The Escrow file will be validated with the Escrow File DTD specified in this document. Any errors at this point are unlikely, and must be investigated manually.

5. Global Name Registry will parse the Escrow file using the XML parser Xerces.

6. After the parsed information is available, based on the object type (domain, contact, nameserver), a script will generate an appropriate SQL statement and insert the information directly into the database, which structure is identical to the database from which the Escrow was taken, using Global Name Registry database schemas. Alternatively, Global Name Registry has the option of generating an EPP command from the parsed information and passing it through the EPP servers. This would be far slower than the direct database approach, the latter which is preferred.

7. The auth-info token(s) and the object history (past transfers, past operations on the object) is not included in the Escrow specification and will not be part of the rebuild. However, this will not preclude restored operations but means that Registrars will have to re-set their Auth-info tokens and that the object history will have to be regenerated from another source.

8. The database can be subjected to Quality Assurance after which it can be put into production.

Escrow Agent Proposal

The Escrow agent procedure is illustrated in the figure below:

Figure 18: Escrow agent procedure

The Escrow Agent Proposal and Contract is listed in Appendices 10 and 11 to this proposal.

C17.8 Publicly accessible look up/Whois service

This Section’s first part documents the Global Name Registry Whois from a technical point of view, by looking into its functionality, mapping the functionality to the hardware run, and looking at the Whois interfaces and their functionality. The second part of this Section describes the proposed Whois policies, returned results and otherwise issues that belong more in the policy arena than the technical arena.

C17.8 Publicly accessible look up/Whois service. 79

Technical functioning of the Whois79

Deployment of the Whois Service. 81

Port 43 Whois service. 83

Web-based Whois service. 85

Hardware. 87

Software. 87

Security and reliability87

Whois policy and Format of responses88

Modifiers88

Returned Whois Results88

Data format policies92

Technical functioning of the Whois

The Global Name Registry WHOIS service is able to handle a sustained and significant load. The available WHOIS servers are distributed at the regional sites on a high availability active/passive load balanced failover system. New servers can be easily added. Currently, there are four Whois servers in operation to fulfil the service volumes. Peak capacities are described in more detail in Section C17.10.

The Whois system has been designed for robustness, availability and performance. Detection of abusive usage, like excessive numbers of queries from one source, has been taken into account, and other countermeasures against abuse will be activated if necessary.

The WHOIS service will only give replies for exact matches of the object ID. Search capabilities beyond this will be implemented should the policy development allow it.

The Global Name Registry Whois system operates independently of other Whois systems. In the .org context it is proposed that all clients requesting Whois queries for .org domains will only need to utilize the Global Name Registry Whois system. This is related to the migration Global Name Registry proposes from a “thin” .org Registry to a “thick” .org Registry. This transition is described in more detail in Section C18 and C17.3. A thick .org Registry will allow Whois to be centralized and take the inconveniences of a fragmented Whois away.

This section is only describing the services that Whois offers to the public clients. The updates of the Whois servers are described in section C17.1. Except in the figure below; subsystems, packages or components only related to the publicly accessible look-up will be presented in this section.

Figure 19: Overview of the Whois system

The figure above is an overview of the Whois service and the systems of which the service is constituted. The Whois Public Interface has a Whois database consisting all Whois entries and offers a public interface to the Whois database for look-ups through a port 43 interface accessible via UNIX commands like fwhois, and a web-interface.

In addition, the Whois System generates an Escrow file for the purpose of Appendix P (“Whois provider Data Specification”) to the Registry Contract. The Whois Escrow does not offer any public service, and will therefore not be described here. Please see Section C17.1 for a description of the Whois Escrow.

Global Name Registry has developed a custom database for the operations of Whois. The database developed is optimized for the type of requests that is served by Whois and greatly improves the Whois single-server performance compared to other designs. More details on the performance of the Global Name Registry Whois database can be found in Section C17.10.

Deployment of the Whois Service

The figure on the following page presents the use of the Whois resolving services by a deployment diagram. The diagram shows a client executing a Whois request, and the message flow between components deployed to hardware. The Whois Server and WWW-Whois Server are located at regional sites, and are both a part of the Whois Public Interface System, presented in the figure above.

Figure 20: Deployment diagram for the Public accessible Look up

The Whois service is compliant with RFC 954. It substantially consists of two parts:

· Port 43 Whois services

· Web-based Whois services

These two services, functionally similar but operating on two different interfaces and therefore slightly varying, are described in the following

Port 43 Whois service

When a client makes a Whois query through port 43, one of the regional Whois servers are invoked.

Component descriptions

Rate controller: The rate controller controls the number of queries from one client and is able to detect and limit abusive usage, like excessive numbers of queries from one source. It will then block the source.

The Whois logic basically processes the queries towards the Whois database. The output data of the query is determined by modifiers given in the query (see the ‘Whois Policy and Format of Responses’ section below for more about modifiers). The Whois logic also processes queries clients do towards the Web-based Whois interface.

The response of any request may be an error or a successful query. If an error occurs, the service uses different error messages, depending on the severity and cause of the error. The service will send a message describing the error, the reason for the failure, and possibly an explanation of how to solve the problem. Error handling is in the Whois Services handled by the Whois logic.

In the Whois Database, at each site, all object required for Whois are stored. There are 4 object types in the Whois Database:

· Domain

· Contact

· Nameserver

· Registrar

Whois Log logs all queries processed in the Whois Database, and offers an interface to the Reporting System and the Monitoring System (see Section C17.1). Due to requirements of reporting of the Whois service activity, the Whois Log has a logic, which each night analyzes the log for the last 24 hours. Queries from port 43 and the web-based interface are logged separately.

Control flow

The figure below illustrates the control flow in a Whois query through port 43.

Figure 21: Control flow for a port 43 Whois look-up.

Send query result to client indicates a response which can be both an error message or returned data.

Web-based Whois service

The Web-based Whois service is a Web-based interface to the port 43 Whois service, utilizing the services and components at the Whois server.

Component descriptions

Rate controller: see description in relation to port 43 Whois service.

The WWW-Whois logic contains a CGI script, which has responsibilities to make queries to the Whois server in case of public look-ups. The WWW-Whois determines to which Whois server the query are to be sent, and on which port as well. Extensive queries are sent using a different port than the regular queries, which are sent using port 43.

Extensive Whois queries can only be requested from the WWW-Whois server, and the WWW-Whois server uses the Whois server to process the requests. Information of the requestor is required when performing an extensive lookup (see section about Whois policy and format of responses), which is logged separately. The CGI in WWW-Whois logic are requesting on TCP port 43 on regular look-ups, while another TCP port is used on extensive queries. Returned data from an extensive query is sent by email to the email-address given by the requestor.

WWW-Whois log logs all Web-requests. Information given by the requestor in relation to an extensive query is logged in a separate file.

Control flow

The figure on the following page illustrates the control flow in a Whois query through the Web-based Whois service.

Figure 22: Whois look up through the Web-based interface

Hardware

Specifications:

· Dual Pentium III 1 Ghz processor

· 1 GB Ram

· 100 Mbit switched connection

· 2 double network cards (both internal and external)

This hardware performs extremely well on the custom database Whois software developed by Global Name Registry. It also has the extreme advantage of being horizontally scalable at low cost. For performance of the Whois service, please see Section C17.10.

Software

The Whois service runs on Linux OS.

Security and reliability

The Whois service has been through thorough testing to prevent attempts of denial-of-service and distributed denial-of service.

There are firewalls and load balancers in an active/passive configuration in front of the Whois servers and WWW-Whois servers. This configuration provides a possible failover. All servers contains all objects and records, so if one goes down, queries are routed to another server. The Whois service is easy scalable due to the Update Handler. By adding servers, the performance increases linearly (see Section C17.10).

Whois policy and Format of responses

Modifiers

A modifier can be applied to the Whois query, which determines the amount of data of the requested object returned. The table below present types of modifiers valid for public accessible look-ups, and the amount of data returned of requested objects.

Query type/ modifier	~	None	=
Domain	Summary	Detailed	Detailed
Contact	Summary	Standard	Detailed
Nameserver	Summary	Standard	Detailed
Registrar	Summary	Standard	Detailed

Table 1: Query types and modifiers supported by the Whois service

Returned Whois Results

The subsequent tables describe the returned data from successful Whois queries. Global Name Registry supports public Whois with three modifiers; summary, standard and detailed results, as well as extensive Whois. As stated earlier in the section, public Whois can be requested through a port 43 interface, while the web-based interface supports all Whois requests.

The Whois results for an object owned by a Registrar which only supports RRP, will not have contacts associated and therefore no contacts will be displayed in Whois for this object until the Registrar moves to EPP. This transition is described in more detail in Section C22, C17.3 and C18.

Flags and Public/Extensive Whois fields:

· X - Field will always be output if data is available.

· O - Field is optional, and may not be displayed

· M - Field may be represented as multiple key/value pairs

Sections:

· M - Multiple sub-records may be displayed

If the data is not available, the key will not be displayed.

If the value is a handle, and the handle cannot be resolved in detailed queries, the actual handle will be displayed instead with a message telling that the rest of the data was not available.

The "flags" column applies to all output formats.

Domain record
			Public Whois			Extensive Whois
Section	Field name	Flags	Summary	Standard	Detailed	Extensive Whois
	Domain Name ID		X
	Domain Name			X	X	X
	Sponsoring Registrar				X	X
	Sponsoring Registrar ID			X
	Domain Status	M		X	X	X
	Registrant ID			X	X	X
	Registrant Organization	O			X	X
	Registrant Name				X	X
	Registrant Address				X	X
	Registrant City				X	X
	Registrant State/Province	O			X	X
	Registrant Country				X	X
	Registrant Postal Code	O			X	X
	Registrant Phone Number					X
	Registrant Fax Number	O				X
	Registrant Email					X
	Other names registered by registrant	OM				X
	Admin ID			X	X	X
	Admin Organization	O			X	X
	Admin Name				X	X
	Admin Address				X	X
	Admin City				X	X
	Admin State/Province	O			X	X
	Admin Country				X	X
	Admin Postal Code	O			X	X
	Admin Phone Number				X	X
	Admin Fax Number	O			X	X
	Admin Email				X	X
	Tech ID			X	X	X
	Tech Organization	O			X	X
	Tech Name				X	X
	Tech Address				X	X
	Tech City				X	X
	Tech State/Province	O			X	X
	Tech Country				X	X
	Tech Postal Code	O			X	X
	Tech Phone Number				X	X
	Tech Fax Number	O			X	X
	Tech Email				X	X
	Billing ID			X	X	X
	Billing Organization	O			X	X
	Billing Name				X	X
	Billing Address				X	X
	Billing City				X	X
	Billing State/Province	O			X	X
	Billing Country				X	X
	Billing Postal Code	O			X	X
	Billing Phone Number				X	X
	Billing Fax Number	O			X	X
	Billing Email				X	X
M	Name Server				X	X
M	Name Server ID			X
	Created On				X	X
	Expires On				X	X
	Updated On				X	X

Table 2: Returned data for the Domain object from Whois queries

Contact record
			Public Whois			Extensive Whois
Section	Field name	Flags	Summary	Standard	Detailed	Extensive Whois
	Contact ID		X	X	X	X
	Contact Name				X	X
	Contact Registrar				X	X
	Contact Registrar ID			X
	Contact Organization	O			X	X
	Contact Address				X	X
	Contact City				X	X
	Contact State/Province	O			X	X
	Contact Postal Code	O			X	X
	Contact Country				X	X
	Contact Email					X
	Contact Telephone					X
	Contact Fax					X
	Contact Status	OM			X	X
	Created On			X	X	X
	Updated On			X	X	X

Table 3: Returned data for the Contact object from Whois queries

Nameserver record
			Public Whois			Extensive Whois
Section	Field name	Flags	Summary	Standard	Detailed	Extensive Whois
	Name Server ID		X	X	X	N.A
	Name Server Name			X	X	N.A
	Name Server Registrar ID			X		N.A
	Name Server Registrar				X	N.A
	Name Server Status	M		X	X	N.A
	IP Address Associated	M		X	X	N.A
	Created On			X	X	N.A
	Updated On			X	X	N.A

Table 4: Returned data for the Nameserver object from Whois queries

Registrar record
			Public Whois			Extensive Whois
Section	Field name	Flags	Summary	Standard	Detailed	Extensive Whois
	Registrar ID		X	X