Self-certification


Submitted to ICANN by: <Applicant>

String: <TLD>

Application ID: <ID>

Template Version: 1.1, Date: 5 Mars 2013


About this document

This document provides a template for the self-certification documentation 
for the Pre Delegation Testing, PDT. 

The self-certification documentation shall comply with 
- the requirements stated in Module 5 of the AGB
- the requirements stated in the registry agreement including the specifications 2,4,6 and 10 
- assertions made by the applicant in the gTLD application


The applicant shall provide the information as outlined below. The 
template is based on the requirements in the AGB.

1. DNS infrastructure

AGB, chapter 5.2.2: All tests shall be done both over IPv4 and IPv6, with reports providing results according to both protocols.
AGB, chapter 5.2.2: Self-certification documentation shall include data on load capacity, latency and network reachability.

1.1. Load capacity

1.1.1. Expected load

Instruction: Describe the expected load on the name servers during 
normal operation. If it is a shared name server, then the load of 
other zones must be taken into consideration. Do this for both IPv4 and 
IPv6. 
[A short motivation for figures is expected and a description of the 
shared name server, if applicable. 
Provide references to the gTLD application, if applicable.]
Applicant Self Certification:





1.1.2. Statistical population

AGB, chapter 5.2.2: The load capacity test shall be performed against a randomly selected subset of servers within the applicant’s DNS infrastructure.
Instruction: Describe the selected subset, how it has been selected and 
what percentage of the total set of servers it represents. 
This applies to both IPv4 and IPv6.
[A short description and motivation is expected.]
Applicant self certification:





1.1.3. Method

AGB, chapter 5.2.2: Responses must either contain zone data or be NXDOMAIN or NODATA responses to be considered valid.
Instruction: Describe the method of measurement and what type of 
queries and responses are used.
Applicant self certification:





1.1.4 DDoS

Instruction: 
Describe mitigation of Distributed Denial of Service (DDoS) attacks.
A description of strategies and controls is expected. Provide references 
to the gTLD application, if applicable].
Applicant self certification:





1.1.5. Result

AGB, chapter 5.2.2: Load capacity shall be reported using a table and a corresponding graph, showing percentage of queries responded against an increasing number of queries per second generated from local (to the servers) traffic generators. The table shall include at least 20 data points and loads of UDP-based [and TCP-based] queries that will cause up to 10% query loss against a randomly selected subset of servers within the applicant’s DNS infrastructure.
AGB, chapter 5.2.2: Load capacity [...] [for DNSSEC support] shall be documented as for UDP and TCP above.
AGB, chapter 5.2.2: The documentation provided by the applicant must include the results from a system performance test indicating available network and server capacity and an estimate of expected capacity during normal operation to ensure stable service as well as to adequately address Distributed Denial of Service (DDoS) attacks.
Instruction:
Applicant self certification: 






Example table showing percentage of queries responded against an 
increasing number of queries per second:
UDP TCP UDP +DO TCP +DO
# QPS % QPS % QPS % QPS %
1 500 100 500 100 500 100 500 100
2 1000 100 1000 100 1000 100 1000 100
3 1500 100 1500 100 1500 100 1500 100
4 2000 100 2000 99 2000 100 2000 99
5 2500 100 2500 98 2500 100 2500 98
6 3000 100 3000 97 3000 99.5 3000 96
7 3500 99 3300 96 3400 99 3200 95.5
8 4000 98.5 3700 95 3800 98.5 3600 95
9 4500 98 3800 95 4000 98 3700 94.5
10 5000 97.5 3900 94 4100 97.5 3800 94
11 5500 97 4000 94.5 4200 97 3900 93.5
12 6000 96 4100 94 4300 96 3950 93.5
13 6400 95 4200 93.5 4400 95 4000 93.25
14 6600 94.5 4300 93 4500 94 4050 93
15 6700 94 4350 92.5 4600 93.5 4100 92.75
16 6800 93 4400 92 4700 93 4150 92.5
17 6900 92 4450 91.5 4750 92.5 4200 91.5
18 7000 91 4500 91 4800 91.5 4225 91
19 7100 90.5 4525 90.5 4825 90 4250 90.5
20 7200 90 4550 90 4875 90 4260 90 
Example graph:

1.2. Query latency

AGB, chapter 5.2.2: Query latency shall be reported in milliseconds as measured by DNS probes located just outside the border routers of the physical network hosting the name servers, from a network topology point of view.

1.2.1. Method

Registry agreement, specification 10: 3.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 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.
Registry agreement, specification 10: 3.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.
Registry agreement, specification 10: 3.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.
Instruction: Describe how the query latency has been measured.
[A brief description showing how the requirements are met.]
Applicant self certification:





