Figure C17.2.1: Peak Requirements

Registry Advantage will operate a Shared Registration System supporting RRP and EPP that provides registrars with the ability to register domain names; check on the status of a domain name; modify, delete, and renew existing registrations; and initiate the transfer of a domain name from another registrar.  All SRS functions are performed in real-time and result in an immediate update to the registry’s database.

Registry Advantage has significant experience implementing and operating registry-registrar models that utilize multi-protocol Shared Registration Systems. Currently, Registry Advantage provides its ccTLD registry clients and their registrars with an SRS that provides support for all types of registration transactions.  As will be the case with .org, the SRS supports multi-protocol access by registrars.  Currently, the system supports both Registry Advantage’s proprietary Simple Registration Protocol (SRP) and the Extensible Provisioning Protocol (EPP).  The SRP is similar in many respects to the Registry Registrar Protocol (RRP) that VeriSign uses for the legacy .org registry.  Registry Advantage has also benefited from the significant experience of its parent company, Register.com, in making use of the RRP to perform registrations.  Register.com has been using the RRP since June 1999 when it became the first live registrar to begin competing with Network Solutions.  Over the past three years, Register.com has performed billions of registration-related transactions using the RRP.  This experience has been directly translated into the robust SRS that Registry Advantage operates today.

Protocol

Access to the SRS will be provided through two protocols:  RRP and EPP.  The legacy RRP created by VeriSign is described in RFC 2832 [1] and provides a full set of SRS capabilities. The Extensible Provisioning Protocol (EPP) is the result of the IETF’s provreg working group and is described in a series of Internet-Drafts edited by Scott Hollenbeck.

RRP

Registry Advantage will provide an RRP interface to the Shared Registry System (SRS) throughout the transition period.  At the time of this proposal, VeriSign is contemplating a number of changes to the RRP, as described in an Internet-Draft written by Scott Hollenbeck [2] .  These changes include:

The adoption of these changes would result in the RRP version being updated to 2.0.0.  Registry Advantage will implement the same version of the RRP protocol as VeriSign expects to be using on December 31, 2002, and anticipates that this version is likely to be 2.0.0.  Both the current version (1.1.0) and proposed version (2.0.0) of VeriSign’s RRP are included as Attachment P1.

In addition to implementing protocol elements identical to those used within VeriSign’s SRS, DotOrg Foundation has duplicated many of the existing policies and procedures, such as those related to grace periods and transfers, used by the .org registry.  By providing registrars with consistency in both technical interface and business logic throughout the transition period, DotOrg Foundation intends to allow registrars to continue regular business operations with the least possible disruption due to the migration of registry operation.

EPP

In 2001, the Internet Engineer Task Force (IETF) formed a working group, known as provreg [3] , to create a generic registry-registrar protocol.  This working group has created a number of Internet drafts for the Extensible Provisioning Protocol (EPP), including one describing the requirements for a generic registry-registrar protocol and several others describing the core EPP protocol as well as specific domain, name server and contact object types. Registry Advantage strongly supports the creation of this standard, and has been an active participant in the standards process since the inception of the provreg working group.  Registry Advantage will provide an EPP interface for registrars from the inception of its SRS service, and will eventually discontinue the use of the legacy RRP protocol in favor of EPP.  As EPP is currently an evolving protocol, the specific version and details may be subject to change between the time of this proposal and the actual implementation, but the current candidate protocol is EPP-06/04 [4] .  Registry Advantage has currently implemented this version of the EPP drafts for use by its ccTLD registries.  Additionally, as required by ICANN, Registry Advantage will implement any version of EPP that reaches draft standard status within 135 days of achieving such status.

The current EPP drafts provide support for three types of objects:  domains, hosts (name servers) and contacts.  Due to the “thin” nature of the existing .org registry, social data is currently stored only by registrars and is not transmitted to the registry.  Consequently, Registry Advantage will initially support only domain and host objects within its EPP implementation.

Security

