Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

Контент доступен только на следующих языках

  • English

.name Registry Agreement Appendix 10

Registry Performance Specifications

(1 December 2012)

1. Performance Specifications

The Performance Specifications, defined below, shall apply solely to registered domain names and shall be implemented within eighteen (18) months of the Effective Date. The Performance Specifications will provide a means to measure Registry Operator's delivery of Registry Services. Until such time as the Performance Specifications defined below are implemented, Registry Operator shall continue to meet the availability and performance requirements set forth in Appendix 7 and Appendix 10 of the.NAME Registry Agreement as in effect immediately prior to the Effective Date.

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

1.2 Definitions Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

1.3 "DNS Service" shall mean the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.

1.4 "EPP" shall mean the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

1.5 "ICANN-Accredited Registrar," as used in this Appendix, refers to an "ICANN-Accredited Registrar" that has a Registry-Registrar Agreement in effect with Registry Operator.

1.6 "IP address" shall mean IPv4 or IPv6 addresses without making any distinction between the two. When there is need to make a distinction, IPv4 or IPv6 is used.

1.7 "Performance Specifications" refers to a description of the functional attributes of a particular system or service. The attributes outlined in a Performance Specification are measurable.

1.8 "Probes" shall mean network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at various global locations.

1.9 "Round-Trip-Time" or "RTT" means the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered.

1.10 "SLR" or "Service Level Requirement" means the level of service expected for a certain parameter being measured in a SLA

1.11 "Whois Service" shall mean the information service made available via the Web-based Whois Service and on TCP port 43 on selected servers.

2. Service Level Agreement Matrix

  Parameter SLR (monthly basis)
DNS DNS service availability 0 min downtime = 100% availability
DNS name server availability ≤ 432 min of downtime (≈ 99%)
TCP DNS resolution RTT ≤ 1500 ms, for at least 95% of the queries
UDP DNS resolution RTT ≤ 500 ms, for at least 95% of the queries
DNS update time ≤ 60 min, for at least 95% of the probes
Whois Whois availability ≤ 864 min of downtime (≈ 98%)
Whois query RTT ≤ 2000 ms, for at least 95% of the queries
Whois update time ≤ 60 min, for at least 95% of the probes
EPP EPP service availability ≤ 864 min of downtime (≈ 98%)
EPP session-command RTT ≤ 4000 ms, for at least 90% of the commands
EPP query-command RTT ≤ 2000 ms, for at least 90% of the commands
EPP transform-command RTT ≤ 4000 ms, for at least 90% of the commands

Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. However, note that there is no provision for planned outages or similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

3. Service Levels (Availability and Performance)

3.1 DNS Service.

3.1.1 DNS Service Availability. DNS Service Availability refers to the ability of the group of listed-as-authoritative name servers of a particular registered domain name (e.g., a TLD), to answer DNS queries from DNS probes. For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from "DNS tests" to each of their public-DNS registered "IP addresses" to which the name server resolves. If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable

3.1.2 DNS name server availability. Refers to the ability of a public-DNS registered "IP address" of a particular name server listed as authoritative for a registered domain name, to answer DNS queries from an Internet user. All the public DNS-registered "IP address" of all name servers of the registered domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get undefined/unanswered results from "DNS tests" to a name server "IP address" during a given time, the name server "IP address" will be considered unavailable.

3.1.3 UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.1.4 TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.1.5 DNS resolution RTT. Refers to either "UDP DNS resolution RTT" or "TCP DNS resolution RTT".

3.1.6 DNS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a registered domain name, until the name servers of the parent domain name answer "DNS queries" with data consistent with the change made. This only applies for changes to DNS information.

