Technical Plan
(Including Transition Plan)
Table
of Contents > Section III
|
|
Technical Plan |
|
||
|
Section III — Technical Plan (Including Transition Plan) PIR’s back-end registry services provider, Afilias, will provide a proven, world-class suite of services to serve .ORG registrars and registrants. This will help PIR make the .ORG registry the first to operate in the public interest, and allow PIR to deliver the highest level of customer satisfaction in the domain name industry. Leveraging expertise gained from operating the .INFO TLD, Afilias’
services will speed resolution times, increase reliability, enhance security,
protect information, and provide stability to .ORG. These services include
core functions such as conformance to registry-registrar models and protocols, Afilias has an experienced technology management team leading an expert staff of technical support, customer service, and product management specialists who assist registrars and registrants every hour of the year. This disciplined team has created well-defined processes that allow it to avoid emergencies and quickly address issues as they arise. Afilias pioneered the use of EPP, and is the registry that possesses
the most experience with it. Afilias already supports more than 800,000
.INFO domains, and has executed over 20,000 transfers to date. Afilias’
systems and technology base are standards-compliant, flexible, fault-tolerant,
and Afilias has developed a comprehensive plan to transparently migrate the
.ORG domain with no interruption to DNS or WHOIS services, and with minimal
impact on registrars. Afilias has directly relevant experience in this
area, since it helped design and test the new registry system for the Afilias’ combination of proven technology, strong leadership, customer advocacy, and operational excellence provides a solid foundation for PIR’s stewardship of the .ORG domain. The third section of the .org Proposal is a description of your technical plan. This section must include a comprehensive, professional-quality technical plan that provides a full description of the proposed technical solution for transitioning and operating all aspects of the Registry Function. The topics listed below are representative of the type of subjects that will be covered in the technical plan section of the .org Proposal. C17. Technical Plan for Performing the Registry Function 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:
Under the terms of PIR's contract with Afilias, Afilias will provide back-end registry operations for the .ORG TLD. Afilias has extensive experience in the operations of a top-level domain. Afilias owns Liberty Registry Management Services Company (Liberty RMS), located in Toronto, Canada. Liberty's speciality is the technical development and operation of registries, including the .INFO TLD and the .VC ccTLD. Afilias has entered into several long-term contracts with industry-leading firms to provide data center, globally distributed DNS, and data escrow services. The registry's Tech Support and Operations Monitoring group are located in Toronto, Canada. All registry systems will be located within IBM secure data centers, which conform to these minimum security standards:
IBM Hosting Delivery Centers are located worldwide and share modeled service offerings. Afilias currently utilizes IBM facilities in St. Louis, MO and West Orange, NJ. Due to the nature of Afilias' agreement with IBM, the .ORG registry has the option of utilizing IBM data centers in geographically separated locations worldwide. These worldwide locations include:
b. Primary Site: IBM V3 facility (Fully Managed Data Centers) Primary facilities are fully hosted solutions in V3 telco-grade, high security buildings. Only IBM staff has access to the physical environment, servers, network devices, and so on.
Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators, also in a fully redundant array, are available during extended power outages.
Server racks, cases, network cables and components are systematically labeled with color coded identifiers; minimizing the possibility of any human error during plant services work, and accelerating trouble-shooting capabilities in the event of equipment failure.
Security guards are on duty 24/7, and enforce a sign-in process where IBM staff entering the facility must be on the approved list and be accompanied by a minimum of one other IBM staff member. The entire facility is monitored by video surveillance.
c. Secondary and All Other Fail-over Production Sites: IBM V5 Facilities (Managed and Self-Managed Data Centers) All fail-over facilities are co-located in telco-grade, high-security buildings. Security guards are on duty 24/7, and enforce a sign-in process where anyone entering the facility must be on the approved list. Visitors must show legal photo ID to be granted access to each facility. Once inside the facility, visitors must use a card key and palm scanner to gain access to the data center. The registry systems are locked within cages in the data center and must be unlocked by security. The entire facility is monitored by video surveillance. Multiple air conditioning units are configured in a fully redundant array. Multiple UPS power units with battery backup provide clean and reliable electrical power. Multiple diesel generators, also in a fully redundant array, are available for extended power outages.
|
|
|
|
The specifications of the individual servers are described below. As technology improves and new hardware and systems technology becomes available, the registry intends to upgrade its servers and systems to well-tested systems at periodic intervals. i. Primary Site Shared Application Servers: The following application servers are distributed on two physical Enterprise Sun Servers for N+1 Redundancy.
Two (2) Database Servers
Two (2) Dedicated Application Layer Firewalls (VPN)
Two (2) Dedicated Database Firewalls (VPN)
Two (2) Load Balancer Switches
Two (2) Rate Limiter Switches
Two (2) Server Access Switches
Dedicated TSM (Backup System)
ii. Secondary Site: Shared Application Servers:
One (1) Database Server
Two (2) Support Services Servers (i.e. Reports)
Two (2) Enhanced Registry Services Servers
Two (2) O T &E Servers
Two (2) Server Access Switches
Two (2) Dedicated Application Layer Firewalls (VPN)
Two (2) Dedicated Rate-limiters and Database Layer Firewalls
Dedicated TSM (Backup System)
Figure 24
Figure 25
Clear separation between server and application
environments
High security levels detect and help prevent
intrusion 7x24 NOC runs best-of-breed monitoring
systems Global monitoring, customer care and escalation
systems System redundancies exist at the hardware, database, and application layer. These are explained below. i. Hardware Layer Redundancy
ii. Database Layer Redundancy The registry operates several database servers to provide redundancy. The primary registry facility houses two database servers, one being the main database (Database A) and the other being the secondary database (Database B). Any transactions committed to the primary database are automatically replicated to the secondary database. The WHOIS service will normally operate off the secondary database server, to allow optimal use of the primary server for handling registration events. In addition, the standby registry facility will house one database server, which will be constantly synchronized with the primary registry. In the event that the primary registry's main database (A) fails, the registry application will be manually switched over to the secondary database (B); following the verification of registry data by the on-call DBA. The centralized WHOIS application will continue to use the secondary database as usual. When the main database is restored, any transactions committed to the secondary database will be replicated to the primary database. If the secondary database (B) fails, the centralized WHOIS server will automatically switch over to use the primary database (A). In the event that the primary database fails, and the registry application and the WHOIS server are both using the same database (secondary), some degradation in service is expected. If the primary and secondary database at the Primary data center fail, the registry will switch over to the standby registry facility as described in "Disaster Recovery.” iii. Application Layer Redundancy
f. Systems Capacity and Scalability i. Application Layer The registry applications are designed to have stateless operation with load balancers (See “Hardware Architecture”). This permits dynamic scaling at the application layer for all registry functions. The registry applications are expected to exercise 5-6% sustained load on the currently slated application servers, with bursted loads of up to 12-13%. The registry application server will be operated with a minimum bursted capacity of 50% over sustained loads. In the event of unexpected load increase, this available overhead should permit the registry operator to promote additional application servers into production without expected degradation of service. ii. Database Layer Database servers in use will have the capacity to dynamically add additional processors and memory. As primary services will be balanced across the two main database load averages on currently slated database servers are expected to operate at a sustained 12-15% of capacity, with bursted loads of 20-25%. The database servers will be operated with a minimum bursted capacity of 50% over sustained loads. In the event of unexpected load increase, this available overhead should permit the registry operator to add additional memory and CPU to continue to scale load appropriately. In addition, the registry operator will continually monitor new advances in database clustering technologies, with the intent of incorporating such a solution when proven reliable and secure. The registry consists of two geographically separate physical facilities—the primary and the standby (secondary). These are described above in "Hardware Architecture.” In the event that the primary facility fails, the systems will switch over to use the standby facility. This is described in more detail below. i. System Impact If the registry is operating from the secondary facility, and the primary facility is restored, any transactions that have occurred and have been recorded on the secondary facility database will be replicated to the primary facility databases (Database A & B). While the registry is operating from the standby facility, some degradation in service is expected since there will be reduced hardware and single instances of both registry application and WHOIS service accessing a single Database (as opposed to accessing separate databases as they do in the primary facility). ii. Registrar Impact Any fail-over of the system between the primary and standby registry facility will coordinated with the registrar. The registrar will be provided with the logic to query the status of the registry, and be able to switch over to the operating facility (either primary or standby) as necessary. If the registrar's application has switched over to the standby facility, once the primary registry is restored, the registrar application will be able to switch back to using the primary registry. While the registry is operating from the standby facility, some degradation in service is expected since there will be reduced hardware and single instances of both registry application and WHOIS service accessing a single database (as opposed to accessing separate databases as they do in the primary facility). The registry conducts routine backup procedures. These are performed in such a way as not to adversely impact scheduled operations. A detailed description of backup and escrow procedures is provided in C17.7. Normal backups allow retention of:
The OT&E environment provides a test bed for registrars to test their client applications against a simulated registry environment before going online. The registry also uses the OT&E environment to verify client applications for potential registrars. During client development, registrars can expect the OT&E system to operate as the production environment. The OT&E environment is hosted on multi-processor UNIX servers and represents a scaled down version of the live system. Registrar reports shall be available for download via a Reports Administrative Interface. Each registrar will be provided secure, password-protected access, to the Reports Administrative Interface. A given registrar will only have access to its own reports. Daily registrar reports are maintained for each registrar for seven days. Daily reports older than seven days will be removed. Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be removed. An archive retrieval system will be available to request older registrar reports from a cold storage system and will be part of the enhanced registry services. k. Registrar-Registry Synchronization There are two methods available for the registrar to synchronize data with the authoritative-source registry. Bulk synchronization: A registrar will contact registry support and request a data file containing all domains registered by that registrar, within a certain time interval. The data file will be generated by registry support and made available for download using a secure web server. The data file will be a comma delimited file that contains all domains the registrar has registered in the time period requested—including all associated host (nameserver) and contact information. Single object synchronization via EPP: The registrar can, at any time, use the EPP <info> command to obtain definitive data from the registry, for a known object: including domains, hosts (nameservers) and contacts. There is no need to contact registry support for this synchronization method. l. Hardware and Architecture Disclaimer The registry operator may adjust the both the equipment list and systems architecture in respect of the continuing advancement of both registry functions and hardware/operating systems in the market place. Any changes therein will not adversely affect the sustained performance, reliability, stability, or security of the registry.
The new .ORG registry will conform to the latest version of the Extensible Provisioning Protocol (EPP). At the time of submission of this bid, the most current version is EPP-06, a draft version that has been submitted for ratification into an Internet standard. Since a large part of ISOC’s membership is drawn from the Internet Engineering Task Force (IETF), the registry will implement technology solutions promptly upon adoption as an Internet standard.
1. EPP Registry-Registrar Model (Extensible Provisioning Protocol) Overview: The .ORG registry implementation will feature a "thick"
model as typified by the rich object store managed by the centralized
registry. This object store can be managed by accredited registrars via the SRS interface that will be using the interface protocol specified by the January 24, 2002 IETF Hollenbeck Extensible Provisioning Protocol (EPP) drafts. As these drafts progress through the standards process, the registry will, where appropriate, ensure that the most current version of the standard is supported as outlined in the "Protocol Development/Change Management" section below.
It is the intent of this portion of the document to provide registrar operations development support staff with an overview of the EPP protocol by which they can guide their integration efforts.
The EPP specification is broken up into an extensible object design with each of the primary objects given an individual but consistent interface that meet the base EPP framework as described below:
a. Registry Protocol Highlights (EPP) i. Generic RRP Requirements (draft-ietf-provreg-grrp-reqs-06) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-06.txt
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.
ii. Base EPP Framework (draft-ietf-provreg-epp-06) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-epp-06.txt
This document describes the foundation upon which all of the specific objects (Domains, Hosts, Contacts) must adhere to in order to maintain a consistent interface. A standard registry specific extensible object management framework is also described in this document to handle any extra information need to satisfy policy or other agreements the registry may be required to sustain.
iii. EPP TCP Server (draft-ietf-provreg-epp-tcp-04) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-04.txt
This document dictates the TCP connection strategies to use and is almost identical to the existing NSI RRP implementation. Therefore, the EPP Server implementation structure will mirror the existing RRP Server design using TCP/IP and SSL to secure transport.
iv. Domains (draft-ietf-provreg-epp-domain-04) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-04.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
v. Hosts (draft-ietf-provreg-epp-host-04) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-04.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
vi. Contacts (draft-ietf-provreg-epp-contact-04) URL: http://search.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-04.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of identifiers representing individuals or organizations (known as "contacts") stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts.
vii. Supported Command Set The registry will provide the following command sets to support the Registry Service.
The command sets are described in more detail below.
viii. Greeting
An EPP server shall respond to a successful connection by returning a greeting to the client. The greeting response includes information such as:
ix. Session Management Commands
EPP provides two commands for session management: <login> to establish a session with a server, and <logout> to end a session with a server.
Login
The EPP <login> command is used to establish a session with an EPP server in response to a greeting issued by the server. A <login> command MUST be sent to a server before any other EPP command.
Logout
The EPP <logout> command is used to end a session with an EPP server.
x. Object Query Commands
EPP provides three commands to retrieve object information: <info> to retrieve detailed information associated with a known object, <check> to determine if an object is known to the server, and <transfer> to retrieve known object transfer status information.
These are described below.
Info
The EPP <info> command is used to retrieve information associated with a known object. The elements needed to identify an object and the type of information associated with an object are both object-specific, so the child elements of the <info> command are specified using the EPP extension framework.
Check
The EPP <check> command is used to determine if an object is known to the server. The elements needed to identify an object are object-specific, so the child elements of the <check> command are specified using the EPP extension framework.
Transfer (Query)
The EPP <transfer> command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the <transfer> query command are specified using the EPP extension framework.
xi. Object Transform Commands
EPP provides five commands to transform objects: <create> to create an instance of an object with a server, <delete> to remove an instance of an object from a server, <renew> to extend the validity period of an object, <update> to change information associated with an object, and <transfer> to manage changes in client sponsorship of a known object.
These are described below.
Create
The EPP <create> command is used to create an instance of an object. An object may be created for an indefinite period of time, or an object may be created for a specific validity period. The EPP mapping for an object MUST describe the status of an object with respect to time, to include expected client and server behavior if a validity period is used.
Delete
The EPP <delete> command is used to remove an instance of a known object. The elements needed to identify an object are object-specific, so the child elements of the <delete> command are specified using the EPP extension framework.
Renew
The EPP <renew> command is used to extend the validity period of an object. The elements needed to identify and extend the validity period of an object are object-specific, so the child elements of the <renew> command are specified using the EPP extension framework.
Transfer
The EPP <transfer> command is used to manage changes in client sponsorship of a known object. Clients may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request.
Update
The EPP <update> command is used to change information associated with a known object. The elements needed to identify and modify an object are object-specific, so the child elements of the <update> command are specified using the EPP extension framework.
b. Protocol Development/Change Management The IETF Provisioning Registry Protocol "provreg" working group [PROVREG] has been chartered to develop a specification for the requirements and limitations for a protocol that enables a registrar to access multiple registries. The working group will also develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications. The EPP has been proposed as a candidate for this purpose.
The initial specification will allow multiple registrars to register and maintain domain names within multiple TLDs. The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information.
The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn).
ISOC expects the activities in the working group to have significant impacts on both registry and registrar systems. As such, PIR will take the following steps to ensure that it will be able to migrate to a protocol that has been accepted as an IETF standard.
2. RRP Implementation: RRP to EPP Translation (RRP-Proxy) Overview RFC2832
Support for the current RRP protocol interface into the .ORG registry will be achieved via an RRP-to-EPP proxy. This service would provide all RRP services that are currently stated in RFC2832. A true RRP server would not exist, instead RRP key-value pairs would be translated into EPP-XML using the extension framework where needed to transmit RRP specific items to the actual EPP "thick" registry service. The RRP-to-EPP proxy would act as a temporary migration interface and would be phased out in favor of direct EPP connectivity some time in the future. This approach would minimize the impact of the new .ORG "thick" registry to all existing Registrars.
3. Helpful How-to for EPP
Registrars Appendix B provides an example of the epp-howto document that describes how to transition from RRP to EPP with the use of the epp-rtk. A copy of this document is also available within the epp-rtk project at http://epp-rtk.sf.net/epp-howto.html
Documents like this one as well as others will be made available to registrars to aid in the smooth transition from RRP to EPP. In addition, the registry operator will provide other migration services on request from registrars, to ensure that the RRP to EPP transition is relatively seamless.
|
Connectivity
between the Internet and the Primary and Secondary Registry is via multiple
redundant connections. In addition, connections between servers on the
internal Registry Network are via redundant multi-homed 100 Mbps Ethernet.
Connectivity between the primary and secondary registry facility (for
replication) is via redundant VPN connections.
