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.

The primary On-Line Transaction Processing (OLTP) database is the most critical element of the .org registry provisioning function. Because of its critical nature, the primary OLTP database must be designed and built with several critical elements considered.

  • Performance. The proposed OLTP database is able to provide fast response. Current SLA requirements of 3 seconds for CHECK functions and 5 seconds for ADD functions are not sufficient. Any database not designed to process a transaction in less than 500 milliseconds can be expected to have difficulty handling peak periods. Critical to meeting performance requirements is keeping the minimal amount of data necessary in the OLTP database. The proposed OLTP database (which is currently supporting the .org registry) provides a well thought out archiving process that far exceeds these requirements.

  • Capacity. The proposed .org database is able to process more than 300,000 transactions per minute with 5,000 transactions per second or more during peak and/or land rush periods. It is also designed and tested to accommodate more than 100 million registrations.

  • Scalability. The proposed .org database is designed to scale beyond current registration levels. Just as quickly as registration volumes have been decreasing, they could turn around and begin rising. Even low registration volumes are no indication of potential transaction volumes.

  • Reliability. The success of any TLD registry depends on the quality of its service. In order for the Internet community to embrace (or continue to embrace) a TLD, reliability of service and data integrity are of paramount importance. The proposed .org database has a well-established history of providing both service reliability and data.

  • Security. If the primary OLTP database is susceptible to unauthorized intrusions, the stability of the entire TLD is at risk. But security is more than just providing protection against hackers. Section C17.9 discusses other critical elements of security in detail and describes how security requirements have been implemented.

  • Recoverability. With all hardware and software systems, failures are not a matter of "if", but a matter of "when". Therefore, all risks and contingencies must be considered. UIA recognizes that recoverability starts with the design of the database and continues into the hardware architecture, the software architecture, and even the underlying supporting facilities infrastructure.

  • Equivalent Access. This feature must be built in from the ground up. It is not an "after market" add-on. Significant investments have been made to ensure that the .org registry supports equivalent access for all registrars. The technical approach to ensuring equivalent access is outlined in Section C17.10.

Recent history has clearly demonstrated that registry databases must be designed to stand up under significant transaction volumes during peak periods. Many new registries have experienced massive transaction volumes during their initial start-up periods as registrars compete to be the first to grab desirable registrations. There is, however, another significant event that most new registries have not yet experienced and that has proven to generate massive transaction volumes. The event is the return of desirable registrations back into the market, an event that the current .org registry handles without incident every day.

Database Size and Throughput

The proposed .org registry database is designed and tested to host a minimum of 100 million registrations while maintaining strict SLAs and providing robust business continuity capabilities. It has a proven history of handling more than 100,000 transactions per minute on a continuous basis for days on end, with peaks of more than 300,000 per minute and more than 4 billion per month. Despite this transaction volume, the current .org registry consistently exceeds established SLAs, processing CHECK commands in an average of under 10 milliseconds and ADD commands in under 100 milliseconds. Figure C17.3-1 is a snapshot of these transaction volumes from the web-based monitoring tool.

Figure C17.3-1: One Hour Snapshot of Database Transaction Volumes

Transaction volume, however, is only one element required of a registry database. Another is reliability. A registry cannot permit the loss of even a single transaction. Therefore, multiple copies of the database must be replicated and stored in different locations, as displayed in Figure C17.3-2. To accomplish this, the .org registry uses data storage technology by EMC. The .org registry database is replicated within the primary data center facility in addition to being replicated to a geographically diverse site. Multiple copies of the database significantly reduce the possibility of data loss or corruption, as well as providing for speedy recovery of services in the event of a disaster. Always having a current copy of the data means that time need not be spent restoring from a back-up tape and replaying transaction logs in order to fully restore the database. Of course, tape back-ups and transaction logs will be generated and kept in the unlikely event that they will be needed, but there is no substitute for having multiple real-time updated copies of the database.

Figure C17.3-2: Registry Database Real-Time Redundancy

The ability to handle large transaction volumes is of little use if the system is continually subject to unscheduled and unplanned outages. In 2001, the current .org registry operated at 99.987% reliability (refer to C17.3-3).

Figure 17.3-3: Registry Availability in 2001 

Thus far, in 2002, the current .org registry is operating at 99.994% reliability (refer to Figure C17.3-4).

Figure 17.3-4: Registry Availability in 2002 

A Registry Command Center (RCC) monitors the performance of, and registrar connectivity to, the .org database in 60-second increments. Equivalent access is ensured through the use of multiple connection pools that guarantee each registrar sufficient connections to enable customers with live Internet presences to update their data, while also supporting customers who cater to the speculation industry. Refer to Figure C17.3-5 for detail.

Figure 17.3-5: Registry Connection Pools 

Using multiple pools, the .org registry is able to guarantee each registrar a minimum number of connections (15) in the Guarantee Pool. Registrars that need additional connections may obtain them from the Overflow Pool. The Automated Pool is a pool of connections specifically set aside to support registrars that exercise intensive batch processes to search for and obtain registrations as they are deleted. Experience has demonstrated that any registry subject to a land rush for deleted registrations must provide a mechanism by which this activity can be performed without impacting users who are attempting to maintain their web presence. These capabilities are discussed in detail in Section C20.

Access to the .org database is currently accomplished through a secure RRP connection, and database objects are created as a result of business rules in the application servers generated from specific RRP commands received from the registrars. The RRP protocol was designed with an attribute called "idempotency", which permits commands to be issued multiple times but executed only once. With the transition to EPP (discussed in detail in Section C22), registrars will be able to use the same protocol as many of the newer registries, and the new .org registry will be better able to extend service offerings.

The proposed .org registry will continue the current detailed level of reporting provided to the registrars, including reports issued daily to each individual registrar containing information such as:

  • Registration activity (e.g., ADDs, DELETEs, etc.)
  • Transfer activity
  • Available credit

To maintain the performance and reliability of the .org database, older data (more than three months) will be routinely migrated to the Critical Data Archive (CDA), where it will be maintained indefinitely. In this way, data needed to support registrar and law enforcement inquiries and/or disputes is always available.

In the current .org database, grace periods are configurable. UIA believes that changes to the current grace period implementations are desirable and would cooperate fully with ICANN and the Internet community with regard to proposed changes. Specifically, UIA would like to see a longer DELETE grace period that would reduce the risk of registrants accidentally losing their registrations or having them held hostage by cyber-squatters. The current ADD grace periods are more attractive to speculators than to non-profits, and should probably be reduced or eliminated.

Domain transfers are currently a source of significant debate among the registrars and within the Internet community. UIA is committed to the stability of the .org domain and believes that unbridled transfers can create problems for registrants, just as it has in the long-distance telephony environment. UIA is, however, also committed to working with ICANN and the constituency groups to develop and implement transfer procedures that protect the interests of the registrants and the stability of the .org domain. All changes to the .org database will be performed via the RRP commands processed through the Gateway and Applications servers, and will be maintained in database logs, making it easy to track the historical activities of individual registrars as well as the history of specific domain registrations. Tracking is particularly important for financial transactions. If specific one-time data fixes are required, they will be engineered, tested and implemented with the utmost rigor and caution, and always with an audit trail. In the event of the default, acquisition, or closure of a registrar, the proposed .org database has the ability to transfer domain registrations to another registrar, either en masse or according to a specific list of domain registrations. 


Back to Table of Contents