1.2.2. Result

Instruction: Report the min/avg/max values of query latency in milliseconds. 
The test shall include both UDP and TCP. The tests shall also include DNSSEC. 
Perform the tests on all name servers (IPv4/IPv6).
Applicant self certification: 





Example table showing query latency (min/avg/max) in milliseconds:
NS IP UDP TCP UDP +DO TCP +DO
a.ns.TLD 192.0.2.1 120/125/134 150/151/152 122/140/200 152/160/171
a.ns.TLD 2001:DB8::1 100/103/109 125/126/127 110/115/116 135/141/145
b.ns.TLD 192.0.2.2 90/91/92 90/93/94 91/91/92 91/97/100
b.ns.TLD 2001:DB8::2 98/99/103 110/115/118 105/125/190 107/130/200
c.ns.TLD 192.0.2.3 50/55/60 53/54/55 60/69/81 70/71/72

1.3. Reachability

1.3.1. Peering

AGB, chapter 5.2.2: Reachability will be documented by providing information on the transit and peering arrangements for the DNS server locations, listing the AS numbers of the transit providers or peers at each point of presence and available bandwidth at those points of presence.
Instruction: Provide the information as specified by the 
requirements.
Applicant self certification: 





Example table showing transit and peering arrangements:
NS IP AS Bandwidth
a.ns.TLD 192.0.2.1 AS1 AS2 AS3 100 Mbit/s
a.ns.TLD 2001::DB8:1 AS1 AS4 AS5 100 Mbit/s
b.ns.TLD 192.0.2.2 AS3 AS4 AS5 1 Gbit/s
b.ns.TLD 2001::DB8:2 AS6 AS7 AS8 1 Gbit/s
c.ns.TLD 192.0.2.3 AS9 2 Gbit/s

1.3.2. Reachability TCP-based DNS queries

AGB, chapter 5.2.2: Reachability will be documented by providing records of TCP-based DNS queries from nodes external to the network hosting the servers. These locations may be the same as those used for measuring latency above.
Instruction: Provide the information as specified by the 
requirements. Repeat for both IPv4 and IPv6.
Applicant self certification:





1.4 DNSSEC

AGB, chapter 5.2.2: DNSSEC support -- Applicant must demonstrate support for EDNS(0) in its server infrastructure, the ability to return correct DNSSEC-related resource records such as DNSKEY, RRSIG, and NSEC/NSEC3 for the signed zone, and the ability to accept and publish DS resource records from second-level domain administrators. In particular, the applicant must demonstrate its ability to support the full life cycle of KSK and ZSK keys. 
Instruction: 
Provide information regarding
Applicant self certification:





1.5. SLA, DNS Infrastructure

Specification: 
The DNS infrastructure must meet all service level requirements 
described in specification 10 of the registry agreement.

The infrastructure must also meet all service level assertions 
made in the gTLD application in relation to system performance as 
described in specification 10 of the registry agreement.

The infrastructure must furthermore meet all other performance 
assertions made in the gTLD application.

Instruction:
Applicant self certification: 





Example table showing adherence to the SLA:
Parameter Self-certification (monthly basis)
DNS service availability ____ min downtime
DNS name server availability ≤ ____ min of downtime
TCP DNS resolution RTT ≤ ____ ms, for at least 95% of the queries
UDP DNS resolution RTT ≤ ____ ms, for at least 95% of the queries
DNS update time ≤ ____ min, for at least 95% of the probes


2. Whois

AGB, chapter 5.2.3: Applicant must provide Whois services for the anticipated load. ICANN will verify that Whois data is accessible over IPv4 and IPv6 via both TCP port 43 and via a web interface and review self-certification documentation regarding Whois transaction capacity.

2.1. Load capacity

AGB, chapter 5.2.3: Self-certification documents shall describe the maximum number of queries per second successfully handled by both the port 43 servers as well as the web interface, together with an applicant-provided load expectation.

2.1.1. Expected load

Instruction: Describe the expected load on the Whois service 
(port 43 and HTTP) during normal operation. If it is a Shared Registry 
System, then the load of other TLD:s must be taken into consideration.
Do this for both IPv4 and IPv6.
[A short motivation for the figures is expected and a short description of the 
shared registry system, if applicable. 
Provide references to the gTLD application, if applicable.]
Applicant self certification:





2.1.2. Port 43

2.1.2.1. Method

Instruction: Describe how the performance has been measured.
[A brief description is expected.]
Applicant self certification:





2.1.2.2. Result

Instruction: Describe the maximum number of queries per second 
successfully handled by the port 43 servers over IPv4 and IPv6.
Applicant self certification: 





