Main Page | Proposal Home

Jump to question:
C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9 | C10 | C11 | C12 | C13 | C14 | C15 | C16 | C17 | C18 | C19 | C20 | C21 | C22 | C23 | C24 | C25 | C26 | C27 | C28 | C29 | C30 | C31 | C32 | C33 | C34 | C35 | C36 | C37 | C38 | C39 | C40 | C41 | C42

C17. Technical plan for performing the Registry Function. This should present a comprehensive technical plan for performing the Registry Function. In addition to providing basic information concerning the proposed technical solution (with appropriate diagrams), this section offers the applicant an opportunity to demonstrate that it has carefully analyzed the technical requirements for performing the Registry Function. Factors that should be addressed in the technical plan include:

RegisterOrg is committed to providing the highest possible levels of stability, security and performance, both during the transition period and in the ongoing operation of the .org registry. The registry infrastructure has been designed by combining state of the art hardware with sophisticated software and proven operational practices. These technical systems and facilities ensure the high levels of reliability, functionality, and performance required to provide the quality of service demanded by registrars, registrants, and the Internet community in general. Registry Advantage’s experience and resources assure that it can also provide the stability and readiness required by the challenging transition process.


·         Core hardware selected to provide high mean time between failures (MTBF).

·         Significant redundancy throughout the infrastructure guarantees no single point of failure.

·         Many failure modes are diagnosed and corrected for automatically with no human intervention.

·         Registry Advantage has a proven track record, with uptimes exceeding 99.99% for all services.


·         The Registry has an operational global registry infrastructure in place today.

·         Registry Advantage currently provides multi-protocol access to its shared registry system.

·         Key personnel in place now.


·         Registry Advantage has proven experience performing the migration of TLD names to its infrastructure.

· is profitable and stable, with over $200 million in cash and marketable securities.



·         High performance hardware and software has been selected.

·         Measured operational capacity of all systems substantially exceeds projected peak loads.

·         Performance is sustained even in the event of component failure.


·         Registry Advantage SRS currently supports EPP.

·         DNS and Whois services comply with all relevant RFCs.

·         Registrar Account Management Interface offers significantly enhanced functionality and reporting compared to VeriSign’s registrar tool.

Today, the .org TLD contains over 2.7 million second-level domain names, and ICANN has indicated that its first priority is preserving a stable, well-functioning .org registry. This requirement is further complicated by the need to ensure a smooth transition between registry operators by January 1, 2003, and to provide multiprotocol access to the Shared Registry System. The operational requirements of the .org registry are complicated by the need for a smooth transition between VeriSign and the new registry operator. This transition must be accomplished with minimal disruption to the registry’s operations (including zero downtime for critical subsystems such as DNS) and with no data loss. To reliably achieve these goals, a strong theoretical registry design is not sufficient; instead, the successful applicant must demonstrate real-world experience, with a proven capacity to both operate a large registry and complete a complicated migration.

Registry Advantage is an experienced registry operator, and has the systems, facilities and personnel in place today to operate a stable, well-functioning .org registry. Registry Advantage has built upon’s experience as one of the world’s largest providers of DNS services by creating a high-performance DNS server specifically optimized for registry operations. This software is tightly coupled to Whois, SRS and account management systems that currently provide registry services to a number of functioning ccTLDs. In addition, Registry Advantage has formulated a clear, methodological transition plan for the .org registry with established and verifiable milestones. As described in C18.6, this transition plan is based on Registry Advantage’s unique experience of performing migrations of entire top level domain name registries from existing operators to its own infrastructure.

Registry Advantage’s systems have been proven capable of supporting the .org registry. As described in C17.10 and attached in Section XI, Test Results, Registry Advantage has conducted extensive testing of its systems to demonstrate that they have the capacity, performance, and reliability required by the .org TLD. These same tests demonstrate the capability to rapidly and successfully migrate the entire .org data set to its own systems. This parallels Registry Advantage’s results transitioning ccTLD registry operations, in which all data was migrated with zero downtime and zero data loss.

Finally, RegisterOrg and Registry Advantage are committed to providing the world’s best registry. This commitment is not a promise backed only by words. As described in C28, Registry Advantage has sufficient confidence to offer service-level commitments that are simply the best in the industry, meeting or exceeding the highest service-level metrics offered by any TLD registry operator today. Similarly, Registry Advantage is prepared to make financial commitments to ICANN associated with achieving each major milestone in the transition process

C17.1 General description of proposed facilities and systems. Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.

The Registry Advantage facilities and systems are described in detail throughout C17, but are summarized in the remainder of 17.1. All major elements of the registry infrastructure are operational today. Upon the award of the .org registry to RegisterOrg, Registry Advantage will also deploy services at four additional locations. No single point of failure exists throughout the registry infrastructure, and multiple layers of redundancy ensure that even in the event of multiple components failing simultaneously, the system will continue to function normally. This approach allows Registry Advantage to deliver levels of reliability normally associated with mission-critical applications such as core telephone networks and trading floor environments.

Locations of Facilities
Registry Advantage will provide services from eight geographically dispersed facilities worldwide. Four of these facilities are operational today. The registry architecture includes two general types of facilities: “subscription” and “publication”. The “subscription” facilities, which are provided at two locations, support registration services (including the SRS and the registrar’s Account Management Interface) as well as Whois and DNS services. The other six locations provide a read-only “publication” interface to registry data using the DNS protocol.

In order to provide a highly reliable registry infrastructure, Registry Advantage will operate core registration services in two locations. Each of these locations will provide Shared Registry System (SRS), database operations, account management, DNS and Whois services. One of the two locations is currently operational at an AT&T data center located at 811 Tenth Avenue in New York City. For the purposes of this document, this location is referred to as the “primary site”. Registry Advantage will also duplicate the core registry functions at a “secondary site” in Asia, which will be built out and deployed upon award of the registry to RegisterOrg. Registry Advantage has selected the Tokyo, Japan region as a likely location for the secondary site, although the final location will be determined after the selection of the successor registry operator.

In the event of a failure at the primary site, or other unforeseen circumstances, core registry functions will be transferred from the primary site to the secondary site. Only one site will host the core registry functions at any given point in time.