The Shared Registry System is designed to provide secure, reliable communications between registrars and the registry.  Several security checks will be applied in the early phases of each connection made to the SRS in order to prevent unauthorized access.  Interactive sessions will be conducted over SSL-secured network communications.  This prevents malicious third parties from intercepting communications between registrars and the registry.  Additionally, access to registry functions will be controlled by three mechanisms:

Username and password – Each registrar will be assigned a username and a password that they will keep secure.  The passwords will be stored in encrypted form, so that even the registry will not have access to all of the registrars’ passwords.  The password for each username will be changed on a periodic basis.

Client side SSL certificates – Each registrar will use a certificate with their registrar user name as the common name field.  The registry server will only accept certificates that are digitally signed by the registry.  (This differs from VeriSign’s practice of requiring that certificates be signed by a third party:  it eliminates some expense for registrars, and allows the registry to rely on the trusted relationship that it establishes with registrars as opposed to the generic verification policies utilized by third parties.)  At the time of signing, the registry will be able to validate that the person requesting the certificate does in fact represent the registrar who has been assigned that particular username.  In order to facilitate an easy transition for registrars, Registry Advantage will also continue to support certificates signed by VeriSign.

The registry server will only accept connections from a client when the username they log in as matches the common name in the certificate.

IP Address Filtering – The registry server will only permit logins from a restricted list of IP addresses.  Each registrar will have a list of IP addresses associated with it.  Although the IP addressees of all registrars will be able to access the registry’s network, a registrar will be prohibited from communicating with the Shared Registration System unless the connection originates from an IP address in the range assigned to that registrar.  In order to allow its clients to take advantage of redundant configuration or other special needs, the registry will permit multiple IP ranges per registrar.

Unlike the gTLD registry currently operated by VeriSign, which considers each of the security factors above independently, the proposed registry will only allow access to a registrar if all of the authentication factors match the specific registrar.  In other words, a registrar must connect using its particular username/password combination and its SSL certificate from its IP address.

These mechanisms will also be used to secure all web-based tools that will allow registrars to access the registry.  Additionally, all transactions in the registry (whether conducted by registrars or the registry’s own personnel) will be logged to ensure accountability and an appropriate audit trail.

Thick vs. Thin

Although Registry Advantage will initially operate a “thin” .org registry in the same manner that VeriSign does today, the registry will eventually be expanded to allow for a “thick” set of registry data.   This will be accomplished via a stable transition plan, described in Question C18.  Specifically, Registry Advantage will gather the following information that is not included in the current gTLD registry:

The thick registry model conveys several advantages.  First, a centralized source of public information such as a Whois database offers the Internet community a single resource with complete, standardized information about each domain name.  This is useful to a variety of interests– from technical contacts to intellectual property searches.  Second, registrars are not burdened by the necessity to maintain potentially costly Whois infrastructure, although they may choose to do so.  Third, a thick registry offers the opportunity to significantly streamline inter-registrar functions, such as transferring domains between registrars.  The registrar community is currently engaged in broad-ranging discussions regarding transfers and other issues, and DotOrg Foundation believes that the eventual outcome of those discussions will be invaluable in devising clear practices for both registries and registrars.  Registry Advantage expects that it will be able to leverage its thick registry model to provide more efficient services to registrars as a result of these discussions, and awaits the formation of a consensus by all involved parties.

A slightly different EPP implementation will be required during initial operation as a “thin” registry and later as a “thick” registry.  The principal difference is that the thin registry operation incorporates no social data.  EPP’s separation of registration events into domain, contact and name server objects makes this straightforward.  A thin registry simply does not allow for contact objects to be created or associated with domain names.  EPP also allows for migration of the registry from thin to thick.  In consultation with the DotOrg Foundation, Registry Advantage will manage the thin to thick migration by moving through several phases of EPP operation:

This process is described in detail in Question C22.

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.

Registry Advantage operates an Oracle database on a high availability cluster of Sun 6500 servers.  Common database packages ensure consistent handling of common events such as object creation and grace periods.