Example table showing maximum queries per second:
QPS
IPv4 5000
IPv6 5100

2.1.3. HTTP

2.1.3.1. Method

Instruction: Describe how the performance has been measured.
[A brief description is expected.]
Applicant self certification:





2.1.3.2. Result

Instruction: Describe the maximum number of queries per second 
successfully handled by the web interface over IPv4 and IPv6.
Applicant self certification: 





Example table showing maximum queries per second:
(QPS) HTTP HTTPS
IPv4 500 400
IPv6 505 396

2.2. Data mining

AGB, chapter 5.2.3: Additionally, a description of deployed control functions to detect and mitigate data mining of the Whois database shall be documented.
Instruction: Describe the control functions for detection 
and mitigation of datamining of the Whois database. 
This is applicable for both port 43 and HTTP.
[The description should cover both the strategy used and implemented controls.
Provide references to the gTLD application, if applicable.]
Applicant self certification:





2.3. Searchable whois

Instruction: Describe any provision made for searchable Whois lookup services for
names registered in the TLD.
[Provide references to the gTLD application, if applicable.]
Applicant self certification:





2.4. SLA, Whois

AGB, chapter 5.2.3: System performance -- The registry system must scale to meet the performance requirements described in specification 10 of the registry agreement.
Specification:
The registry data directory services must meet all service level 
requirements described in specification 10 of the registry agreement.

The services must also meet all service level assertions made in the 
gTLD application in relation to system performance as described in 
specification 10 of the registry agreement.

The services must furthermore meet all other performance assertions 
made in the gTLD application.


Instruction:
Applicant self certification: 





Example table showing adherence to the SLA:
Parameter Self-certification (monthly basis)
RDDS availability ____ min downtime
RDDS query RTT ≤ ____ ms, for at least 95% of the queries
RDDS update time ≤ ____ min, for at least 95% of the probes


3. EPP

3.1. Load capacity

AGB, chapter 5.2.3: Documentation shall provide a maximum Transaction per Second rate for the EPP interface with 10 data points corresponding to registry database sizes from 0 (empty) to the expected size after one year of operation, as determined by applicant.
Instruction:
Applicant self certification: 





Example table showing the load capacity:
# Number of domains TPS
1 0 2000
2 200000 1900
3 250000 1850
4 300000 1825
5 350000 1800
6 400000 1775
7 500000 1750
8 650000 1700
9 800000 1625
10 1000000 1550

3.2. Initial load

AGB, chapter 5.2.3: Documentation shall also describe measures taken to handle load during initial registry operations, such as a land-rush period.
Instruction: Describe how the load is handled for the initial 
registry operations, such as a land-rush period.
[A brief description is expected. A justification of the chosen solution should be provided.]
Applicant self certification:





3.3. EPP Extensions

Instruction: 
    

  • Describe all provided EPP extentions.
[Brief descriptions are expected.]
    • 

  • Describe how these extensions comply with RFC 3735.
    • 

  • Provide references to assertions made in gTLD 
application relating to EPP extensions. 
    • 

  • Provide a description of the adherence to these assertions.
Applicant self certification:





3.4. EPP IPv6

Instruction:
If EPP services are available over IPv6, give a short description of IPv6 usage.
[Provide references to the gTLD application, if applicable.]
Applicant self certification:





3.5. SLA, EPP

AGB, chapter 5.2.3: System performance -- The registry system must scale to meet the performance requirements described in specification 10 of the registry agreement.
Specification:
The EPP services must meet all service level requirements 
described in specification 10 of the registry agreement.

The services must also meet all service level assertions made in the gTLD 
application in relation to system performance as 
described in specification 10 of the registry agreement.

The services must furthermore meet all other performance assertions 
made in the gTLD application.

Instruction:
    

  • Provide a table describing the adherence to the Service Level Requirements as 
  given in specification 10 of the registry agreement.
    • 

  • Provide references to all assertions in the gTLD application relating 
  to system performance as given in Specification 10 of the registry agreement.
    • 

  • Provide a table describing the adherence to the above mentioned assertions.
    • 

  • Provide references to all other assertions in the 
  gTLD application relating to system performance.
    • 

  • Provide a description of the adherence to these assertions.
    •
Applicant self certification: 





Example table showing adherence to the SLA:
Parameter Self-certification (monthly basis)
EPP service availability ____ min downtime
EPP session-command RTT ≤ ____ ms, for at least 90% of the commands
EPP query-command RTT ≤ ____ ms, for at least 90% of the commands
EPP transform-command RTT ≤ ____ ms, for at least 90% of the commands


© Internet Corporation For Assigned Names and Numbers.