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.

.POST Agreement Appendix 7 | Functional and Performance Specifications

.POST Agreement Appendix 47 | Functional and Performance Specifications
  ICANN Logo

.POST Agreement Appendix 7
Functional and Performance Specifications

(11 December 2009)



Pursuant to the responsibility delegated to it in Appendix S, Sponsor will prescribe functional requirements for Registry Services provided for the .post sTLD that shall ensure that at least the following minimum functional capabilities 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. Name server Requirements

The name servers for the .post Sponsored TLD MUST be operated in compliance with the following Requests for Comments (RFCs) and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to: 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472. 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 ; "."
dash = %x2D ; "-"
alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
ldh = alpha / digit / dash
id-prefix = alpha / digit
label = id-prefix [*61ldh id-prefix]
sldn = label dot label; not to exceed 254 characters
hostname = *(label dot) sldn; not to exceed 254 characters







There MUST be name servers for the .post Sponsored TLD on at least five different network segments. So that the IANA has zone-file access, zone-file transfers MUST be enabled at all name servers for transfers to at least 192.0.32.0/20, 208.77.188.0/22, 199.7.81.0/24 and 199.7.85.0/24 or to other IP addresses that may be provided in the future.

3. Registry System Requirements

The registry system MUST enforce the name reservations and Charter requirements set forth in Appendix S.

4. Whois Service Requirements

Whois service MUST meet at least the functional specifications set forth in Appendix 5.

5. Data Escrow Requirements

Data escrow MUST meet at least the functional specifications set forth in Appendix 1. The Sponsor shall designate a Registry Operator capable of storing the data to be escrowed.

6. Reporting Requirements

The Sponsor shall ensure that Registry Operator’s system MUST provide data sufficient to meet the reporting requirements set forth in Appendix 4.

7. Performance Specifications

DNS Service Availability. Service availability as it applies to the DNS Service refers to the ability of the name servers, as a group, to resolve a DNS query from an Internet user. The committed Performance Specification is 100% measured in Monthly Timeframes.

Performance Level. At any time at which it is available, each name server (including a cluster of name servers 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 name server.

Cross-Network Name server Performance Requirements. The committed Performance Specification for cross-network name server performance is a measured Round-trip time of less than 300 ms and measured packet loss of fewer than 10%. Cross-network name server 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 name servers and observing the responses from the name servers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root name server 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 name server must not exceed the required values.

The Round-trip time to each of 75% of the name servers from at least one of the measurement locations must not exceed the required value.

The packet loss to each of the name servers 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 name server performance requirement will be deemed not to have been met only if the name servers persistently fail 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 and its designated Registry Operator will have 60 (sixty) days to cure the failure.

If, following Sponsor’s opportunity to cure, the name servers continue to persistently fail CNNP Tests and Sponsor and its Registry Operator fails to resolve the problem within 30 (thirty) days after written notice of the continuing failures, Sponsor will be in breach of its obligations under the Registry Agreement.

60 (sixty) days before the commencement of testing under this provision, ICANN will provide Sponsor and its designated Registry Operator 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 and its designated Registry Operator to make necessary modifications.

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

Whois Service Performance Level. Each Whois server must, on average, be able to handle a load of queries that is three times the measured daily peak (averaged over the Monthly Timeframe) of such requests on the most loaded Whois server.

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 3 (three) consecutive rcPing commands initiated by the Registry 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.

8. Location of Data Centers

The UPU shall designate a Registry Operator to provide back-end registry infrastructure services that utilize multiple data centers providing geographic and network diversity.

9. Fail Over Practice

The registry shall practice fail over between data centers not less frequently than once every two years.