Registry Advantage has built a database infrastructure based on Oracle 8i running on Sun Enterprise 6500 servers.  The specific version of the Oracle database software is subject to change based on current software availability from Oracle, but version 8.1.7 is currently deployed in the Registry Advantage infrastructure.  Key features of Oracle include:

The database will initially be allocated approximately five hundred gigabytes (GB) of storage, with approximately three terabytes (TB) of additional storage available.  Based on an initial analysis of publicly available information regarding the current .org registry TLD data, even after performing a transition from a thin to thick registry, the .org registry would require less than 200 GB of storage, leaving a large amount of overhead for growth in the number of registrations or in the data associated with each domain name.  Additional storage is easily added to this environment—not only does the hardware support the addition of significant additional space, but Oracle also accommodates multiple storage devices and is capable of automatically splitting a single database over multiple devices.

The Registry Advantage database will easily be capable of providing adequate transaction processing for the .org registry.  Using the TPC-C benchmark methodology, Registry Advantage’s current hardware configuration has been measured in excess of 67,000 transactions per minute (tpmC), and is capable of over 200,000 disk I/O operations per second as well as processing 200,000 network packets per second.  Additionally, Sun Enterprise 6500 servers are expandable to more than double the amount of processors and RAM that Registry Advantage currently has configured.  Also, due to the continuous operation of multiple database servers, the addition of more powerful servers, such as Sun’s Sunfire 6800 servers, is easily accomplished.

The database leverages a 4GB shared global area and high performance storage to eliminate I/O bottlenecks.  The high performance SAN based managed storage is organized into volumes by Veritas Volume Manager software, and the Veritas VxFS filesystem.  This allows for flexible allocation and layout of the disk volumes to address both space and performance issues on the fly.  

As hot spots are identified, columns can be moved or added to distribute the I/O activity across more physical disk extents.  In addition, Veritas Quick IO is used to leverage Kernel Asynchronous IO (KAIO) capabilities of the Solaris Operating Environment normally only available on raw devices.  Database activity is monitored continuously and proactively.  Deltas in performance characteristics of the I/O subsystem, the listener, and a number of internal Oracle server attributes (such as locks and blocked sessions) trigger automated corrective actions designed to address each of these specific areas of operation.  Together, these technologies provide the best performance and stability in the industry.

Registry Advantage will operate a total of three Sun E-6500 database servers in two locations:  two currently in place at the primary Registry Advantage location in New York and one at its secondary location.  At the primary site, the databases will operate in three modes:  active, backup and standby.  At the secondary location, the databases will operate in two modes:  active and backup.  Of the three total databases, only one will be in active state at any time.  The site hosting the active database is the “active site”; the other site is the “backup site”.  All database servers at the backup site run in backup mode.

Figure C17.3.1: Standard Database Operations

A brief description of each of the database modes follows:

Active: The active database server supports the active database instance and is the authoritative source of information for all registry systems.

Standby:  The standby database server is attached to an alternate storage array and runs a database instance in recovery mode.  Every five minutes, redo logs are copied from the active database server to the standby system, and are incorporated into the standby database.  In the event of a failure by both the active and backup database servers, or the storage array used by the active and backup servers, the standby server will take over all database functions, and become the active database server.

Backup: The backup database server operates very much like the standby server, applying replicated logs to the storage device at the alternate site.  The failover to this database however, involves the complete failover of the primary site to the alternate site.  Although in terms of specific database operations, there is little difference in switching from backup mode to active mode at the alternate site, there are numerous other operational factors that are involved that make this transition unique.

Replication and Redundancy

Data will be replicated between the active and backup sites using GADSF – the Global Application Data Synchronization Framework (see the attached document for a detailed description of the operation and architecture of the GADSF software).

Figure C17.3.2: Database Replication

The Registry Advantage monitoring systems continuously check the health of the database at the active site; in the event of a failure at the active database, automated failover to the backup and/or standby database servers at the primary site will occur.  If the failure is a storage failure, the standby storage device is brought on-line and made active on the standby Sun E6500.  If the failure is server related or server access related, the standby Sun E6500 takes over operation of the active database on the primary storage device (and the standby database is paused).  In either scenario, recovery from failure is automatic and occurs in less than 3 minutes.  Restoration of the failed components is done manually by Registry Advantage operations staff.

