Generic Top-Level Domain (gTLD) Registry Agreements
.XXX Agreement Appendix 7 | Functional and Performance Specifications
.XXX Agreement Appendix 7 Functional and Performance Specifications (31 March 2011) |
||
Pursuant to the responsibility delegated to it in Appendix S, Registry Operator will prescribe functional requirements for Registry Services provided for the Sponsored TLD that shall ensure that at least the following minimum functional capabilities are provided. The key words "MUST," "MUST NOT," "REQUIRED," "SHALL", "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119. The DNS service for the Sponsored TLD MUST be operated in compliance with the following Requests for Comments (RFCs): 1034 , 1035 , 1982 , 2181 , 2182, 2671, 3226, 3596, 3597, 3901, 4343, 4472, and their successors. Registry Operator shall be able to publish IPv6 addresses as glue records for registered domains in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry's name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow "DNS IPv6 Transport Operational Guidelines" as described in BCP 91. For domain names which are either not registered, or the registrant has not supplied valid records such as NS records for listing in the DNS zone file, or their status does not allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs 1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using redirection within the DNS by the Registry is prohibited. When queried for such domain names the authoritative name servers must return a "Name Error" response (also known as NXDOMAIN), RCODE 3 as described in RFC 1035 and related RFCs. This provision applies for all DNS zone files at all levels in the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services) maintains data, arranges for such maintenance, or derives revenue from such maintenance. When Registry Operator signs its TLD zone files implementing Domain Name System Security Extensions ("DNSSEC"), Registry Operator will comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator will accept public-key material from child domain names in a secure manner according to industry best practices. Registry will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants' public-key material. If the Registry Operator offers Internationalized Domain Names ("IDNs"), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors and the ICANN IDN Guidelines at <http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines. In clarification of the statement of host-name rules in these RFCs, all Registered Names SHALL comply with the following syntax in augmented Backus-Naur Form (BNF) as described in RFC 5234: dot = %x2E ; "." The registry system MUST enforce the name reservations and Charter requirements set forth in Appendix S. Registry Operator shall implement the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 3915, 5730, 5731, 5732, 5733, 5734, and 5910. If Registry Operator requires the use of functionality outside the base EPP RFCs, it must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735. Registry Operator shall accept IPv6 addresses as glue records in its Registry System. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a TLD accredited Registrar willing to operate the SRS over IPv6. Whois service MUST meet at least the functional specifications set forth in Appendix 5. Data escrow MUST meet at least the functional specifications set forth in Appendix 1. The registry shall be capable of storing the data to be escrowed. The registry system MUST provide data sufficient to meet the reporting requirements set forth in Appendix 4. DNS Service Availability. Service availability as it applies to the DNS Service refers to the ability of the Nameservers, as a group, to resolve a DNS query from an Internet user. The committed Performance Specification is 99.999% measured in Monthly Timeframes. Performance Level. At any time at which it is available, each Nameserver (including a cluster of Nameservers addressed at a shared IP address) MUST be able to handle a load of queries for DNS data that is three times the measured daily peak (averaged over the Monthly Timeframe) of such requests on the most loaded Nameserver. Cross-Network Nameserver Performance Requirements. The committed Performance Specification for cross-network Nameserver performance is a measured Round-trip time of less than 300 ms and measured packet loss of fewer than 10%. Cross-network Nameserver performance measurements will be conducted by ICANN at times of it's choosing, in the following manner:
Whois Service Availability. The committed Performance Specification for Whois Service is 99.4% measured in Monthly Timeframes. Whois Service Performance Level. The Whois Service will, on average, be able to handle 50 queries per second. Whois Service Response Times. The Whois Service will have a maximum whois query response time of 1.5 seconds. Failure of the Whois Service to respond to three (3) consecutive rcPing commands initiated by the Registry Operator at regular intervals within such maximum processing time shall mean the Whois Service is considered unavailable. Whois Service Updates. The data provided by the Whois Service will be updated on at least a daily basis. Registry Operator will conduct its operations using network and geographically diverse, redundant servers (including network-level redundancy, end-node level redundancy and the implementation of a load balancing scheme) to ensure continued operation in the case of technical failure (widespread or local), business insolvency or an extraordinary occurrence or circumstance beyond the control of the Registry Operator. Registry Operator will use commercially reasonable efforts to restore the critical functions of the registry (DNS, WHOIS, Registration System, Data Escrow and DNSSEC if offered) within 24 hours after the termination of an extraordinary event beyond the control of the Registry Operator and restore full system functionality within a maximum of 48 hours following such event, depending on the type of critical function involved. Outages due to such an event will not be considered a lack of service availability. The registry shall practice fail over between data centers not less frequently than once a year. |