3.1.7 DNS test. Means one non-recursive DNS query sent to a particular "IP address" (via UDP or TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor. The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered. A query with a "DNS resolution RTT" 5 times higher than the corresponding SLR, will be considered unanswered. The possible results to a DNS test are: a number in milliseconds corresponding to the "DNS resolution RTT" or, undefined/unanswered.

3.1.8 Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP "DNS test" to each of the public-DNS registered "IP addresses" of the name servers of the registered domain name being monitored. If a "DNS test" result is undefined/unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.

3.1.9 Collating the results from DNS probes. The minimum number of active testing probes to consider a measurement valid is 20 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

3.1.10 Distribution of UDP and TCP queries. DNS probes will send UDP or TCP "DNS test" approximating the distribution of these queries.

3.1.11 Placement of DNS probes. Probes for measuring DNS parameters shall be placed as near as possible to the DNS resolvers on the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

3.2 Whois Service.

3.2.1 Whois Service Availability. Whois Service Availability refers to the ability of all the Whois services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the Whois testing probes see any of the Whois services as unavailable during a given time, the Whois Service will be considered unavailable.

3.2.2 WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

3.2.3 Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If Registry Operator implements a multiple-step process to get to the information, only the last step shall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

3.2.4 Whois query RTT. Refers to the collective of "WHOIS query RTT" and "Web-based-WHOIS query RTT".

3.2.5 Whois update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a registered domain name, host or contact, up until the servers of the Whois services reflect the changes made.

3.2.6 Whois test. Means one query sent to a particular "IP address" of one of the servers of one of the Whois services. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an Whois test are: a number in milliseconds corresponding to the RTT or undefined/unanswered.

3.2.7 Measuring Whois parameters. Every 5 minutes, Whois probes will select one IP address from all the public-DNS registered "IP addresses" of the servers for each Whois service of the TLD being monitored and make an "Whois test" to each one. If an "Whois test" result is undefined/unanswered, the corresponding Whois service will be considered as unavailable from that probe until it is time to make a new test.

3.2.8 Collating the results from Whois probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

3.2.9 Placement of Whois probes. Probes for measuring Whois parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

3.3 EPP Service.

3.3.1 EPP Service Availability. Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers. The response shall include appropriate data from the Registry System. An EPP command with "EPP command RTT" 5 times higher than the corresponding SLR will be considered as unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.

3.3.2 EPP session-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session. For the logout command it will include packets needed for closing the TCP session. EPP session commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

3.3.3 EPP query-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

3.3.4 EPP transform-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP transform commands are those described in section 2.9.3 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

3.3.5 EPP command RTT. Refers to "EPP session-command RTT", "EPP query-command RTT" or "EPP transform-command RTT".

3.3.6 EPP test. Means one EPP command sent to a particular "IP address" for one of the EPP servers. Query and transform commands, with the exception of "create", shall be about existing objects in the Registry System. The response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the "EPP command RTT" or undefined/unanswered.

3.3.7 Measuring EPP parameters. Every 5 minutes, EPP probes will select one "IP address" of the EPP servers of the TLD being monitored and make an "EPP test"; every time they should alternate between the 3 different types of commands and between the commands inside each category. If an "EPP test" result is undefined/unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.

3.3.8 Collating the results from EPP probes. The minimum number of active testing probes to consider a measurement valid is 5 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

3.3.9 Placement of EPP probes. Probes for measuring EPP parameters shall be placed inside or close to Registrars points of access to the Internet across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

4. Emergency Escalation

4.1 Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to monitored services. The initiation of any escalation and the subsequent cooperative investigations do not in themselves imply that a monitored service has failed its performance requirements.

4.2 Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry Operator, and Registrars and ICANN. Registry Operators and ICANN must provide said emergency operations departments. Current contacts must be maintained between ICANN and Registry Operators and published to Registrars, where relevant to their role in escalations, prior to any processing of an Emergency Escalation by all related parties, and kept current at all times.

5. Covenants of Performance Measurement

5.1 No interference. Registry Operator shall not interfere with measurement Probes, including any form of preferential treatment of the requests for the monitored services. Registry Operator shall respond to the measurement tests described in this Specification as it would do with any other request from Internet users (for DNS and Whois) or registrars (for EPP).

5.2 ICANN testing registrar. Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above. Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions. ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement.

6. Responsibilities Of The Parties

6.1 Registry Operator shall not be liable to ICANN or ICANN-Accredited Registrars for any credits or penalties or be deemed to be in breach of any of its obligations under the Registry Agreement if it fails to meet a Performance Specification as a result of its compliance with any Consensus Policy established after the Effective Date to the extent and for so long as the failure to meet a Performance Specification is unavoidable by commercially reasonable efforts due to Registry Operator's compliance with such Consensus Policy.

7. Miscellaneous

7.1 This Appendix is not intended to replace any term or condition in the Registry-Registrar Agreement.