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.

TLD Sponsorship Agreement: Attachment 7

ICANN | TLD Sponsorship Agreement: Attachment 7

  ICANN Logo

TLD Sponsorship Agreement: Attachment 7

Posted: 13 October 2001

Minimum ICANN-Required Performance Specifications for Registry Services

Pursuant to the responsibility delegated to it in Attachment 1, Sponsor will prescribe performance requirements for Registry Services provided by the Registry Operator for the Sponsored TLD. Those performance requirements shall ensure that at least the following minimum performance levels are provided.

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.

2. Definitions

Capitalized terms used in this Attachment and not otherwise defined shall have the meaning ascribed to them in the Sponsorship Agreement.

2.1. "Core Internet Service Failure" refers to an extraordinary and identifiable event beyond the control of Registry Operator affecting the Internet services to be measured pursuant to item 3.1.3 of this Attachment 7. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

2.2. "DNS Service" shall mean the service complying with RFC 1034 made available on TCP/UDP port 53 on the Nameservers.

2.3. "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC).

2.4. "Nameservers" refers to the nameservers to which the Sponsored TLD is delegated in the Authoritative Root-Server System.

2.5. "Performance Specification" refers to a description of the performance attributes of a particular system or service.

2.6. "Round-trip" shall mean the amount of measured time that it takes for a reference query to make a complete trip from the sampling agent, to the service being tested and back again. Usually measured in milliseconds.

2.7. "Whois Service" shall mean the information service made available on TCP port 43 on selected servers and described more fully in Attachment 15.

3. Service Levels (Availability and Performance)

3.1. DNS Service

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

3.1.2. 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. [NOTE: This requirement is based on RFC 2870, Section 2.3.]

3.1.3. Cross-Network Nameserver Performance Requirements. The committed Performance Specification for cross-network Nameserver performance is a measured Round-trip time of under 300 ms and measured packet loss of under 10%. Cross?network Nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner: The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the Nameservers and observing the responses from the Nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and Europe). Each string of request packets will consist of 100 UDP packets at 10-second intervals requesting ns records for arbitrarily selected second-level domains in the Sponsored TLD, preselected to ensure that the names exist in the Sponsored TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received will be noted. To meet the packet loss and Round-trip-time requirements for a particular CNNP Test, all three of the following must be true: The Round-trip time and packet loss from each measurement location to at least one Nameserver must not exceed the required values. The Round-trip time to each of 75% of the Nameservers from at least one of the measurement locations must not exceed the required value. The packet loss to each of the Nameservers from at least one of the measurement locations must not exceed the required value. Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered. To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of day, as well as on different days of the week). The cross-network Nameserver performance requirement will be deemed to have not been met only if the Nameservers persistently fail (see item above) the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed. In the event of persistent failure of the CNNP Tests, ICANN will give Sponsor written notice of the failures (with backup data) and Sponsor will have sixty days to cure the failure. If, following Sponsor's opportunity to cure in item above, the Nameservers continue to persistently fail CNNP Tests and Sponsor fails to resolve the problem within thirty days after written notice of the continuing failures, Sponsor will be in breach of its obligations under Subsection 3.4 of the Sponsorship Agreement. Sixty days before the commencement of testing under this provision, ICANN will provide Sponsor with the opportunity to evaluate the testing tools and procedures to be used by ICANN. In the event that Sponsor does not approve of such tools and procedures, ICANN will work directly with Sponsor to make necessary modifications.

3.2. Whois Service

3.2.1. Whois Service Availability. The committed Performance Specification for Whois Service is 99.4% measured in Monthly Timeframes.

3.2.2. Performance Level. The Whois Service will, on average, be able to handle 50 queries per second.

3.2.3. Response Times. The Whois Service will have a worst-case response time of 1.5 seconds, not including network delays, before it will be considered unavailable.

3.2.4. Updates. The data provided by the Whois Service will be updated on at least a daily basis.

4. Measurement

4.1. Except in the case of Cross-Network Nameserver Performance Requirements (item 3.1.3 above), Registry Operator will perform continuous monitoring from internally located systems as a means to verify that the availability and performance measurements in this Attachment are being met.

4.2. Sponsor will report the results of monitoring under item 4.1 above in its monthly reports described in Attachment 20.

Prior drafts:

20 August 2001

Comments concerning the layout, construction and functionality of this site
should be sent to

Page Updated 14-Jan-2008

(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.