If a catastrophic failure prevents failover to any database at the primary site, a site failover to the backup site is initiated manually.  A database instance will be activated on the backup database server, and the new active server will take over all database functions.  All registry-registrar services and cluster master services will also be moved to servers at the new active site.  When service is restored at the primary site, Registry Advantage will initiate a manual transition back to the primary.

Registry Advantage is committed to a Recovery Time Objective (RTO) of 0-2 hours and a Recovery Point Objective (RPO) of 0-5 minutes.  What this means is that under any circumstance, regardless of the failure scenario, the full operation of the registry will be resumed in less than 2 hours.  Additionally, it will have all of the data committed to the repository through the front end systems from the point of failure, or no more than 5 minutes prior to the downtime event.  In the first case above, in either the database failure or the storage failure, the actual RTO/RPO will be 0-5 minutes and 0 minutes.  That is, operations will be fully recovered within 5 minutes, with 0 data loss.  In the latter case above, where a catastrophic event causes a site failover, Registry Advantage will be able to deliver on the overall RTO/RPO and resume operations in less that 2 hours with at most the last 5 minutes of updates lost.  Depending on the catastrophic event, due to the robust nature of the GADSF, zero data loss is possible even in this scenario. GADSF was designed to specifically achieve this objective.

Management and Administration

Extensive procedures will guide all database operations, including schema changes, database changes, database failover, database backup, and disaster recovery.  The DotOrg Foundation’s policies and Registry Advantage processes and systems will ensure that extensive error checking occurs for any change made to the production database environment, and provides mechanisms to roll back changes in the event of unintended consequences on the production systems.

The schema for the .org registry database will be finalized as part of the registry’s implementation plan after the contract has been awarded.  However, it is likely to be extremely similar to the existing schema used to support Registry Advantage’s existing ccTLD customers. As part of the transition process, architectural provisions will be made to insure that the schema is able to represent all current objects and data currently present in the VeriSign .org schema. A discussion of the types of objects that will be represented in the registry is contained within Question C17.2, and further explanation of some functions implemented by the database (such as grace periods, transfers and object creation) are provided below. All changes to the Oracle database operations and architecture, including changes to schema, PL/SQL, and in the number and type of data services available will all be managed by qualified, dedicated database administrators who have been trained in the highly available and redundant high transaction data infrastructure described in this document.

More detailed descriptions of the key components of the database infrastructure are included on the following pages.  Specifically, documents are attached which describe:

Grace Periods

The database will also be responsible for implementing grace periods.  DotOrg Foundation intends for its grace period policies to be substantially similar to those that VeriSign currently implements for each of its gTLDs.  Each of the following grace periods is currently supported by the Registry Advantage database:

Object Creation, Change, Deletion

All objects in the Oracle database schema are managed through a library of PL/SQL packages.  This provides a common interface to the database objects for all front ends, regardless of language or platform.  For example, the registrar web interface written in Perl calls the same PL/SQL package functions as the EPP server implemented in C++.  This guarantees consistency in the behavior of any repository application.  Included in this library are functions to add, modify, and delete objects, as well as functions to query objects.  All responses from the PL/SQL package library return a consistent set of return codes and messages.

This package library approach allows for the centralization of critical code and knowledge.  Distributed repository applications all use a consistent interface to create and manage repository objects, simplifying the construction of these applications and reducing the likelihood of bugs in the front-end code bases.  Additionally, business rules and data integrity are enforced in a consistent manner across all front ends.  And although various front ends may implement their own security layers, these are in addition to access and security components built into the PL/SQL package library functions, which include hashed repository passwords and IP address associations with repository user logins.  These are independent from the schema logins used by Registry Advantage operations personnel to manage the repository database.

Object Transfers

