Generic Top-Level Domain (gTLD) Registry Agreements
Unsponsored TLD Agreement: Appendix C, Section G (.info)
 |
Unsponsored TLD Agreement: Appendix C, Section G (.info) (11 May 2001) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Functional Specifications Section G—Registry Operations Physical Plant All Registry systems will be located within secure data centers, with at minimum, the following security standards:
All facilities are colocated 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. Hardware Architecture The system uses a distributed architecture that achieves the goals of scalability, reliability, and extensibility. The systems can continue to function even if an entire server were to suffer catastrophic failure. The registry will use load balancers to assist in scalability as well as to prevent service outages. Due to the nature of load balancing, in many cases it will be possible to also perform upgrades on servers without the customer being impacted. Registry facilities will be operated in two geographic locations, allowing for redundancy and fault tolerance. The primary registry facility will be a live facility, meaning that it will be the normal full-time registry. The secondary registry facility will be a standby facility, meaning that it will only be activated because of operational concerns about the primary facility. The secondary facility will remain continuously synchronized with the primary. The registry will operate several database servers to provide redundancy. The primary registry facility will house two database servers, one being the main database and the other being the secondary database. The standby registry facility will house one database server, which will be constantly synchronized with the primary registry. The database servers will be replicated but are not load balanced. The following diagram illustrates the hardware architecture.
The specifications of the individual servers are described below. Primary Site
Connectivity 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 connections within the network. A separate network is used for backups. High capacity routers and switches are used to route traffic to Registry services (see Hardware Architecture). Load balancing is used for balancing all aspects of the Registry, including the Registry gateway, Whois services, and Domain Name Services. Internet Services The Internet services of the registry includes multiple DNS servers, mail servers, EPP gateways, Whois servers, Report servers, OT&E servers, Web servers for Registrar and Registry Administrative interfaces, and Registry Operations servers. All gateways and servers are hosted in a UNIX environment on multi-processor servers. All servers are protected behind firewall systems. See "Hardware Architecture" for detailed information. Internet services operate on RISC-architecture processors with large external caches, main memory and multiple input/output channels, which are able to support internal hot-swappable storage and have redundant hot-swappable power and cooling. The Registry Operations Center operates separate servers to handle customer support, database administration functions, and support for system development. The Registry operations center is on a separate network from the primary and secondary registry facilities, and connects to the registry facilities via a VPN connection. The OT&E Environment is hosted on high capacity multi-processor UNIX servers. System Security All Registry systems shall be located within secure data centers. The Registry shall employ a number of measures to prevent unauthorized access to its network and internal systems. Before reaching the Registry network, all traffic shall be required to pass through a firewall system. Packets passing to or from the Internet shall be inspected, and unauthorized or unexpected attempts to connect to the Registry servers shall be denied and logged. Front-end Registry servers shall generally sit behind a second layer of network security. A network-based intrusion detection system (IDS) shall monitor the network for suspicious activity. If possibly malicious activity is detected, appropriate personnel shall be notified immediately. The Registry shall employ a set of security precautions to ensure maximum security on each of its servers, including disabling all unnecessary services and processes; regular application of security-related patches to the operating system or critical system applications. Regular detailed audits of the server configuration shall be performed to verify that it complies with current best security practices. The Registry application shall use encrypted network communications. Access to the Registry server shall be controlled. The Registry shall allow access to an Authorized Registrar only if each of the authentication factors matches the specific Authorized Registrar. These mechanisms will also be used to secure any web-based tools that allow Authorized Registrars to access the Registry. Additionally, all relevant transactions in the Registry (whether conducted by Authorized Registrars or the Registry's own personnel) shall be logged. The Registry also shall support a secure personal communication process. Authorized Registrars shall be permitted to supply a list of specific individuals (5 to 10 people) who are authorized to contact the Registry. Each such individual shall be assigned a pass phrase. Any support requests made by an Authorized Registrar to Registry customer service shall be authenticated by Registry customer service. All failed authentications will be logged and provided to Afilias on a monthly basis for consideration and/or distribution. All root/super-user accounts shall have passwords changed regularly. Shell accounts on production servers shall be kept to an absolute minimum and limited strictly to senior network and operations staff. Secure shell connections shall be used by Afilias operations staff to access servers remotely. The Registry shall maintain out-of-band management connections to production servers; should there be a denial of service attack on the systems. Root access shall be controlled and managed by Registry Operations. System Redundancy System redundancies exist at the hardware, database, and application layer. These are explained below. Hardware Layer Redundancy The registry will operate with redundant hardware for key facilities. These are described above under "Hardware Architecture". Database Layer Redundancy The registry will operate several database servers to provide redundancy. The primary registry facility will house 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 will be automatically replicated to the secondary database. The Whois service will normally operate off the secondary database server, to allow optimal use of the primary 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 automatically switch over to the secondary database (B). 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 automatically 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". Application Layer Redundancy The application layer architecture allows several instances of the system to be running simultaneously. Automatic fail-over of the system and subsystems is an integral part of the design of the architecture. In addition, the application layer is designed so that peak load can be scaled across multiple processors and multiple servers using a load-balancing algorithm. This results in high reliability and redundancy. The registry will operate two Registry (application) servers (Registry A, B) at the primary registry location, and one Registry (application) server at the stand-by location. A hardware load balancer will distribute load between the two application servers at the primary registry location. In addition, the registry will operate two centralized Whois servers (Whois A, B) at the primary registry location, and one centralized Whois server at the stand-by location. A hardware load balancer will distribute load between the two Whois servers at the primary registry location. In the event of failure of one of the Registry servers, or one of the Whois servers at the primary registry location, the remaining server will handle all transactions until the failed server becomes available. Any fail-over of the application or Whois server will be transparent to the Registrar. If both Registry Application servers at the primary registry facility fail, then the registry will switch over to the stand-by facility as described in "Disaster Recovery". Disaster Recovery 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 switchover to use the standby facility. This is described in more detail below. 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 the Registry application and Whois service will be accessing a single Database (as opposed to accessing separate databases as they do in the Primary facility). Registrar Impact Any fail-over of the system between the primary and standby registry facility will be transparent to 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 automatically switch back to using the primary registry. While the registry is operating from the standby facility, some degradation in service is expected since the Registry application and Whois service will be accessing a single Database (as opposed to accessing separate databases as they do in the Primary facility). Backup The Registry will conduct routine backup procedures. This will be performed in such a way as not to adversely impact scheduled operations.
Nightly backup window starts at 7:00 p.m. and ends at 7:00 a.m. local time. Data Escrow Escrow of the Registry database is discussed in Appendices R and S. OT&E 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 live system to behave exactly as the OT&E system. Afilias' OT&E environment will be hosted on multi-processor UNIX servers and represents a scaled down version of the live system. Registrar Reports Regular Scheduled Reports Afilias will generate reports for each registrar on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the Registrar is the sponsoring registrar. The reports are available for download from the Registrar Administration Interface secure web site. This site requires the Registrar to provide its username and password for authorization. Report Types Two types of reports will be created for each Registrar: Daily Reports and Weekly Reports. These are described below. Daily Reports
Weekly Reports
Report Frequency Daily reports will be generated daily every four hours. Previous reports for that day shall be overwritten each time a new daily report is generated. Weekly reports will be generated on Sunday at 00:00 UTC and shall contain activity for the previous week. Previous weekly reports are overwritten when a new weekly report is generated. Storage Daily Registrar reports are maintained for each registrar for seven days. Daily reports older than seven days will be removed. Distribution Registrar reports shall be available for download via a Reports section in the Registrar Administrative Interface ("Registrar Tool"). Each Registrar will have secure, password-protected access, to the Registrar Administrative Interface. A given Registrar will only have access to its own reports. Registry Reports to ICANN Afilias will also provide various informational reports to ICANN regarding the registry. These are described in Appendices T and U. Registrar-Registry Synchronization There are two methods available for the Registrar to synchronize data with the authoritative-source Registry.
Earlier draft: Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org. Page Updated 02-Feb-2012 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||