In addition to the primary and secondary sites, Registry Advantage currently operates DNS services at the following facilities:

  • MFN ( facilities at 6-7 Harbor Exchange in London, U.K.;
  • MFN ( facilities at 150 South First Street in San Jose, CA; and
  • Diyixian Internet Centre at 168 Yeung Uk Road in Hong Kong.

Further information about each of these facilities is attached in Section XI, Data Centers.

Additional DNS facilities will be built out in the event that RegisterOrg is selected. Although the final locations of these facilities will also be determined in the future, the intent is to locate one in each of the following areas:

  • Central region of the United States of America
  • Europe
  • United States of America (location to be determined)

Facilities will be selected with the intent of maximizing network diversity and performance. Typically, facilities will be located at or near major internet exchange points.

Building Security, Environment and Connectivity
All Registry Advantage data center locations are subject to a rigorous set of requirements relating to security, physical plant, network connectivity, and policies and procedures. These requirements include:

Physical Security



24/7 Guard Service


Continuous monitoring of data center areas


Positive identification required of all persons accessing data center floor


Physical barriers separating data center floor from publicly-accessible areas

Environmental Equipment



Fire suppression system throughout the building


HVAC units to control temperature and humidity


All hardware attached to uninterruptible power supplies


Backup power provided by on-site electrical generator


Resistant to natural disasters

Network Connectivity



Multiple high speed (45+ Mbps) network egress paths


Presence of multiple carriers


Minimum connection requirements for Registry Advantage routers:

Primary and secondary sites: 100 Mbps

DNS POPs: 10 Mbps



Availability of BGP peering session

Policies and Procedures



In the event the data center hosts any ICANN accredited registrar or other gTLD registries, the systems will be physically and distinctly separated from each other.


Will allow personnel officially designated by the registry to inspect the facilities in which the registry’s data center is maintained at any time upon reasonable notice.

Capacities of Systems
Registry Advantage has designed its systems to ensure maximum reliability, performance and security for the .org registry. Its existing database and registry systems already support over five million domain names and can process at least one hundred thousand new registrations per day. Registry Advantage has built systems that can support a peak registration capacity of over 200 new registrations per second and up to 1000 check queries per second. These current levels are five times (5x) the expected maximum “add storm” peaks based on analysis of publicly available data. (See section C17.10 for details.)

Furthermore, RegisterOrg is prepared to commit to service level agreements that meet or exceed the “best-of-breed” based on an analysis of the SLAs in place for all of the major gTLDs. Availability for DNS will be meet 100% uptime, while Whois and SRS will meet or exceed an uptime of 99.99% (see C17.13 and C28 for definitions and details). Registry Advantage, on behalf of RegisterOrg, has engineered its systems to meet or exceed those guaranteed service levels.

Systems Overview
The transactional hub of the Registry Advantage infrastructure is an Oracle database running on a Sun Enterprise 6500 server. Storage for the database is provided by an EMC Symmetrix 8530 storage array. McData Sphereon 3016 (ES-16) FC/FA fibre channel switches provide connectivity between the database and its storage, as well as to a Spectra Logic AIT3 tape backup library. Additionally, network-attached storage for front-end servers is provided by a Network Appliance storage array.

Front-end registry functions such as Shared Registry Service, DNS, and Whois run in a Linux environment on clusters of IBM X330 1U servers. Requests are load-balanced among the hosts in these clusters by Big-IP load balancers from F5 Networks and with the load balancing features of Extreme Networks Summit Ethernet switches. Additional network components include Cisco routers and switches, and Netscreen firewalls.

This baseline infrastructure is deployed at Registry Advantage’s secondary site in Asia, as shown below.

In addition to this baseline infrastructure, additional components are added at the primary site in New York to provide additional redundancy and reliability. A duplicate Sun Enterprise 6500 server acts as a hot standby database. Also, an EMC ClarIIon 4700 storage array acts as alternate storage for both database systems.

Network Architecture
The network infrastructure is designed to be robust, fast, and scalable. The design is based on standard network architecture principles that have been well tested and found to be very reliable. It is designed to have no single point of failure, and for the network to continue operating even in the event of failure in multiple components.

The network consists of several zones: border, core and access. At the border, two Cisco 7206 routers attach to upstream ISPs via Fast Ethernet and DS-3 interfaces. Each router operates a Border Gateway Protocol (BGP) peering session with the ISPs that attach to it. BGP is used to make route announcements for all public IP addresses used within the location, as well as to receive routing updates from the ISPs. The two routers are connected to one another via a gigabit Ethernet link. For redundancy purposes, the routers use Cisco’s Hot Standby Router Protocol to provide for automatic failover capabilities in the event of a failure. The routers have public IP addresses, but they will make use of extensive access lists to serve as a preliminary layer of network security and prevent large streams of malicious packets from reaching the firewalls.

Also in the border zone are the firewalls. Registry Advantage uses Netscreen firewalls. These firewalls have automatic failover capabilities, which allow a standby unit to assume active operations in the event of a failure of the currently active unit. All traffic passes from the routers through the firewalls before moving to the internal network. The firewalls will use public IP address space on their outside interfaces and private IP address space on their inside interfaces.

In the core, Registry Advantage operates two Extreme Networks Summit 5i non-blocking gigabit switches. These multilayer switches will provide core switching (layer 2) and routing (layer 3) functions at wire speed (up to one gigabit per second on each port). Network paths will exist from both of these switches through the firewalls to the border routers. Additionally, these switches will be connected via redundant gigabit links on different ports.

The other service provided in the core zone is load balancing. Two Big-IP load balancers from F5 networks will be used for this function. Each of these devices will attach to one switch via two gigabit Ethernet connections. (The two connections do not provide redundancy; one is considered the “outside” interface by the Big-IP and will use public IP addresses, and the other is considered the “inside” interface by the Big-IP and will use private IP address space.) Requests from outside the network for public services such as Whois or the SRS service will actually be routed to addresses on the “outside” Big-IP interface. The request will be processed by the load balancer and handed off to an appropriate internal system. The Big-IP can use a number of algorithms to determine the best server to hand an individual request to, but generally requests are handed to individual hosts in a cluster on a round-robin basis. Note that the load balancer will only attempt to process requests destined for legitimate public services. No attempt is made to translate packets and move them into secure internal systems such as the database or NFS storage arrays. The Big-IPs will use a high availability configuration. At any given time, only one of the switches will be active. If a Big-IP or one of its network links should fail, the other load balancer will become active and take over all virtual IP addresses used to provide load balancing functions.

Finally, the access layer will consist of a number of Extreme Networks Summit 48 switches. These switches will connect to each of the Black Diamonds via a gigabit Ethernet connection, and will use the spanning tree algorithm and Extreme’s Standby Routing Protocol to prevent routing loops and allow for redundancy in the event of a link or core switch failure. Individual hosts will attach to the Summit 48 switches via Fast Ethernet. Hosts requiring gigabit Ethernet access to the network will attach directly to the core switches.

Logical Network Architecture
The data flow between the three architectural layers described above and the Internet can be additionally described in terms of the logical access between these layers. Systems that are logically associated with the access layer are only accessible via private (RFC 1918) address space. Additionally, the VLANs in the access layer only allow specific VLAN and IP source traffic through the use of access restrictions on the switches. This effectively limits inbound connections to only systems originating from the core layer. Similarly, systems in the access layer are only able to directly communicate with other systems in the access layer, or systems in the core layer with private addresses.

Similar restrictions exist between the core layer and the border layer, where connections originating form the Internet may only reach systems between the border and core layers (e.g. the BigIP). This effectively forms two virtual demilitarized zones (DMZs) within the physical network architecture.

Satellite Location Network Architecture
At remote DNS locations, the network is significantly simplified. At each of these locations, Internet connectivity will generally be from a single ISP via a 100-megabit fast Ethernet connection (or, in some circumstances, possibly a 10-megabit Ethernet connection) directly into a Summit 48i layer 2 and layer 3 switch. This switch is capable of performing wire-speed routing and switching functions, and all equipment at the location will attach directly to the switch. The switch also has software that enables it to communicate with the ISP using BGP to propagate route announcements into the global Internet. Additionally, the switch can also provide basic load balancing services required to intelligently distribute requests across multiple hosts in a cluster, in a similar manner to the Big-IP load balancers described above. A Netscreen firewall is also attached to the switch. VLANs are created on the switch in order to separate the network into inside and outside portions, and allow the firewall to effectively protect the servers on the network. As with the Registry’s Cisco 7206 routers, access control lists will also be applied on the switch to restrict access to the network even before packets reach the firewall.

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

  • · Extreme Networks Summit 5i switch;
  • · Cisco 7206 VXR router;
  • · Extreme Networks Summit 48i switch;
  • · Big-IP Enterprise load balancer; and
  • · Netscreen firewall appliances.

Database Systems
The Registry Advantage database is an Oracle 8.1.7 server instance tuned for both online transaction processing (OLTP) and decision support system (DSS) functionality. Registry Advantage database operations make use of Sun Enterprise 6500 servers, a proven high-availability and high-performance hardware platform. In order to provide maximum reliability, the Registry will operate three database servers in two locations, any of which can rapidly assume the function of the active database.

Primary Site
The primary data center houses two of the three Oracle database servers in the Registry Advantage high availability architecture. These are configured in a tightly coupled high availability cluster, each with redundant access to a pair of synchronized high availability storage arrays. These Oracle instances are instrumented and actively monitored in real time by dedicated Oracle database administrators and enterprise management software.

Secondary Site
The secondary data center will house the third Oracle database server in the Registry Advantage high availability architecture. This server will be dual attached to a single McData FC/FA switch, providing access to another high availability storage array, also synchronized with the active database server at the primary site.

Database operations are described in detail in C17.3.

Storage Systems
Registry Advantage has a state-of-the-art storage network comprised of industry-leading 100% uptime guaranteed high performance storage frames in a fully redundant SAN Fibre Channel Fabric, as well as clustered Network Attached Storage (NAS) devices. All storage hardware is provided by market leading vendors.

Primary Storage
At both the primary and secondary location, the primary storage device is an EMC Symmetrix 8530 that is attached via fibre channel to a McData redundant switch pair. This provides a highly available storage sub-system which is achieved through EMC’s redundant platform design, multiple fiber channel interconnects, power path load balancing, and Veritas volume manager / file system. The EMC Symmetrix is configured to provide the following basic storage components:

  • · Over 500 GB of RAID-1 (primary database table space);
  • · Over 500 GB of BCV backup (an independently manageable third mirror of the primary table space);
  • · 4 GB of redundant cache with industry leading advanced cache management; and
  • · Active-Active redundant internal disk directors for exceptional I/O rate handling.

This configuration allows for inter-day snapshots and archive to the secondary data storage, hundreds of thousands of I/O operations per second, and the fastest random I/O performance in the industry. This also comes with a 100% uptime guarantee from EMC.

Network Attached Storage
A Network Appliance 740 cluster in a highly available configuration addresses all network attached storage needs. This storage will be accessed using NFS and allow all currently specified nodes to connect. In addition to the compressed database copies and archived logs (staged as part of the Global Application Data Synchronization Framework), this device also supports the Information Request System redundant masters and other front end application systems (see the application section for details).

Network Appliance is the market leader in NFS filer appliance technology and the clustered F740 filer is a state-of-the-art high availability NFS filer, utilizing the latest DataOnTap filer operating environment. It is capable of dynamic resizing of volumes, multiple point-in-time snapshots per volume, automated fail over, and proactive management using industry standard tools, such as SNMP and Secure Shell. The proprietary WAFL File System is capable of extremely large numbers of files per directory and large files with exceptional performance.

Alternate Storage
An EMC CLARiiON 4700 RAID subsystem, dual fabric attached, provides an additional 500GB+ of alternate direct attached storage. This hosts the standby database copy, and the archived logs and has the following characteristics:

  • Over 500GB of RAID5 (primary database table space);
  • 2GB mirrored cache;
  • Dual internal fibre channel arbitrated loops; and
  • Native fibre channel disk architecture for maximum internal throughput.

The EMC CLARiiON 4700 operates within the same order of magnitude of the primary storage device, handling over 100,000 I/O operations per second and achieving over 200MB of throughput.

All data storage is backed up via Veritas Netbackup to a Spectra Logic Spectra 12000 AIT3 tape library, capable of storing over 30TB of data in a single 120 AIT3 tape set, and can backup over 800GB of data per hour. The backup server has access to the primary data storage over a direct fiber channel connection. The secondary data storage is accessed as a netbackup client over the local gigabit Ethernet connection.

Full (level 0) Database and System backups run daily. Retention policies store weekly backups for one month and monthly backups for twelve months.

Component failure in the managed storage
The Symmetrix is a highly redundant subsystem with advertised “zero downtime” as part of its feature set. It can withstand any single component failure with no loss of service, and can be configured to have available sparing to tolerate multiple component failures for disk drives.

Therefore, to the extent configured, component failure (single in most cases, or possibly multiple in the case of extents) presents zero downtime, zero data loss, and zero risk to the operation of the Oracle database.

Likewise, the NetApp cluster is similarly redundant and any single redundant component failure will result in zero downtime and zero data loss.

Since the Oracle database is not dependent on the alternate storage for operation, failures in this unit have no impact on the production system. However, the unit is a redundant RAID subsystem and can withstand single component failures. This would only matter in the event of a total Symmetrix failure, and only for as long as it takes to restore the Symmetrix to full operation.

If the primary storage is failed or corrupt, the network-attached storage device has copies of both the database volumes and the archived logs. Additionally, the alternate storage device has a point-in-time copy of the database and all subsequent logs, keeping the standby database copy in a near current state. Application logs can be used, if need be, to replay any transactions not yet applied to the standby database copy.

In the event the network attached storage fails, no downtime will be experienced. However, the secondary copies of the data and logs will be unavailable and no new secondary copies will be stored until the network-attached storage is available again.

Secondary Site
At the secondary site, the storage environment is simplified. A single storage array attaches to a McData switch fabric. No alternate storage is provided. Network attached storage is once again provided by a Network Appliance storage array.

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

  • EMC Symmetrix 8530;
  • EMC CLARiiON 4700;
  • McData Sphereon 3016 (ES-16);
  • Network Appliance 740 filer; and
  • Spectra Logic 12000 AIT3 tape library.

Application Servers and Software
All applications are served from clusters of high performance Intel-based systems that run the open-source GNU/Linux operating system, tuned to satisfy the demands of the registry environment. The application software was written by Registry Advantage to meet the needs of high performance, reliability and security. The proprietary DNS application service, in particular, provides security advantages over alternatives such as the open source BIND service.

Key features of the application servers include:

  • Dual processor design for maximum performance;
  • Capable of supporting up to 4 gigabytes of RAM;
  • Multiple fast Ethernet connections; and
  • System Maintenance bus for out-of-band management.

Application Servers at the Primary Site
The following applications are supported by the IBM X330 GNU/Linux platform:

  • Shared Registry System (SRS): This is a set of dedicated pools of servers supporting the various SRS protocols available in the RegisterOrg registry. These are also load balanced by the F5 BigIP layer 4 switch.
  • Whois: This is a set of dedicated pools of servers supporting the distributed Whois cluster. Pools are dedicated to the service, or a part of the distributed cache. The Whois cluster utilizes load balancing by both the F5 BigIP layer 4 switch, as well as the layer 4 load balancing capabilities of the Extreme Networks switching gear, if required.
  • Domain Name Service (DNS): The DNS server pools are highly redundant and independent of each other and rest of the architecture. Each set of DNS servers is a pool of both BIND based DNS services and Registry Advantage’s proprietary DNS services (RA-DNS). The zone files in the BIND servers are created using a Generator batch process, while the RA-DNS servers are updated from the Cluster Master. Each geographically distributed DNS Point of Presence (PoP) is load balanced using advanced layer 4 load balancing techniques available on Extreme Networks switching gear. The Registry Advantage DNS achieves high performance (thousands of UDP transactions per second sustained on a single Intel-based Linux server) and efficient memory use (over 10 million names stored in 2GB of memory on a single Intel-based Linux server). The zone update mechanism supports near real time (within minutes) DNS updates in a flexible, scalable and reliable solution.
  • Cluster Masters: Each of the application cluster pools above communicates with the application cluster master servers to obtain configuration information, incremental data updates. In return, the application cluster pools provide the cluster masters with status information. This allows the cluster masters to act as watchdog monitors for all application servers. The master cluster is a high availability pair of IBM X330 GNU/Linux systems each with redundant configuration data and a synchronized cache of changed objects from the active database.
  • Account Management Interface (AMI): This is a dedicated pool of secure web servers to support the AMI application cluster, load balanced by the F5 BigIP. The Account Management Interface allows registrars to log in and update registration data for their registrants as well as to generate transaction summary reports.

Additional Services Supported at the Primary Site
In addition to the primary application clusters, RegisterOrg also maintains dedicated systems and network management servers, including Host and Network Intrusion Detection Systems (H/NIDS), as well as a complete set of development and testing servers, and a fully functional replication of the production environment for Quality Assurance Testing.

Supported Applications at the Secondary Site
The secondary site will host a complete replication of the production application server pools. Each application cluster will be replicated with N=N redundancy, ensuring the secondary site is fully capable of operating the registry at any time. The redundancy in the number of 1U servers and network interconnects, as well as the load balancing capabilities of the primary site will all be fully present at the secondary site. Additionally, as the primary site expands, the secondary site will expand in lock step, maintaining the reliability of the architecture.

Supported Applications at the Satellite Locations
At this time, Registry Advantage maintains 3 satellite locations, in addition to the primary and secondary sites. These locations support three additional DNS Points of Presence (PoPs), each with its own cluster of both BIND and proprietary DNS servers. Like the primary site, these satellites use the advanced layer 4 load-balancing capabilities of the Extreme Networks Summit 48i switches for high performance and availability. The geographically distributed POPs may also be load balanced globally using an implementation of RFC 1546 “anycasting,” leveraging the stateless “best effort” nature of the DNS.

C17.2 Registry-registrar model and protocol. Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.

The SRS provides multi-protocol access via both RRP and EPP. The SRS is capable of performing over 180create and 800 check commands per second, compared with peak capacity requirements of 10 creates and 500 check commands per second.


The Registry 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.

Through its backend technology provider, Registry Advantage, the Registry has significant experience implementing and operating registry-registrar models that utilize multiprotocol 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 multiprotocol 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 in making use of the RRP to perform registrations. 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, 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.

Access to the SRS will be provided through two protocols: RRP and EPP. The legacy RRP created by VeriSign is described in RFC 2832 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.

The Registry 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. These changes include:

  • · Status codes for registry entities have been modified to be more similar to those used in EPP.
  • · Clients have the capability to cancel a requested transfer.
  • · IPv6 name server addresses are supported.
  • · Some response codes have been added or modified.

The adoption of these changes would result in the RRP version being updated to 2.0.0. RegisterOrg 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 attached in Section XI, RRP.

In addition to implementing protocol elements identical to those used within VeriSign’s SRS, RegisterOrg has duplicated many policies, 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, RegisterOrg intends to allow registrars to continue regular business operations with the least possible disruption due to the migration of registry operation.

In 2001, the Internet Engineer Task Force (IETF) formed a working group, known as provreg , 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. The Registry’s technical team 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. RegisterOrg 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 . Registry Advantage has currently implemented this version of the EPP drafts for use by its ccTLD registries. Additionally, as required by ICANN, the Registry’s technical team 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, the Registry will initially support only domain and host objects within its EPP implementation.

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 the registrar’s user name as the common name field. The Registry’s 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, the Registry 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 above security factors independent of the others, 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 RegisterOrg 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 C18. Specifically, the Registry will gather the following information that is not included in the current gTLD Registry:

  • Registrant information; and
  • Administrative and technical contact information.

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 RegisterOrg believes that the eventual outcome of those discussions will be invaluable in devising clear practices for both registries and registrars. The Registry’s technical team 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 RegisterOrg, Registry Advantage will manage the thin to thick migration by moving through several phases of EPP operation:

  • In phase one, the Registry will prohibit the use of contact objects. In this mode the Registry is purely a thin registry.
  • In phase two, the Registry allows for contact objects to be created, modified and deleted, and for contact objects to optionally be associated with domain names.
  • In phase three, the Registry requires that contact objects be associated with domain names when they are created or renewed.
  • In phase four, only those domain names with contact objects are published into the .org zone file.
  • In phase five, the Registry will prohibit the use of domain names without contact objects associated with them. Any domain name without contacts will be automatically deleted from the Registry’s database. In this mode the Registry is purely a thick registry.

This process is described in detail in 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.

The Registry 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.

Through Registry Advantage, the Registry 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:

  • High-end data warehousing capabilities;
  • Sophisticated query optimization;
  • Rich variety of integrated indexing schemes, join methods, and summary management features;
  • Partitioned tables and indexes based on range, hash or composite partitioning;
  • Parallel index creation and support for automatic index maintenance;
  • Scalable parallel architecture for SMP and MPP platforms;
  • Unlimited database size;
  • Architecture that supports thousands of simultaneous requests;
  • Online backups that can be made without interrupting transaction processing;
  • Extended backup/recovery subsystem, including online backups without interrupting transaction processing;
  • XML parsers;
  • User authentication and security;
  • Advanced resource management;
  • Full multilingual support, including Unicode UTF-2;
  • Database event triggers; and
  • Logging and archiving.

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 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.

RegisterOrg will operate a total of three Sun E-6500 database servers in two locations: two currently in place at the primary 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.

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 fail over to this database however, involves the complete fail over 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 Section XI, Database Replication for a detailed description of the operation and architecture of the GADSF software).

The Registry’s technical teams’ 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’s operations staff.

If a catastrophic failure prevents failover to any database at the primary site, a site fail over 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 fail over, 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. RegisterOrg’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 Section 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:

  • Sun Enterprise 6500 servers;
  • Solaris 8 operating environment;
  • Oracle 8i Enterprise database system;
  • Veritas Volume Manager, Cluster Server, Global Cluster Manager, and Net Backup; and
  • Registry Advantage Global Application Data Synchronization Framework.

Grace Periods
The database will also be responsible for implementing grace periods. RegisterOrg 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:

Add grace period: This period begins when a domain is initially created. If a registrar deletes a domain while this grace period still applies, the registrar will receive a credit for the registration.

Renew grace period: This period begins when a domain is renewed. If a registrar deletes a domain while this grace period still applies, the registrar will receive a credit for the registration.

Auto-renew grace period: This grace period is similar in nature to the renew grace period, but applies only to those domains which have been automatically renewed at the end of their terms. It is anticipated that this grace period will be longer than the standard renew grace period.

Transfer grace period: This period begins when a domain is transferred to a new registrar. If the new sponsoring registrar deletes a domain while this grace period still applies, the new registrar will receive a credit for the registration.

Delete pending period: This period begins when the registrar issues a command to delete an object. During this period, the object is removed from all visible systems such as the DNS and WHOIS system, but it remains in the database and cannot be registered. This allows the registrar or registry to reverse an accidental deletion. The delete pending period does not apply to domains deleted during the add, renew, auto-renew, or transfer grace periods.

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.

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, RegisterOrg 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, RegisterOrg 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, although 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 RegisterOrg 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:

  • Logs of all transactions completed in a single day;
  • Logs of all transfers, both gaining and losing; and
  • Listing of all nameservers registered for that registrar, and the associated domains.

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:

  • Listing of all transactions performed by the registrar within a specified time period;
  • Listing of all billable transactions performed by the registrar within a specific time period;
  • Listing of all instances of a certain type of transaction (such as create or modify) by the registrar within a specific time period;
  • Complete transaction history of a specified domain; and
  • Listing of all domains currently sponsored by the registrar.

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:

  • Listing of all domains currently sponsored by the registrar;
  • Listing of all domains currently pending delete;
  • Listing of all domains currently pending transfer;
  • Listing of all domains within 30 days of expiration; and
  • Listing of all billable transactions within the previous month.

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

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

    On behalf of RegisterOrg, Registry Advantage will operate a world-class DNS infrastructure to support the .org registry operations. In order to overcome the limitations of BIND, RegisterOrg will use the proprietary DNS server application developed and deployed by Registry Advantage. The important features of this technology include:

  • Near real-time propagation of updated domain information;
  • Fault-tolerant clustering of DNS servers;
  • No fixed limit to the number of zones supported by a single cluster; and
  • Tight coupling to the SRS repository, including the SRS interfaces for adding/changing/deleting objects and SRS security.

    The design of this DNS infrastructure allows per-domain updates to the Registry database from authorized parties. These updates are initiated through the registrar’s SRS interfaces or through the registrar secure web based account management interface. Once a registrar makes a successful change to a domain involving DNS-related information, the database will insert an update message into a queue for the cluster master. The cluster master then uses a secure network protocol to distribute the updates throughout all other clusters of DNS servers. In this manner, changes can be propagated from the database to all DNS servers with a frequency of under five minutes. The process of distributing these updates to satellite DNS sites is described in greater detail in the attachment, Section XI, Database.

    This per-domain update mechanism (see diagram below) eliminates the need for traditional zone file generation to actively manage the DNS.

    All updates will be logged by both the database and the DNS application; these logs will periodically be crosschecked to verify consistency. These logs will also be backed up on a daily basis (see C17.7) and can be used to restore the DNS system to its state at a previous moment in time, and provide an audit trail. In addition, traditional BIND compatible zone files will be generated on a daily basis and archived to tape as part of the data escrow process. This also allows for high level inter-day changes to be easily identified, in addition to the SRS audit logging.

    Since the DNS information is automatically updated in near real time, no access to the DNS zone information is allowed outside of the SRS repository. All changes to the DNS data must be made through SRS to ensure access security and proper change tracking by registrars. The daily zone files generated are for backup and referential purposes only (see below) and are stored in a restricted file system that only Registry Advantage authorized personnel have access to.

    In order to ensure the stability of its DNS infrastructure, the Registry will also deploy several backup DNS servers running BIND. Although these systems will not generally be used to answer DNS queries, in the event of a catastrophic failure of the principal .org DNS infrastructure, Registry Advantage will use the BIND-based DNS servers in a failover mode. Traditional zone file generation will be required to keep these servers up to date, and this zone file generation will occur on a once daily basis as described above. These zone files are validated using secure cryptographic hashes and digital signatures before they are loaded into the backup BIND servers. Once the ongoing stability of the Registry infrastructure has been established, these backup servers may be phased out.

    Once the ongoing stability of the Registry infrastructure has been established, these backup servers may be phased out.

    C17.5 Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them. If you propose to employ the VeriSign global resolution and distribution facilities described in subsection 5.1.5 of the current .org registry agreement, please provide details of this aspect of your proposal.

    As described in C17.4 and the attachment in Section IX, Software, Registry Advantage will utilize a DNS infrastructure that does not rely on zone files as used in BIND and other traditional DNS server software. In order to provide end-users with a reliable and responsive DNS infrastructure, Registry Advantage will deploy DNS servers in a number of locations, including those referenced in C17.1:

  • New York;
  • San Jose;
  • Hong Kong; and
  • London.

    Additionally, Registry Advantage will deploy DNS servers at its secondary site and will use an RFP process to select at least three additional locations for DNS servers. Sites would be selected in order to improve the overall geographic and network diversity for the .org DNS service. It is currently anticipated that one of these locations will be deployed in each of the following regions:

  • Asia/Pacific;
  • Central region of the United States; and
  • Europe.

    At any given time, the DNS cluster at either the primary site in New York or the secondary site will act as the “master” cluster. (The master cluster is the one adjacent to the active database and shared registry service, so if the New York site is providing the active shared registry service, the DNS cluster in New York will be the master.)

    The master will be responsible for keeping distributed logs, issuing warnings to operators, initializing new servers in the other clusters, and zone data propagation. In the event of catastrophic master failure, the satellite clusters will still continue to operate. It will be possible to retrieve configuration information from them once the master is rebuilt.

    The master will also distribute updated zone information to the satellite clusters. All communications between the master and satellite clusters will be encrypted for security. Updates received by an individual node within a satellite cluster will be distributed to the rest of the servers within that cluster. As indicated in C17.4, the Registry will tune communications parameters so that changes generally propagate to all clusters within five minutes.

    Registry Advantage’s system employs advanced DNS software developed at, which achieves accelerated response times, rapid zone information updates, and improved fault tolerance. (Please refer to C17.1 for detail.) In developing this software, leveraged its considerable experience in providing authoritative DNS services for over three million domain names and specifically designed this software to create a highly scalable and available DNS infrastructure. Registry Advantage has built on this base of knowledge in creating its infrastructure and software to support the .org registry on behalf of RegisterOrg.

    As indicated in C17.4, this entire DNS infrastructure will be backed up by a parallel system of DNS servers running BIND. Once a day, zone files will be generated (from the same location as the master DNS cluster) and distributed to all BIND servers via a secure, authenticated network layer protocol such as SSL. After performing integrity checks on the received data, BIND will reload on these remote systems in a staggered manner so that no fewer than half are active and ready to respond to queries at any given moment.

    In addition to distributing zone data to its own DNS servers, Registry Advantage will also make limited use of VeriSign’s DNS constellation for several weeks immediately following the transition of registry operators. Initially, VeriSign will continue to use the last zone file generated during its tenure, so no zone file distribution will be required, but once the Registry begins to reliably generate zone file data, it will become necessary to propagate this data to VeriSign.

    Registry Advantage proposes to periodically transmit zone file data to VeriSign either through the DNS protocol itself using such mechanisms as AXFR or IXFR, or by periodically using a file transmission mechanism such as FTP or SSH/SCP. The specific details for transferring this zone file data will be negotiated with VeriSign in the event the .org registry is redelegated to RegisterOrg.

    For more details regarding the use of the VeriSign DNS constellation, see C18.1 and C18.5.

    C17.6 Billing and collection systems. Technical characteristics, system security, accessibility.

    Billing of registrars is critical to the financial stability of the registry. Strict processes are in place to ensure the least amount of disruption to registrars and the maximum security to the registry.

    RegisterOrg will subcontract with Registry Advantage to provide billing and collection services. The decision to subcontract this service to Registry Advantage was made due to Registry Advantage’s extensive experience operating billing and collection systems for existing registries and registrars. RegisterOrg will audit its subcontractor to ensure appropriate billing practices.

    To minimize the potential for disruptions caused by changes to billing procedures during the transition, RegisterOrg will adopt a billing procedures that are similar to those used by VeriSign, albeit with some improvements to accessibility and reporting capabilities. As is the case for the existing .org registry, registrars will receive monthly invoices, have secure access to reports through an Account Management Interface (AMI) and maintain letters of credit on file with the registry. There will be no requirement for registrars to pay using credit or debit cards and hence risk incurring additional processing fees or interest charges from credit card companies and banks.

    Billing Process

  • Each registrar would provide a letter of credit on which the Registry can draw in the event of non-payment of domain registrations.
  • On behalf of the Registry, Registry Advantage will monitor the volume of registrations daily and make a report available to the Registry. If the monetary value of registered names exceeds 80% of the letter of credit, the Registry will contract the registrar. The registrar can increase the letter of credit or make a pre-payment to maintain an acceptable credit balance. Once the credit limit has been reached, the registry will shut off such registrar’s ability to register further names. This would prevent the Registry from having to delete unpaid names or for registrants to rely on a registrar that may be experiencing financial problems.
  • The Registry will send bills to registrars on a monthly basis for the previous month’s registrations. At the end of the billing period, the Registry will compile registration data for each registrar and create an invoice. The data would be available either by the Registry sending paper or electronic documents to the registrar, or by posting the data on a secure FTP site.
  • Registrars are expected to pay the invoice in full upon receipt. Upon receipt of payment, the Registry will update such registrar’s account and send confirmation of the registrar’s credit balance.

    In some cases, registrars may make partial payments pending minor disputed amounts relating to a small number of names. In these situations, the Registry would coordinate with the registrar to answer questions and obtain payment for outstanding invoice amounts.

    If a registrar were not to pay, the Registry would shut off such registrar’s ability to register names. The Registry could draw on the letter of credit to pay outstanding amounts; in extreme delinquencies, the Registry may delete the names in question.

    Account Management Interface (AMI)
    AMI will provide a secure web-based portal with the following functions:

  • Setting up and administrating registrar accounts (e.g. a registrar would have a master login account and can grant additional accounts to select employees);
  • Registration transactions, similar in functionality to those provided via the RRP or EPP interfaces; and
  • Registration transaction reports and on-line account statements.

    The Registry is subcontracting with Registry Advantage to carry out invoicing and collections responsibilities. Registry Advantage will be responsible for invoicing registrars, collecting from them, and sending the collections to RegisterOrg’s account.

    The letter of credit from each registrar would be held by RegisterOrg.

    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.

    All Registry data is continuously replicated to two standby database instances. Registry Advantage also stores backups at off-site locations, including a Data Escrow provider.

    Back Up
    The .org registry will be protected by a variety of data backup and escrow mechanisms, ranging from the real-time replication of critical data to a comprehensive traditional tape backup scheme, and also including full third party data escrow.

    The Registry will replicate most important data in real time. Using Veritas Global Cluster Manager and the Global Application Data Synchronization Framework, the Oracle database will be replicated from the active site (see the definition in C17.3) to the backup site. Application data will be copied to both the active and backup sites before moving from development to production systems. This duplication of data allows for failover procedures to provide a mechanism to resume the operation of the registry at the alternate site in the event of a failure at the active site.

    At the primary site in New York, a secondary storage array will also back up the active database. As described in C17.3, redo logs will be copied from the active database server to the separate storage array used by the standby database server. These logs are used to bring the standby database instance up-to-date at one-minute intervals. In the event of a failure of the active storage array, the standby database server can become active and resume all database functions.

    Two additional mechanisms will be employed to back up database information to tape, using AIT3 tape libraries as described in Attachment 10. First, logical backups will be made of the complete database daily. Second, complete physical backups of all .org database information will be performed on a daily basis at the primary site; at the secondary site in Asia, complete physical backups will be performed on a weekly basis complimented by incremental backups on a daily basis.

    Application and log data will be stored to tape on a similar schedule to physical data backups for the database. This information will be completely backed up to tape on a daily basis at the primary site. At the secondary site, complete weekly backups will be complimented by daily incremental backups. The Registry will use Veritas Net Backup software to facilitate the restoration of data in accordance with disaster recovery procedures. Sets of tapes will be rotated to secure off-site locations on a regular basis.

    Escrow Services
    As required by Attachment S of the registry agreement between ICANN and RegisterOrg, the Registry shall deposit into escrow all registry data on a schedule to be agreed with ICANN ((i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week) and in an electronic format mutually approved by the Registry and ICANN. The escrow shall be maintained by a reputable independent escrow agent. Registry Advantage’s expense of the escrow arrangement is included in its sub-contract fee to RegisterOrg. Registry Advantage has already identified an independent escrow agent to provide similar services for the .pro TLD; this same escrow agent can also be used for the .org data.

    Per Attachment S, the use of the escrow data will be limited to verification that the deposited data is complete and in proper format to protect the privacy of the data. The data would be released to ICANN upon the occurrence of one of the events and per the terms described in Section 9 of the Registry Data Escrow Agreement (Attachment S of the Unsponsored TLD Agreement (“model registry agreement”), which provides the template for the ICANN-Registry Agreement) termination of the registry agreement or in the event of an applicable court order or subpoena. Further details about data escrow would be modeled on Attachments R and S to the model registry agreement.

    C17.8 Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

    Registry Advantage will provide a robust Whois service supporting a variety of query types. The Whois service supports over 800 queries per second, compared to an expected peak requirement of 350 queries per second.


    Through Registry Advantage, RegisterOrg will make available a centralized, shared and publicly available Whois service at its site in New York as well as at the secondary location, with access to the Internet connectivity and infrastructure built to support all of the .org registry functions. This service will utilize a custom Whois server application based on the Whois application developed by This robust application provides Whois service for over three million domain names and answers approximately 500,000 queries each day. The Registry, through Registry Advantage, will deploy load-balanced clusters of Intel x86-based hardware (described in C17.1) able to handle tens of millions of queries per day. While only a small number of servers are needed to accommodate anticipated load, the Registry will deploy additional hardware to insure complete fault-tolerance within the system. Updates will be propagated from the database to the Whois service in near real time when domains are registered or modified.

    Initially the Registry will operate in a “thin” mode, meaning that only a limited set of data will be stored in the Registry’s database and made available through the Whois. RegisterOrg proposes a gradual transition to a “thick” registry in which a complete set of Whois data is stored by the Registry in one central location, allowing for more effective and efficient search capability. For further details regarding the transition from thin to thick registry operations, please refer to Question C22.

    For queries relating to domain names, the publicly available .org Whois service will respond to requests for a single domain name and will generally provide back the following information:

  • Domain name;
  • Registrar information;
  • Name servers (if any);
  • Registrant information*;
  • Administrative and technical contact information*; and
  • Date of registration, date of last modification, date of expiration.

    * These fields are only available in the “thick” Whois mode.

    Queries may also be performed on name server, registrar, and contact (when applicable) objects. Details regarding these queries are provided below.

    Once the transition from thin to thick registry operations has been completed, data can be presented in a standard format for domains registered by any registrar. However, in order to accommodate local privacy laws, the registry will provide a mechanism for certain data from individual domains, or possibly across entire registrars, to be “masked” and made unavailable to the public. The specific fields that can be masked will be determined by RegisterOrg and Registry Advantage in collaboration with ICANN, based on current ICANN policy.

    Registry Advantage’s Whois service is made available through the port 43 Whois protocol. The Whois protocol is defined in RFC 954 and Registry Advantage will ensure that its Whois server operates according to the protocol defined therein on behalf of RegisterOrg. RFC 954 describes the Whois protocol as follows (note that while the protocol specification references SRI-NIC specifically, it may be applied to other registries, such as the .org):

    To access the NICNAME/WHOIS server:

    Connect to the SRI-NIC service host at TCP service port 43 (decimal).

    Send a single “command line”, ending with (ASCII CR and LF).

    Receive information in response to the command line. The server closes its connection as soon as the output is finished.

    Query Syntax
    The command line transmitted by the client must be in the following format:

    [type =] query

    In the syntax above, arguments indicated in italics are keywords that must be replaced by particular values as described below. Portions of the syntax contained within [square brackets] are optional.

    The following type keywords are used to indicate that the query applies to a specific object type:


    Search only domain objects. The query string is searched in the Name field. The format of the results of this type of query is described below.


    Search only nameserver objects. The query string is searched in the Name field and in the IP address field. The results of this type of query will be consistent regardless of the parent domain and are described below.


    Search only contact objects. This type of query may be performed only after thick registry operations have begun. The query string is searched in the ID field. The results of this type of query will be consistent regardless of the associated domain and are described below.


    Search only Registrar objects. The query string is searched in the ID field. This type of object can only be associated with domains in the extended .org name space. The format of the results of this type of query is described below.

    If the optional type keyword is not provided, the default behavior is to search only domain objects as if the “Domain” keyword had been specified.

    The query provided must be an exact match for the Name (fully qualified), ID, or IP address field of the object being searched for (as specified above). The query is considered to be case insensitive. All queries will return at most a single result, except nameserver queries based on IP address, which may return multiple results if the same IP address is associated with multiple name server names.

    The server will return two varieties of responses: errors, and successful query results. All lines in an error result will be preceded by the string “%%”. The rest of the line will contain freeform text describing the error condition. Each line will be terminated by . The number of lines and length of each line is variable.

    An example of an error result is below:

    %% No match.

    The other type of response is a successful query result. Three types of lines may be contained within a query result: comment lines, blank lines, and data lines. The first character in a comment line is the character “#”. These lines contain information that is not intended to be parsed by machines and may contain statements of registry policy, status information regarding the Whois service, or other freeform messages. These lines should always be displayed by Whois client software. Blank lines contain no data or only white space and are presented only for visual formatting purposes; they should also be ignored by parsers. Data lines are formatted in key/value pairs to facilitate machine readability. The format of data lines is the key, followed by the character “:”, followed by a space, followed by the data. All lines are terminated by .

    Domain Query Response
    Domain queries will return different types of responses based on whether a thin or thick set of data is stored for that domain name. Fields in boldface below may appear more than once. Fields in italics are optional and may not appear. For those domain names with only a thin set of data, the following fields will be returned in response to a Whois query:

  • Domain Name
  • Sponsor ID
  • Sponsor Whois Server
  • Sponsor URL
  • Nameserver
  • Updated Date

    For those domain names with a thick set of data, additional fields will be returned in response to a Whois query, and the “Sponsor Whois Server” field will not be returned. The total fields present in a response to a domain with a thick set of registry data are as follows:

  • Domain Name
  • Sponsor ID
  • Sponsor URL
  • Registrant ID
  • Registrant Name
  • Registrant Organization
  • Registrant Address
  • Registrant City
  • Registrant State/Province
  • Registrant Country
  • Registrant Postal Code
  • Registrant Phone Number
  • Registrant Fax Number
  • Registrant E-mail
  • Admin ID
  • Admin Name
  • Admin Organization
  • Admin Address
  • Admin City
  • Admin State/Province
  • Admin Country
  • Admin Postal Code
  • Admin Phone Number
  • Admin Fax Number
  • Admin Email
  • Tech ID
  • Tech Name
  • Tech Organization
  • Tech Address
  • Tech City
  • Tech State/Province
  • Tech Country
  • Tech Postal Code
  • Tech Phone Number
  • Tech Fax Number
  • Tech Email
  • Nameserver
  • Updated Date

    Sample input and output for a successful query for each type of domain is provided below. The first example is a domain with a thin set of registry data


    whois “domain =”


    Domain Name:


    Sponsor URL:

    Nameserver: NS1.MYISP.ORG

    Nameserver: NS2.MYISP.ORG

    Updated On: 22-Feb-2003

    The second example demonstrates sample output for a successful query on a domain with a thick set of registry data:


    whois “domain =”


    Domain Name:


    Sponsor URL:

    Registrant ID: JD1325

    Registrant Name: Jane Doe

    Registrant Address: 345 Storybook Lane

    Registrant City: Littletown

    Registrant State/Province: KS

    Registrant Country: US

    Registrant Postal Code: 66645

    Registrant Phone Number: (800) 555-5555

    Registrant Email:

    Admin ID: JD1324

    Admin Name: John Doe

    Admin Address: 123 Anyplace Street

    Admin City: Anytown

    Admin State/Province: NY

    Admin Country: US

    Admin Postal Code: 12345

    Admin Phone Number: +1.845.234.5678

    Admin Email:

    Tech ID: JD1324

    Tech Name: John Doe

    Tech Address: 123 Anyplace Street

    Tech City: Anytown

    Tech State/Province: NY

    Tech Country: US

    Tech Postal Code: 12345

    Tech Phone Number: +1.845.234.5678

    Tech Email:

    Nameserver: NS1.MYISP.ORG

    Nameserver: NS2.MYISP.ORG

    Updated On: 22-Feb-2003

    Contact Queries
    The following lines may be present in the response to a query for a contact object:
    · Contact ID
    · Sponsor ID
    · Sponsor URL
    · Name
    · Organization
    · Address
    · City
    · State/Province
    · Country
    · Postal Code
    · Phone Number
    · Fax Number
    · E-mail
    · Updated Date

    Sample input and output for a successful query is provided below:


    whois “contact = JD1234”


    Contact ID: ORG-CNT-JD1324

    Sponsor URL:

    Name: John Doe

    Address: 123 Anyplace Street

    City: Anytown

    State/Province: NY

    Country: US

    Postal Code: 12345

    Phone Number: +1.845.234.5678


    Updated On: 22-Feb-2002

    Name Server Queries
    The following lines may be present in the response to a query for a name server object:
    · Nameserver ID
    · Sponsor ID
    · Registrar URL
    · Server Name
    · IP address
    · Updated Date

    Sample input and output for a successful query is provided below:


    whois “nameserver =”


    Host ID: US-HST-123


    Sponsor URL:

    Server Name:

    IP Address:

    Updated On: 22-Feb-2002

    Registrar Queries
    The following lines will be present in the response to a query for a Registrar object:
    · Registrar ID
    · Registrar URL
    · Registrar Whois Server
    · Address
    · City
    · State/Province
    · Country
    · Postal Code
    · Phone Number
    · Fax Number
    · E-mail
    · Updated Date

    The “Registrar Whois Server” field will be phased out once the Registry includes only domains that have a thick set of registry data.

    Sample input and output for a successful query is provided below:


    whois “Registrar = ORG-REG-FICTIONAL”



    Registrar URL:

    Registrar Whois Server:

    Address: 678 Mark Twain Lane

    City: Florida

    State/Province: MO

    Country: US

    Postal Code: 24760

    Phone Number: (573) 333-3333


    Updated On: 22-Feb-2002

    Abuse Prevention
    To prevent the abuse of the Whois database, the IP addresses of incoming requests will be logged. In the event that an excessive number of requests from a specific IP or network are made, the Whois servers will temporarily block additional requests from the same IP address or range.

    Bulk Access
    In addition to the publicly available Whois information, the Registry will provide bulk access to a limited subset of this information to individuals or organizations that agree to specific terms of use. This bulk access is governed by the registry agreement between ICANN and RegisterOrg (see attachment, C50.6, RegisterOrg) thereto. Bulk access at the registry level will include only the following information:
    · Domain name;
    · Sponsor ID; and
    · Associated nameservers (if any).

    Bulk access to additional information may be provided by individual registrars, as per ICANN policies and in accordance with applicable law.

    C17.9 System security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

    Robust security is an element in every part of the Registry’s system design. Each user’s access to the system is strictly limited.

    Due to the critical nature of .org registry data, Registry Advantage will conduct all of its operations with significant attention to security, in conjunction with existing security practices. All Registry Advantage systems are designed to provide the RegisterOrg with world-class security at every level.

    Physical Security
    All registry database and shared registration services are operated in extremely secure hosting facilities. The following physical protections are used throughout data center facilities: use of 24-7 guard service, alarm systems, several layers of physical barriers, and use of biometric identification devices.

    Generally, positive identification is required of all personnel entering and exiting the facility. Data center floors are isolated from areas in which visitors are commonly allowed. Each data center tenant is separated from others by steel cages, and movements within the data centers are carefully monitored.

    In addition to preventing unauthorized persons from accessing the registry systems, the robust infrastructure has significant fire suppression, flood, earthquake, and even radiation resistance. The robust physical plant is intended to minimize the chance of unexpected events from impacting the registry’s operations.

    Network Security
    Registry Advantage employs a number of measures to prevent unauthorized access to its network and internal systems. Before reaching the registry’s internal network, all traffic passes through a firewall system. Packets passing to or from the Internet are inspected, and unauthorized or unexpected attempts to connect to the registry’s servers are denied and logged. The registry’s routers also act as the first line of defense against any denial of service attacks, with the ability to instantly deny traffic from a specific host, network, or even an entire Internet Service Provider. Refer to the network diagrams (Question C17.1) for details of Registry Advantage’s network infrastructure.

    Front-end registry servers (such as the SRS, Whois and name servers) sit behind a second layer of network security provided by load balancing equipment. The hosts use RFC 1918 reserved address space that is not routable on the public Internet. Packets destined for specific services such as DNS or the registry’s SSL-protected applications are translated only after being subjected to additional security checks; suspicious traffic is dropped before being translated and will not reach the servers. Additionally, front-end systems are arranged into load balanced clusters; even if an attack is successful on an individual host, subsequent requests by the attacker will reach other servers, making it extremely difficult to take advantage of any weakness. Critical internal systems, such as database and file servers, also have non-routable IP addresses, and absolutely no traffic is permitted to reach them from the public Internet.

    Registry Advantage also operates a network-based intrusion detection system (NIDS) at both the primary and secondary site. The NIDS monitors the network for suspicious activity. If possible malicious activity is detected, appropriate personnel will be notified immediately.

    In addition to traditional stateful inspection and border ACL levels of security, Registry Advantage utilizes state-of-the-art Denial of Service (DoS) and Distributed Denial of Service (DDoS) prevention techniques, including advanced flow setup throttling and aggressive session table management. Especially susceptible to DDoS attacks are UDP based services such as DNS. However, Registry Advantage has worked extensively with its firewall vendor, NetScreen, to provide unprecedented protection against these attacks on DNS services specifically by helping to design UDP state building rules using layer 7 DNS information. With the NetScreen advanced state building rules, DDoS attack packets targeting the Registry Advantage DNS UDP service are dropped at the firewall, before they reach the internal access network.

    Server Security
    Registry Advantage employs a set of security precautions to ensure maximum security on each of its servers. Although specific procedures vary based on operating system, specific function of the host, and other factors, minimum standards on each server include:
    · Disabling all unnecessary services and processes;
    · Regular application of security-related patches to the operating system or critical system applications;
    · Installation of tools such as SYN cookies to prevent denial of service attacks;
    · Use of host based intrusion detection tools and log file analysis to ensure the ongoing integrity of each system; and
    · Accounts on all production systems are only assigned to a limited set of administrative personnel. Developers, customer service employees, and others will not have login accounts on these servers.

    Application Security
    In addition to following commonly accepted security standards for application design and operation, Registry Advantage subjects its code to rigorous internal security audits on a periodic basis. Additional security for the infrastructure as a whole is increased by Registry Advantage's custom DNS and WHOIS server implementations. These remove the possibility of being susceptible to security problems that may exist in the freely-available software products. The IETF has already noted that heterogeneity within the global DNS architecture is a benefit - RFC 2870, section 2.1 states, "It would be short-sighted of this document to specify particular hardware, operating systems, or name serving software. Variations in these areas would actually add overall robustness".

    Protocol Security
    The security mechanisms used to protect registry-registrar functions are discussed in Question C17.2. These measures are intended to prevent unauthorized access, and in the future, the Registry may also introduce a unique digital signature for each database object, making it extremely difficult for an attacker to tamper with the registry’s data.

    Access to Systems
    The Registry will provide highly differentiated system access to different classes of users. Each user will be provided with access to only those functions and portions of the registry data that are required by that user. Although specific policies will be implemented for each class of user and each service or machine, a general outline of access restrictions follows:

    • Registrars
      • Read/write access through both the SRS and Account Management Interface to all domains and other objects sponsored by the registrar.
      • A limited set of information (similar to that provided to the general public) will also be accessible for those domains sponsored by other registrars.
    • Registry Advantage employees
      • Customer Service representatives: Read-only access to the entire registry database; ability to perform certain pre-defined functions such as undeleting domains that are within the delete pending period.
      • Software developers: Access only to development and staging environments. No access to production systems.
      • System administrators: These are the only employees with logins directly on the registry’s production servers.
      • Accounting and other business functions: Access to reporting capabilities similar to those provided to registrars, but with the ability to access the data for the entire registry.
    • RegisterOrg employees
      • Access to reporting capabilities similar to those provided to registrars, but with the ability to access the data for the entire registry.
    • Zone file and Bulk Whois agreement signees
      • Access only to the appropriate distribution server. The only function that these users will be able to perform will be to initiate the download of the appropriate file.

    C17.10 Peak capacities. Technical capability for handling a larger-than-projected demand for registration. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.

    All of Registry Advantage’s systems are capable of handling significant surges in demand. Based on extensive tests and comparison with historical public data, Registry Advantage’s systems can handle three times the expected peak loads on SRS, DNS and Whois services.


    Registry Advantage has taken a number of steps and precautions to ensure that its systems are capable of dealing with larger than expected surges in demand, even though it is unlikely the transition of the .org registry will be accompanied by the same kind of initial surge in demand that became commonplace with the opening of new gTLDs.

    Registry Advantage has already designed and built systems to accommodate a registry of the size and importance of the .org TLD. To validate the current capabilities of its systems, Registry Advantage performed a series of load tests on its SRS, DNS and Whois services. With the goal of enhancing the external validity of the tests, the entire .org dataset was loaded into the registry database and test queries were generated from this dataset. The hardware, network and software configurations used for the testing matched those already in place at Registry Advantage’s primary data center, and the configurations also matched those proposed for the .org registry.

    Expected test results were established prior to running the tests, based on several triangulated inputs. The purpose of this was to extrapolate and predict the expected typical and expected peak loads on the SRS, DNS and Whois services for the .org registry. Information from ICANN advisories, SnapNames’ State of the Domain reports and data supplied by VeriSign to the North American Network Operator's Group were combined with data drawn from Registry Advantage’s experience as a registry outsourcing provider to analyze and predict the expected volumes. For example, the expected peak for SRS checks per second was estimated using data from the ICANN “add storm” advisory , which related to the full com/net/org dataset. These numbers were scaled based on the portion estimated by Registry Advantage as related to the .org domain . A full description of the test results and methodology is attached in Section XI, Test Results.

    The SRS tests included queries of all the major types (adds, checks, infos, deletes) combined into test sets that were representative of ‘typical’ loads as well as atypical ‘add storm’ loads. The Whois and DNS tests covered a range of .org query mixes (successful queries, failed queries, malformed packets, etc.) conducted in a random order to determine maximum queries per second.

    The table below summarizes the major results attained in the testing. It is important to note that the number of servers in the SRS test cluster were actually fewer than the number proposed for .org (3 servers instead of 6 servers), yet the performance of the 3 servers alone exceeded expected peak capacity in all cases. Across all parameters and tests, performance significantly exceeded both the expected typical and expected peak levels as determined from the publicly available data about the .org TLD.


    Expected Typical

    Expected Peak

    Current Capability





    DNS queries/second/POP




    Whois queries/second/cluster








    SRS checks/second




    SRS successful adds/second




    SRS changes/second




    SRS deletes/second




    SRS infos/second




    SRS connections/server




    Translating the SRS performance capability numbers into hourly peaks, Registry Advantage’s SRS servers are capable of up over 3 million checks per hour, in addition to the successful registration of over 655,000 new domain names in the same one-hour period.

    These levels of capacity and redundancy mean that, even in a scenario where one or more components fail at the same time as increased registration volume, the systems will continue to process expected peak registration volumes. In the unlikely event that additional hardware is needed, Registry Advantage can re-deploy hardware on an emergency basis to accommodate larger-than-expected demands on the system during the initial months of operations. For example, if database resources are under strain, processors and memory can be moved from the standby Sun E-6500 to the active database server. This configuration leaves the primary site with only active and backup database servers, but given the other layers of system redundancy described in C17.1 and C17.3, this is an acceptable contingency for a short period of time. In the event that the SRS front-end systems become a bottleneck, servers from Whois and name server clusters can be moved to the SRS cluster, as these other services will be under relatively lower load during the initial months of the .org registry’s operation.

    To monitor and manage peak loads in real-time, Registry Advantage will utilize state-of-the-art performance management and profiling tools. These tools are capable of modeling performance and correlating application work loads with specific infrastructure components and component sets. Peaks in various application workloads can be modeled and their impact anticipated with operational responses, including adding hardware in key areas of the infrastructure and modifications to logical storage layouts to avoid disk I/O bottlenecks.

    Registry Advantage will use its performance monitoring tools to carefully manage the transition during the first few weeks of registry operation. As described in section C18.1, the Registry plans to pursue a cautious approach with the transition. The proposal is to gradually ramp up the operation of the SRS over the course of a week in order to prevent the system from being overloaded by pent-up demand at the time of launch.

    It is also worthwhile to note that Registry Advantage plans to use extremely common Intel x86-based servers in all of its front-end systems. This hardware is nearly ubiquitous within the market and it would be extremely straightforward to obtain additional servers if needed. The use of layer 4 load balancing techniques as described in Section C17.1 makes it simple to rapidly move additional servers into a cluster. Although the Sun Enterprise hardware used for database servers is not as common, it is widely available and additional hardware could be readily obtained if necessary. The initial database server configurations allow for significant additions of CPUs and memory within the E-6500 systems that Registry Advantage will deploy.

    As mentioned above, the full .org dataset was loaded into the database to test the DNS, Whois and SRS applications using real data. Loading the full dataset also provided the opportunity to confirm that other parts of the registry system, such as the database, storage, backup and escrow functions can handle this size of dataset. These systems are more than adequate for the 2.7 million names in the .org dataset. Indeed these systems can support at least 20 million names using the proposed hardware configurations. Considering potential growth, it is worth noting that these systems are taxed by a large number of total domains registered, and not by high day-to-day or hour-to-hour volumes. Short-term surges in registration volume should not affect these systems. If long-term registration projections do not adequately anticipate the growth of the .org TLD, these components can be upgraded well in advance of their limits being reached. Whois and name servers use a clustered approach, which allows the easy addition of inexpensive new hardware as the capacities of the system are reached. Once again, storage and backup systems have been engineered to accommodate expected volumes for over twenty million active domain names, with the Whois servers capable of handling millions of queries per day and the name service infrastructure capable of handling over 100,000 queries per second.

    C17.11 Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.

    Overview RegisterOrg intends to outsource most billing, customer and technical support for the .org registry to Registry Advantage. Problems and questions from registrars will be initially handled by the Registry Advantage Customer Support Center. The Center staff will attempt to identify and diagnose the cause of any problems and rectify them. Registry Advantage anticipates that the customer support team will be able to address any billing and customer support issues, as well as many technical issues. Some technical problems may be beyond the capabilities of the Center’s staff to resolve directly. In these cases, they will promptly escalate the issue to specialized technical staff (for example, network engineers or database administrators) for resolution. Any problems reported by RegisterOrg or any .org registrars will be tracked through a ticketing system so that Registry Advantage can monitor issue resolution and timing.

    Certain problems or questions from registrars related to the registry-registrar agreement or RegisterOrg initiatives outside the Registry Function for and with registrars may be more appropriately addressed directly by the RegisterOrg. If such questions come in through the Service Center, they will be referred to RegisterOrg.

    Ticketing System
    In order to track customer service issues, the Registry would operate a trouble ticket system. A ticket would be created at the time of each new contact between registrars and the Registry. This system would provide customer service representatives with the ability to categorize, assign priorities to, and update trouble tickets to ensure that issues are routed to the appropriate personnel.

    Major capabilities of the ticketing system include: · Automatic assignment of tickets to specific personnel based on problem type;
    · Notifications generated when tickets are opened, modified or closed;
    · Notifications to registry personnel generated when open tickets approach their expected service resolution times;
    · Tracking of outages for SLA purposes; and
    · Generation of reports on the status of all open tickets as well as trouble ticket histories.

    The Registry will seek to proactively notify customers of problems as they occur. Contact would generally be made through e-mail; however, if the scope of a technical problem affects the Registry’s capacity to send e-mail messages, an attempt would be made to contact registrars by telephone or facsimile. Registrars would be notified well in advance of planned maintenance events and invited to provide feedback regarding the Registry’s technical operations on a regular basis.

    The Registry will provide urgent notice of any catastrophic outage or disaster recovery involving critical operations to the registry, and will follow up with regular reports by a senior registry systems engineer as long as needed. Systems outage involving non-critical operations to the registry shall receive similar regular, but less frequent, reports as long as needed.

    Hours of Support
    Technical support services will be provided on a 24-7 basis, 365 days per year, in order to equally accommodate registrars around the world. Although English will be the primary support language, Registry Advantage’s staff can communicate in several common languages, and will continue to seek diverse language capabilities among the additional staff hired to manage .org operations.

    Customer and billing support services for non-critical issues will be provided Monday through Friday during regular business hours (Monday through Friday, 9 a.m. to 5 p.m. EST, excluding holidays).

    Access to Sensitive Data
    Access by Registry Advantage or RegisterOrg to sensitive registrar critical data will be limited. Read-only status will be available to help desk entry-level employees or outsource employees for such data in order to prevent inadvertent changes to registrar records. Support staff will be prohibited from providing information about other registrar’s operations. For further details, please see the security description in C17.9.

    Customer Service Issue Resolution Process Registry Advantage has developed a complete issue resolution process for registrars—from ticket opening to ticket closure. The Registry Advantage Customer Support Center has established the following process to respond to inquiries most effectively and efficiently:
    1. When the registrar contacts the Center to report a problem or make a request, a service request is opened and a ticket number assigned. The Center has an internal ticketing process to track progress toward resolution.
    2. The first contact with the Customer Support Center is with a member of the Registry Support Team. To help expedite the customer ticket, the Team asks for account and contact information along with a description of the problem or service request. If required, additional technical information may be requested and security procedures used to verify the identity of the caller.

    Average Callback Times
    When Registry Advantage receives an e-mail or fax service request, the Center contacts the customer, based on the initial incident priority (on a scale of 1 to 4). Average callback time, by priority, is:
    1 20 minutes
    2 1-business hours
    3 6-business hours
    4 24-business hours

    Average Resolution Time
    The goal is to provide each customer with a rapid response and resolution to the inquiry, but depending on priority (on a scale of 1 to 4) the following guidelines can be used:
    1 2 business hours
    2 1 business day
    3 2 business days
    4 3 business days Ticket Prioritization All incoming tickets will receive prioritization based on the reported problem. Registry Advantage reserves the right to adjust the severity of an issue. Priority 1: A Priority 1 ticket is the highest priority within the Support Center system. The Center makes every reasonable effort to ensure that the customer is operational as soon as possible. Registry Advantage is in continuous contact with the customer until the problem is resolved. Typical Priority 1 issues include the following: · System inoperative; · Domain Name resolution impacted; · Registration activities impaired; · Letter of credit limit has been reached; · Registrar access to registry service is limited; and · Serious installation or upgrade issues (if they seriously impact progress towards completion and/or production dates).

    Priority 2: Typically a Priority 2 ticket is for a problem that prevents the registrar from completing non-registration business but does not cause the registry or a registrar’s use of the registry to become completely inoperable. The Center makes every reasonable effort to resolve the reported problem as soon as possible. Typical Priority 2 issues include the following:
    · Reports will not run
    · Performance problems
    · Functionality issues

    Priority 3: A Priority 3 ticket is for a problem that causes a feature or system failure that can be avoided by the customer applying alternative methods. Typical Priority 3 issues include the following:
    · Receiving error messages in the reports
    · Receiving console error messages
    · Exporting/Importing data files failing
    · Upgrade or installation planning

    Priority 4: A Priority 4 ticket is for a minor problem having only a minimal impact on the customer’s business. Typical Priority 4 issues include the following:
    · General registration questions
    · Changes to contact information
    · General billing inquiries

    Support for Registrants and Internet Users Primary support for registrants will be provided by registrars. Inquiries made by registrants directly to the Registry, either by phone or e-mail, will be referred to the appropriate registrar or possibly ICANN if the complaint is against the registrar. Similarly, neither phone nor e-mail support will be provided for Internet users.

    RegisterOrg will, however, provide a publicly available Web site with useful information for both registrants and Internet users. Information on the public Web site will include:
    · Registration policies
    · A listing of ICANN-Accredited Registrars who offer .org registrations
    · A Web-based interface to the Whois service
    · Frequently asked questions about the .org domain name

    RegisterOrg’s Web site will be designed to provide maximum utility to a broad spectrum of registrars, registrants and Internet users, including those with visual handicaps. In order to make the site broadly accessible, simple design concepts will be employed and text will be emphasized over graphics, Flash, and other visual elements.

    C17.12 Compliance with specifications. Describe the extent of proposed compliance with technical specifications, including compliance with at least the following RFCs: 954, 1034, 1035, 1101, 2181, 2182.

    Registry Advantage services comply with all relevant RFCs. In addition, Registry Advantage is an active participant in the standards-setting process.

    All Registry Advantage systems will comply with the relevant specifications from IETF RFCs. The compliance of various services is summarized in the table below:




    RFCs 1034, 1035, 1101, 2181 and 2182


    RFC 954

    SRS (RRP)[7]

    RFC 2832 or draft-hollenbeck-rfc2832bis-01

    SRS (EPP)[8]







    It is important to note that Internet standards are continuously evolving, and the Registry intends to be an active participant within the IETF and to track the changes of relevant working groups. For example, the IETF’s provreg working group is currently in the process of defining a generic registry/registrar protocol, which would be of considerable interest to both the Registry and the registrar community. Registry Advantage intends to participate in this process and to implement the standard protocols that may emerge from this group’s work. Similarly, RegisterOrg and Registry Advantage expect to be active participants in current and existing IETF working groups, such as provreg, dnsop, and dnsext. Registry Advantage is currently an active participant in IETF standards-setting activities, both through mailing lists such as NAMEDROPPERS, as well as through regular attendance at IETF meetings. As new standards that affect .org registry services are developed, Registry Advantage and RegisterOrg will work closely with ICANN to ensure compliance with all relevant standards.

    C17.13 System reliability. Define, analyze, and quantify quality of service.

    RegisterOrg defines system reliability as a function of availability, performance and accuracy. Registry Advantage will engineer its systems to meet the strict quality-of-service definitions for reliable operation of the .org registry.

    Domain-name registries provide some of the most essential functions of the modern Internet. The Internet is increasingly relied upon to perform critical functions for companies, organizations, and individuals throughout the world. These realities dictate that the reliability of a registry’s functions must approach 100% despite the constant need for upgrades to both hardware and software. RegisterOrg has taken those demands into consideration and proposes strict quality of service definitions as the basis for a best-of-breed SLA that will ensure and enforce the reliable operation of the .org registry. Registry Advantage, as a subcontractor RegisterOrg, has the capability to maintain and operate a high-availability and high-performance registry that will achieve a level of reliability that is unparalleled on the Internet today.

    The Registry defines system reliability as encompassing several interrelated dimensions: availability (uptime), performance (response time and throughput) and accuracy (correctness of query response and resultant database transactions). A multidimensional analysis of system reliability is important because a system could be available, but with performance so degraded as to be useless and unreliable. Or, a system could be available and responding quickly to queries, but with inaccurate responses to those queries or inaccurate data entries, which makes it unreliable for use. In analyzing and formulating metrics of system reliability, the Registry consequently recognizes that the measurement of reliability involves measuring availability, performance and accuracy. The following specific definitions of system reliability are proposed for each of the major services in the .org registry:

    Service description

    System reliability definition

    Shared registry service (RRP)

    The shared registry service shall be considered to be up during any minute long interval in which 95% of add, modify and delete transactions are successfully completed within 800 milliseconds and 95% of check transactions are completed within 400 milliseconds.


    The Whois service shall be considered to be up during any minute long interval in which 95% of all requests return correct data within 800 milliseconds.

    DNS (cluster)

    An individual DNS cluster shall be considered to be up during any minute long interval in which 95% of all requests to the cluster return a correct response within 300 milliseconds.

    DNS (service)

    The DNS service shall be considered to be up during any interval in which at least half of the total clusters are considered to be up.

    The quality-of-service-definitions above assume that the measurement is being made from the same network as the measured service. In order to measure the responsiveness of .org registry services from various portions of the Internet, Registry Advantage will contract with a service measurement company such as Keynote or Exodus Monitoring and Management Services to provide data regarding the performance of core .org registry functions.

    RegisterOrg will commit to these system reliability definitions in conjunction with “best-of-breed” uptime hurdle rates for DNS, Whois and SRS reliability. As explained in C17.10, Registry Advantage has the capacities in its existing systems to readily meet the exacting requirements of ICANN and RegisterOrg for system reliability and performance. C28 takes the definitions of system reliability provided in this section as the basis for describing the service level commitments that RegisterOrg will enforce and that Registry Advantage will achieve.

    C17.14 System outage prevention. Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.

    Every major component of the .org registry has been designed with significant redundancy to make a major system outage extremely unlikely.

    For critical .org registry subsystems, such as the database and storage, Registry Advantage will use highly available hardware from Sun, EMC and Network Appliance. These components are widely deployed for mission-critical applications in a variety of sectors including the Internet, financial, medical and government. The EMC Symmetrix storage arrays that Registry Advantage uses in both its primary and secondary locations feature hot-swappable drives, redundant power and cooling, RAID 0+1 protection of all data, battery-backed NVRAM to guarantee write completion, proactive monitoring of the environment and internal systems, and feature a 100% uptime guarantee backed by a $1,000,000 commitment. The Sun E-6500 database servers feature fully redundant internal power and cooling, the ability to repair or reconfigure components while the system remains online, CPU power control and hardware failure prediction. The Network Appliance and EMC ClarIIon storage arrays feature many of the same reliability features as the EMC Symmetrix, including redundant controllers and online standby drives.

    Front-end .org registry services (including SRS, Whois and DNS) use redundant clusters of inexpensive, Intel-based hardware. While individual hosts lack the complete redundancy of the Sun Enterprise hardware used for database servers, RegisterOrg will use modern layer 4 load balancing techniques to instantly remove failed servers from production should a fault arise. The load balancers that RegisterOrg will deploy allow the use of extensive health checks on both the server and the application. If a particular node fails a health check, the load balancer will not direct any additional user requests to that node. In this model, each server operates as a redundant compliment to all of the other servers in its cluster.

    All elements of the network (as described in C17.1) have been designed with redundancy in mind. All servers, storage arrays, and other production hosts will attach to the network using at least two ethernet connections. Although significantly less prone to failure than server hardware, all network components, including routers, switches, firewalls, and load balancers, will be installed in redundant configurations running in high availability mode. Generally speaking, the failure of any network element will result in a seamless failover to redundant hardware within seconds. One of the least reliable components of the network is likely to be the registry’s connection to the Internet. The Registry will address this by connecting to at least two Internet Service Providers (ISPs) at its primary location, and will use the BGP to intelligently share traffic and prevent the failure of either ISP from taking the registry offline.

    Hardware redundancy will be complimented by advanced monitoring, clustering and data replication software. RegisterOrg will use advanced software to monitor, fault-detect and recover Oracle database services at both the primary and secondary location. This software allows for the creation of flexible policies, will notify RegisterOrg personnel in the event of a failure, and allows for cascading recovery from consecutive failures. As described in the attachment (Section XI, Software) Registry Advantage’s DNS server application implements multiple layers of internal redundancy, and allows for real-time notification of system managers or other key employees in the event of a failure. Question C17.9 has described the .org registry’s security model in detail, but it is worth re-iterating that in addition to the passive protections provided by firewalls, hardened systems and robust authentication measures, Registry Advantage will actively monitor for attempted breaches in security through the use of intrusion detection systems, log file analysis, and other tools such as Sam Hain.

    In order to detect problems before they result in outages, Registry Advantage will engage in aggressive 24-7 monitoring of all .org registry systems and applications. High server loads, unexpected volumes of traffic, suspicious error messages in logs, slow responses to application queries and commands, and other telltale signs of problems to come will be automatically detected so that Registry Advantage staff can be notified and set to work correcting any potential problem. Registry Advantage will use a suite of monitoring tools to preemptively detect failures in either hardware or software components well before they develop into downtime events. Many of these detection modules also provide automated corrective actions in addition to notifications, so that potential downtime situations are averted without human intervention.

    Registry Advantage will also contract with its hardware and software vendors to obtain enterprise class third party support available for all of its mission critical components. This includes Cisco, Sun Microsystems, EMC, Network Appliance, Extreme Networks, Oracle, and IBM. Support from these entities and the monitoring systems described above will all be managed through an enterprise class systems management console and framework that can integrate monitoring and management services from many difference sources into one seamless Network Operations Center (NOC), operated by Registry Advantage's personnel.

    In addition, Registry Advantage will maintain and operate a complete replication of the production infrastructure in a parallel Quality Assurance Testing (QAT) environment. Prior to deploying any new or modified hardware or software into the production environment, these changes will be staged in the QAT environment and subjected to rigorous regression and stress testing by dedicated operations and quality control staff. This environment also allows RegisterOrg personnel to accurately replicate production conditions to help reproduce even the most obscure problems to help in the rapid resolution of any issues.

    Core RegisterOrg services will be housed within world-class hosting facilities meeting the most stringent specification. These facilities offer multiple layers of physical security combined with 24-7 monitoring, fire suppression, and redundant communications facilities. In order to ensure power availability and conditioning, UPS systems are maintained throughout the facilities, and generators have been installed for the contingency of a long-term power failure.

    In the event of a catastrophic failure at the primary site, a second site (also housed within world class hosting facilities in Tokyo, Japan, with the same characteristics as the primary site) will be able to take over full operation of the .org registry within 2 hours, and with all updates within the 5 minutes preceding the outage. (While 0-5 minutes worth of updates may be lost in this scenario, they may be recovered once the primary site is accessible.) This is among the best RTO/RPO commitments in the industry. Registry Advantage will be able to deliver on this RTO/RPO commitment by maintaining fully replicated systems in both the primary and alternate sites, and by replicating data through transaction log replication in one minute intervals, at both the Oracle level, and the front end systems level. This is discussed more fully in C17.15, and in C17.1 and C17.3 above.

    C17.15 System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.

    No single point of failure exists within the registry infrastructure. Common failure modes have been considered, and can be corrected rapidly and with minimal disruption to operations. Many failure modes result in automatic recovery with zero downtime.

    Although the extensive redundancy and monitoring described above make a major system outage unlikely, Registry Advantage has created a number of contingencies for recovery from various types of failures. Because of the complete replication of every component within the system, the highly resilient DNS network, and the multiple geographic locations, even significant downtime events should not impact the ongoing operations of the system.

    Several types of failure and the recovery mechanism are described below.

    Database Failure
    A total of three database servers and three storage arrays provide cascading fallbacks and allow the registry to recover from multiple consecutive failures. The complete design of this database redundancy is described in C17.3. The Registry will use software to detect and recover from failures in database hardware or the storage subsystem.

    In the event that the currently active database server should fail, but the standby database server and primary storage array remain operational, a simple database failover occurs. The standby database mounts the database filesystem that had formerly been used by the failed server, shuts down its standby database instance, and starts a new database instance using the primary storage array so that it can assume the role of the active database server. This is managed by Veritas Cluster Server software and recovers the database instance in less than three minutes with no data loss. This process is illustrated above.

    Storage Failure
    A description of database server modes is provided above in C17.3. Each of these database server modes is tied to a separate storage subsystem. At the primary location, the active and standby storage subsystems support the active and standby database server modes. At the alternate site, the backup storage subsystem supports the backup database server mode. Under certain failure conditions, the roles of these database servers and storage subsystems changes.

    For example, if the active storage subsystem fails, however unlikely, the standby storage subsystem becomes active. If the primary site fails—or if cascading component failures cause a site failover, or both the active and standby storage subsystems fail—the backup storage subsystem becomes active, and the alternate site becomes the active site. This is described in our responses to Questions C17.1, C17.3, and C17.14 and depicted below.

    Server Failure
    Generally speaking, the failure of an individual Whois, SRS, or name server will not result in downtime. The Registry’s layer-4 load balancers will rapidly detect these failures, stop sending requests to the failed node, and notify system administration staff, who can then repair the failed system without incurring downtime. Similarly, individual servers behaving erratically or in need of maintenance can be intentionally disabled at the load balancer and repaired.

    Cluster Failure
    In the unlikely event of the failure of an entire cluster of servers at the primary site, such as all of the SRS servers or the master DNS cluster, Registry Advantage could perform a controlled database failover from the active site to the standby site. Management software would facilitate the actual failover process. Upon completion of the failover, database operations and other registry functions would resume at the secondary site. In such an eventuality, this becomes a special case of the storage and data server related site failures described above. Registry Advantage specifically designed its server clusters to be highly redundant, however, so this scenario is extremely unlikely.

    Failure of any of the following application cluster pools in their entirety will result in a controlled site failover to the secondary site:
    · SRS: If any of the supported protocol pools failed completely;
    · AMI: If the secure web based application pool failed completely and could not be restored within a preset time specific to this application; and
    · WHOIS: If the entire set of WHOIS pools or any set of pools dedicated to a portion of the distributed cache all failed.

    Failure of any of these application clusters would not result in a site failover:
    · Cluster Masters: All registry operations can proceed without the cluster masters for extended periods of time, so a site failover is usually not required;
    · Systems and Network Management: If any of these services failed completely, short term measures can be implemented until the cluster was restored;
    · Development and Testing: Although these are critical to the ongoing operation of the registry, extended outages of these clusters could be tolerated without directly affecting registry operations;
    · QAT: Like the development and testing clusters, these clusters could be down for extended periods of time without directly affecting registry operations; and
    · DNS: The geographically distributed architecture and unique data distribution model implemented in the Registry Advantage DNS architecture allow for the entire cluster at the primary facility to fail, however unlikely, without impacting the globally distributed service.

    DNS Satellite Failure
    Satellite DNS clusters may also fail. In that event, attempting to move database operations from the primary to secondary site is neither useful nor appropriate. Instead, by altering BGP route announcements, the IP traffic originally being sent to the failed cluster will be routed to an alternate cluster, which will answer requests directed at both its own IP addresses and those previously allocated to the failed cluster.

    Registry Advantage has also been conducting research into the use of using IP “anycast” to provide its DNS system with improved redundancy and performance. Using this technique, the same IP address would be simultaneously announced from multiple PoPs, and each DNS cluster would be capable of responding directly to queries sent to any of these addresses.

    In the event that a site failed, any IP addresses in use at that location would be seamlessly re-routed to one or more other locations. In the extreme case, each DNS Satellite site announces BGP routes for all DNS PoPs and each cluster can respond directly to any query. Additionally, this architecture supports MxN redundancy by having more physical DNS Satellite sites than announced name server addresses.

    Each cluster will also have a set of non-production IP addresses that can be used to administer the hosts in the event the BGP announcements for the PoP service IP ranges were stopped for any reason. Additionally, each server in a DNS cluster has a non-routable RFC 1918 private IP address for communication with the cluster master and the other cluster members. Communications between DNS Satellite sites and the primary site hosting the cluster masters is done over an IPSEC Virtual Private Network.

    Network Failure
    The .org registry is built with extensive network redundancy. The use of high-availability techniques, such as HSRP and the spanning tree algorithm, mean that the failure of a network component will create no more than seconds of downtime before redundant equipment resumes the operation of the failed component. As described in C17.1, both the primary and secondary sites for the .org registry will have redundant connections to the Internet through diverse Internet Service Providers. Registry Advantage will use BGP to announce its space to each provider; in the event of the failure of an individual link or even an entire ISP, the Internet’s routing architecture will automatically redirect traffic through the other ISP. If both ISPs at the primary site should fail automatically, registry operations will automatically be moved to the secondary site.

    Power Failure
    All sites will be protected by both UPS systems and generators in order to ensure continuous electrical power. Sites are additionally protected with on-site power generation capabilities. Generally, these generators will come on line automatically and provide power to the facility in the event of a complete failure of the local power grid. In the event of an unexpected power failure at the primary site despite these precautions, a failover to the secondary site will allow operations to be resumed within minutes of the failure.

    Unexpected Failure
    There may be types of failure that are not currently anticipated. These failures could be catastrophic and theoretically both the primary and secondary site could be affected. In order to protect against unknown threats, several disaster recovery contingencies exist:

    Because satellite DNS clusters do not depend on either the presence of a functioning database or the continuous operation of the master DNS cluster, they should continue to operate normally even in the event of an event affecting both the primary and secondary site. Due to the importance of DNS services to the overall stability of the Internet, satellite clusters have been designed to operate nearly indefinitely even without any contact from centralized administration

    All data is backed up frequently. Physical and logical database backups are performed on a daily basis, and stored both on magnetic tape using state-of-the-art AIT3 tape backup technology and on the NFS filer. Application data is stored both on off-site development systems and is backed up on a daily basis. Tape backups are routinely moved to off-site locations, and data escrow services will be used to ensure that this information is stored and available. In the event of a catastrophic failure affecting both sites, it would be possible to restore data from tape in a relatively straightforward manner. Registry Advantage will use Veritas Net Backup to manage the backup process and to facilitate the speedy recovery of data if needed.

    Registry Advantage’s systems have been designed primarily using commonly available hardware and software. The Intel x86 hardware used in server clusters are nearly ubiquitous in today’s market, and Sun Enterprise hardware is readily available throughout the world. Even in a situation in which both the primary and secondary sites were completely destroyed, it would be possible to rebuild an operational portion of the .org registry infrastructure using relatively common components combined with stored application and database information.

    Although Registry Advantage is prepared for the possibility of having both the primary and alternate sites simultaneously destroyed, and could recover the full operation of the registry to a point in time previously moved off site on magnetic tape, the location of the alternate site and the diversity of the Internet Service Providers used at either site significantly reduce the likelihood of this occurrence. Detailed (re)construction guides and operations manuals will be stored off site along with the magnetic tapes to assist in the rapid reconstruction of the registry operation if such a need should arise, and these are audited on a quarterly basis for accuracy.

    The Fault, Configuration, Accounting, Performance, and Security (FCAPS) management procedures in operating the registry are derived from many years of IT operations and management experience, as well as procedures and guidelines taken from the British Office of Government Commerce’s Information Technology Infrastructure Library (ITIL) . All of the relevant documentation and systems governing the configuration, capacity, change and release management process is also backed up and stored at the off site location. This can be used for validation of a reconstructed infrastructure as well as providing a baseline for restoring all operational functions in the event of a major disaster where both sites were destroyed.

    The Registry has planned extensively for the possibility of losing a single database, or storage subsystem, or hosting facility, or network component, or ISP, or frontend server, or cluster, and leverages consistent technical and operational procedures for these scenarios.

    For example, the database replication between the active and the standby database servers works by log switching one per minute, archiving those logs to a staging area, and copying them to the standby system so they can be automatically applied to the standby database server (running in recovery mode). This mechanism is virtually identical to the one used for replication to the backup system, although the distance the copy needs to travel before it can be applied to the backup database server is significantly greater. The software framework used to distribute the log files and apply them to the recovery mode database server instance guarantees the proper sequencing and data integrity of the log file applications in both instances.

    In addition to the Oracle transaction logs, the same replication process copies the frontend systems’ logs to the alternate site so they can be used to recover any data lost in the Oracle log transition. The process of recovering the database (transitioning either the standby or the backup database server to become active) includes replaying the frontend system logs in addition to the Oracle transaction logs. This decreases the risk of data loss and improves the overall RPO capability.

    The operational model used for change management is also key in our recovery capability. All changes to the production applications and infrastructure undergo rigorous stress and regression testing in a Quality Assurance Testing environment, which is a complete functional replication of the production systems. Once QAT testing is completed and approved by an independent testing and quality control team, the changes will be scheduled for release into both the primary and alternate sites. The primary site is validated immediately after the change is deployed. The alternate site will be validated internally on a monthly basis; a full-site functionality test and audit, including database instance recovery from both the replicated logs and a randomly selected magnetic tape set, will be performed quarterly.

    C17.16 Registry failure provisions. Please describe in detail your plans for dealing with the possibility of a registry failure due to insolvency or other factors that preclude restored operation.

    Registry Advantage has practically eliminated the chance of registry failure by thoroughly planning and implementing its systems, processes, and staffing plans. However, to address even the most unlikely risks, Registry Advantage has several addressed the unlikely event of registry failure.

    Registry Advantage has built redundancy, backup, and security into the registry. This is documented throughout the rest of C17, in particular in C17.14 and 17.15.

    Registry Advantage will use data-escrow services to protect data from possible failures including business failures, system failures, natural disasters, and sabotage. The data in escrow would be released to ICANN per the terms of the model registry agreement. (For further detail, please see C17.7.) The registry will also encourage registrars to deposit into escrow all registrar data on a similar schedule. But as the registry will have a centralized shared database, including all Whois records listed herein, the registry’s escrow commitment will ensure the availability of accurate records in case of possible registrar failure.

    As to insolvency concerns, RegisterOrg is well-capitalized and presently maintains $10,000,000 in its account (see attachment in Section X, C50.5). Moreover,, RegisterOrg’s parent company, has cash and cash equivalents in excess of $200 million. Accordingly, RegisterOrg and Registry Advantage are capable of continuing registry operations under the most unstable of times. For a full description of’s resources, please refer to C13.6 and the securities reports (attached in Section X, C50.4, SEC Filings).


    [previous question] [next question]