Object transfers are also implemented by a set of PL/SQL packages implemented within the database.  Transfers may be initiated by registrars through the SRS or the web-based Account Management Interface.  Registrars may only request the transfer of domain and, eventually, contact objects.  Name server objects are implicitly transferred when their parent domain is transferred between registrars.

Procedure

A Registrar who wishes to assume sponsorship of a known object from another Registrar will initiate the transfer.  When the registry receives the transfer request, the status of the object will be reviewed.  If the object has any of the clientTransferProhibited, serverTransferProhibited, clientHold, serverHold, or pendingDelete status attributes associated with it, the registry will immediately respond to the registrar initiating the transfer request indicating that the transfer has failed.  If none of these properties are associated with the object, the transfer must subsequently be authorized.

Initially, the DotOrg Foundation will use a transfer authorization model similar to the one used by VeriSign for the legacy .org registry today.  This authorization mechanism relies on the losing registrar for authorization.  At the time the gaining registrar requests the transfer, a notification message will be sent to the losing registrar indicating that a transfer of the object has been requested, and the gaining registrar will receive a response indicating that the transfer is pending the authorization of the request by the losing registrar.  The losing registrar will then have up to five days to respond.  In the event the losing registrar does not respond, the transfer will be processed as if it had been approved.  If the losing registrar responds with a message denying the request to transfer, the registry will generate a notification message to both the registrar initiating the transfer and the losing registrar indicating that the transfer will not be completed, and the transfer process will terminate.  If the losing registrar responds with a message approving the transfer, or if the five day window ends without a response, both the registrar initiating the request and the losing registrar will be notified that the transfer has been authorized, and the object will be immediately transferred to the registrar that initiated the transfer.

At a later date, in consultation with ICANN and accredited registrars, the DotOrg Foundation may implement a policy that allows for the registrant to authorize the transfer by providing some authenticating information to the gaining registrar.  Such a model would require that the registry database store authentication-related data associated with certain domains and/or contact objects.  The advantage to this approach is that it would potentially allow for an expedited transfer process; though consideration would need to be given to protecting against unintended transfers. without a waiting period of up to five days.

Once authorization for the transfer has been obtained, the object will be transferred from the losing registrar to the gaining registrar.  This transfer is affected by modifying the “Registrar” field associated with the object.  For domain objects, at the time of the transfer, the registration period is extended by a year, and the gaining registrar’s account is charged for a registration.  All name server objects within a domain are implicitly transferred between registrars at the time that the domain is transferred; name servers associated with a domain are not transferred unless they are within the domain.

Reporting Capabilities

Registry Advantage currently provides its ccTLD registrars with a rich set of reporting capabilities.  This reporting capability will also be provided to all .org registrars, as well as to the DotOrg Foundation for internal tracking and accounting purposes.  Registrars are only capable of generating reports relevant to those domains for which they sponsor.

Report availability includes all reports currently supported by VeriSign, such as:

Registry Advantage also supports greater functionality than VeriSign, including the real-time generation of some reports based on registrar-supplied criteria.  Examples of the additional reports provided by Registry Advantage are:

These reports will be made available through the Account Management Interface.

Additionally, certain types of reports will be generated on a periodic basis for review by registrars.  These reports include:

These reports will be made available for download by the registrar.

[1] http://www.rfc-editor.org/rfc/rfc2832.txt

[2] VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 (see http://www.ietf.org/Internet-drafts/draft-hollenbeck-rfc2832bis-01.txt)

[3] http://www.ietf.org/html.charters/provreg-charter.html

[4] See http://www.ietf.org/Internet-drafts/draft-ietf-provreg-epp-06.txt, http://www.ietf.org/Internet-drafts/draft-ietf-provreg-epp-contact-04.txt, http://www.ietf.org/Internet-drafts/draft-ietf-provreg-epp-domain-04.txt, http://www.ietf.org/Internet-drafts/draft-ietf-provreg-epp-host-04.txt and http://www.ietf.org/Internet-drafts/draft-ietf-provreg-epp-tcp-04.txt.