Back

23 Provide name and full description of all the Registry Services to be provided

gTLDFull Legal NameE-mail suffixDetail
.spiegelSPIEGEL-Verlag Rudolf Augstein GmbH & Co. KGthomsentrampedach.comView
Question 23: Registry Services

KSregistry has been chosen as technical backend for registry operations because of the companyʹs extensive knowledge of the domain industry and technical infrastructure. The parent company of KSregistry, Key-Systems GmbH, has extensive knowledge in the area of handling gTLDs (as of today all gTLDs already supported) as well as more than 200 different ccTLDs (including com.br, de, jp, be, co.uk, us, etc.). This experience also covers IDN relevant topics as well as DNSSEC and industry best practice elements. Having participated in the early days of the IDN testbed of Verisign, which included the transition to the punycode standard in 2004, KSregistrysʹ parent company gained insight into transitioning processes and all aspects of IDNs. The KSregistry shared registry system (“SRS”) is based on the MetaRegistry platform, which is in use as the domain management platform of Key-Systems. The scalability of the system has been proven in 2007 by handling the transition of the former Namestore ccTLD system for country codes (other than CC and TV) from VeriSign to Key-Systems, as well as the growth of the customer base of Key-Systems. With more than 1800 reseller-registrars and over 3 million domain names under management, the systemsʹ scalability is proven with the number of domains under management and the number of simultaneous connections from different reseller-registrars. With more than 5 years of experience in running and maintaining an EPP server KSregistry can guarantee the compliance and stability required to run a gTLD EPP service in accordance with the ICANN specifications. The KSregistry staff has repeatedly assisted gTLD and ccTLD operators in improving their systems.

These technical and operational specifications for the Registry TLD consist of the following parts:

The EPP-based KSregistry (KSR) platform provides a stable, DNSSEC and IPv6-enabled SRS that is scalable, state-of-the-art, and secure.

All registry services will be provided by the KSregistry in a responsible manner adhering to all ICANN requirements for TLD operations. KSregistry has already been chosen as the new technical registry service provider by the operators of the following ccTLDs : dotDM, dotTC, dotVG and dotGD.

The goal is to operate an ICANN compliant technical registry platform meeting industry best practice standards to allow registrations under the applied for new top level domain.

All registry services described in our responses to questions 23-44 are managed in a contract based on a fixed yearly fee plus a per domain name fee per year.

Thus KSregistry has been mandated to manage all technical tasks related to operating our TLD, and will further support us with their legal resources, as described inter alia in our responses to question 27,31,35,39,43,44 as well as 28 and 29.

Hence, the responses to question 23-44 have been developed together with KSregistry.

All ICANN accredited registrars that meet the registry operators established eligibility criteria must use EPP (see section A below) to interact with the registry and manage their sponsored domain names. Due to the nature of the string as a “single registrant TLD,” it is expected that only a very limited number of registrars will seek accreditation.

All fundamental registry services will be subject to the SLAs as defined in question 24. All services are continuously monitored for compliance with the SLAs and to discover increased system load and performance issues prior to affecting the experience of the registrars or end-usersʹ of the TLD.

The registry will implement several blacklists to ensure compliance with ICANN guidelines, including but not limited to Specification 5 of the New gTLD agreement specifications.

All domain name availability checks and registrations will be checked against the implemented blacklists and eligible registration guidelines to ensure standard compliance and policy guidelines (such as hyphens in third and fourth place are only allowed for valid IDN registrations ʺxn--ʺ).

Two character labels, country and territory names as stated in ISO 3166-1 and all successors thereto, will be blocked and only released if a written confirmation of such a release is granted by the applicable governments. Detailed descriptions on the handling of reserved domain names can be found in answer to question 22.

None of the registry services are offered in a manner that is unique to this TLD. They are offered as standard registry services as is the case for established gTLDs today, and no new services are defined for this TLD.

KSregistry will support this TLD in accordance with the policies established by ICANN and the applicant leveraging a fully operational registry infrastructure supported by experienced professional staff and fully provisioned to immediately launch this and a number of other gTLDs to meet or exceed the Service Levels required in the ICANN contract.

Standard Policies and Dispute Resolution

Domain name registration in the zone are subject to the Uniform Dispute Resolution Policy (UDRP), PDDRP, URS and all successors thereto.

Inter-registrar transfers are subject to the ICANN transfer policy as described in

http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm and the transfer dispute policy as described in http:⁄⁄www.icann.org⁄en⁄transfers⁄dispute-policy-12jul04.htm.

The registry operator is committed to using best practice standards as described by industry members and ICANN.

Data Escrow Service

To ensure compliance with the Data Escrow requirements the registry will be using Group NCC to act as the third party data escrow agent (see answer 38 for details). All data uploaded to the escrow agent will follow the specifications published at http:⁄⁄tools.ietf.org⁄html⁄draft-arias-noguchi-registry-data-escrow-02 or any successor RFC.

The purpose of the third party data escrow service is to allow a registry data transition in the case that the registry provider fails to fulfill its SLA or is incapable of continuing the registry operations in a manner defined by ICANN.

Reports will be generated on a regular basis to be used for reporting to ICANN.


A. Receipt of Data from Registrars

A.1 Extensible Provisioning Protocol (EPP)

For the purpose of data exchange with the registrar, EPP is used in combination with an SSL encryption on a dedicated port. The registry will issue an SSL certificate for usage by the registrars.

Our EPP specifications follow the existing RFCs and will comply with all relevant successor standards. RFCs considered for the EPP protocol are: RFC 3735, 5730 – 5734, 5910 and 3915.

The following commands will be available for registry operation:

- CreateDomain, CreateContact, CreateHost
- ModifyDomain, ModifyContact, ModifyHost
- InfoDomain, InfoContact, InfoHost
- DeleteDomain, DeleteContact, DeleteHost
- CheckDomain, CheckContact, CheckHost
- TransferDomain
- RenewDomain

Check commands will be available for accredited registrars to check availability of contact handles, host objects, and domain names.

CreateContact will be used to create contact handles used for subsequent domain registrations and modifications.

CreateHost will be used to create host objects serving as nameservers.

CreateDomain will enable all ICANN accredited registrars to create a domain name under the respective TLD of this application.

Several ʺInfoʺ commands will be available to provision status information on domains, contacts and host objects to the accredited registrars.

See attached fig. Q23_Figure1.pdf.

Detailed EPP descriptions can be found in the answers to the questions 25, which are incorporated here by reference.

A.2 Production and Operational Testing and Evaluation (OT&E) EPP Servers

There will be two EPP servers to interact with the registry. One will be for production purposes and the other for testing and evaluation (referred to as the OT&E server) of new software versions and EPP client implementations. The production server consists of at least two load balanced servers (n+1). Each new stable production release will be released on the OT&E EPP server at least 30 days in advance. To increase security, a registrar IP address limitation is in place for the EPP servers (both production and OT&E).

A limitation on the allowable commands per time interval will prevent the registrar from affecting other clients in the SRS environment in regard to performance issues and increased system load.

Each registrar in the SRS environment will be entitled to up to five sessions from two different IP addresses. The registrar will be forced to update the registry password for the EPP servers and registrar extranet (see below) at least once every six months.

A.3 Registrar Extranet and SFTP Area

In addition to the EPP system the registrar can chose to interact with the registry through the registry specific registrar extranet and SFTP area. Access to the SFTP area will be secured by protocol specific encryption mechanisms. Aside from the EPP registrar-registry interaction, the registry extranet is mainly used to adjust registrar specific settings such as accounting, default values for RDDS (WHOIS), and reporting. Different tiers of access are granted to the registrars for this purpose. Access can be limited on a per user and group basis to either read only or write operations for the following objects: domains, hosts, contacts, user and group rights, accounting lists and current account statement.

The registrar extranet will enable registrars to update their IP address range and passwords for the EPP production, OT&E and SFTP areas. When changes are made to the IP address range a support agent will contact the registrar to verify the changes prior to the implementation. The registry will provide marketing material and⁄or detailed reports to all registrars on a regular basis via the registrar specific SFTP area.

Documents will be generated on a regular basis for all registrars and can be found in the SFTP area. These include transaction reports, monthly billing details, and detailed lists on domain names with a status of PendingDelete, domain names under registrarsʹ management, and contacts used.

Access to the registry extranet and SFTP area is also limited to a set of IP addresses as defined by the registrar during the accreditation process.

A.4 Support Case Handling

Each support case received by the KSregistry system either by email (ticket system) or phone will be subject to a passphrase authentication scheme. The pass phrases are given during the registrar accreditation process and will be used to identify authorized persons belonging to the registrar. This will thwart any social hacking attempts by unauthorized users.

Support will be handled through 3 different locations:

- USA, VA, Leesburg: 8 am – 5 pm EST ⁄ UTC⁄GMT -5 hours
- Germany, St. Ingbert: 7 am – 6 pm UTC⁄GMT
- Mexico, Monterey: UTC⁄GMT -6 hours

Supported languages are: English, German, Spanish, French, Polish and Mandarin Chinese.

Registrar technical support will be available through a dedicated technical support team 24 x 7 x 365. The support team is committed to delivering support by utilizing best practices and industry standards.

A.5 Provisioning of Zone Status Information to Registrars

Registrars can query the status of a domain name with the “InfoDomain” command or through RDDS. In order to query status information on an existing host-object the command “InfoHost” is used.

The registry operator will inform registrars by email in the cases of unplanned (emergency) or scheduled maintenance.

Information on planned system maintenance will be sent to all accredited registrars at least 30 days prior to the deployment in the OT&E and production system. Registrars will also be informed in the event that system performance drops below normal operational standards and in the event of unforeseen system outages.


B. Dissemination of TLD Zone Files

Nameserver operations for the Registry TLD will comply with RFCs 1034, 1035, and 2182 and all future successors and updates thereto. Additional details on the dissemination of TLD Zone Files can be found in answers to question 35 of this application, which are incorporated here by reference.
Distribution of zone files among all secondary nodes will be handled by a dedicated hidden master.

Updates to the primary master node will be performed every 15 minutes and distributed to a secondary master node (operated by PCH.NET, an external service provider specialized in providing anycast DNS services). For additional stability, the two hidden primary servers (master nodes) will be used in two different geographic locations. All other anycast and unicast nodes will query the secondary master node for zone file updates and update their records accordingly. Several checks will ensure the integrity of the distributed zone file before it is uploaded to the master node. Zone transfers will use the AXFR⁄IXFR zone file transfer method after successful verification of the newly generated zone. The distribution of new zone files will be continuously checked with each of the client nodes.


C. Dissemination of Contact or Other Information Concerning Domain Name Registration

A port 43 RDDS (WHOIS) server (RFC 3912) will be available for legitimate WHOIS lookups. The service will be load balanced on a cluster system updated in near real time. Query limitations on a per IP and subnet basis will apply to prevent system abuse. IP addresses stated in the ICANN RADAR section will be entitled to an increased query limit to facilitate inter-registrar transfers. A website WHOIS will be available on the registryʹs website to facilitate legitimate WHOIS queries using a normal browser. All services will be provided in full compliance with the ICANN requirements and applicable law. Additional details will be described as part of the answer to question 26 (RDDS) and question 44 (IDN).

In order to prevent system abuse of the website whois, a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) will be used. Each IP address will be entitled to up to six lookups per minute and up to 360 lookups per hour. Each subnet will be entitled to 12 lookups per minute and up to 720 lookups per hour.

IP Addresses listed in the ICANN RADAR section will be entitled to 20 lookups per minute and up to 1200 lookups per hour. For clients using Ipv6, appropriate limitations will be in place to prevent data mining and abusive WHOIS queries.

Information used for WHOIS lookups will be distributed to the WHOIS server cluster using default SQL replication mechanisms. A dedicated read-only database (load balanced) will be used to store all relevant data at the location of the WHOIS server. To prevent any unauthorized access to the database all external communications to the database are blocked.
The WHOIS output will contain information such as domain names and contacts associated with the domain name registration, dates such as registration date and expiration date, status of a domain name, and host objects.

Example Request: Query for domain “example.string” (please refer to Q26 section 8 for additional information concerning the WHOIS output)
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.example.string
Referral URL: http:⁄⁄www.example.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0


D. Internationalized Domain Names (IDNs)

The applicant will offer IDNs and is in compliance with 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. The registry will 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.
Full detailed description of IDN handling can be found in answers to question 44, which are incorporated here by reference.

The following languages will be supported for this TLD:

- German

See respective language table “Q44_Figure6.pdf” - attached to the answer of question 44.


E. DNS Security Extensions (DNSSEC)

DNS Servers will provide DNSSEC capability according to RFCs 5910, 4641, 4034 and all successors and updates thereto. EPP DNSSEC specifications will be implemented according to RFC 4310. Zones will be signed on the signing server and distributed to the hidden master nameservers which will then distribute them to the secondary servers. A full detailed description of DNS and DNSSEC related topics can be found in answers to question 43, which are incorporated here by reference.


F. Additional Proposed Registry Services

F.1 Bulk Zonefile Access

Clients with a legitimate interest in accessing the registry zone file will be entitled to access this file once a day. For this purpose a dedicated SFTP access will be granted and the zone file will be uploaded once a day. This service will be subject to an additional agreement fully executed between the interested party and the registry.

F.2 Tiered Registration

As this is a single registrant TLD, apart from a 30 days sunrise period no additional tiered registration phases will be offered.


G. List of Attachments

- Q23_Figure1.pdf - List of supported EPP commands ⁄ EPP object relationship
- Q23_Figure2.pdf - List of Codes throughout the Application



〉〉 SPECIAL NOTE: IN OUR RESPONSE TO QUESTIONS 25, 29, 32, 36, 38, 42, 43, AND 44 WE ARE DEMONSTRATING EXAMPLES OF CODE TO ILLUSTRATE HOW OUR REGISTRY SERVICES WORK. OUR CODE CONTAINS THE BRACKETS ʺ〈ʺ AND ʺ〉ʺ. WHEN GENERATING HTML PREVIEW VERSIONS OF AN APPLICATION VIA THE TAS, WE HAVE DETECTED THAT BROWSERS, OR PROGRAMS SUCH AS MICROSOFT WORD AND ADOBE READER, DO NOT SHOW THESE CODES (THEY ARE, HOWEVER, SHOWN IF YOU OPEN THE FILE WITH NOTEPAD OR SIMILAR TEXT EDITORS). HENCE, WE HAVE DECIDED TO ATTACH CODE FOR QUESTIONS 25, 29, 32, 36, 38, 42, 43, AND 44 IN ORDER FOR EVALUATORS TO HAVE AN EASY ACCESS TO ALL THE CODE EXAMPLES.
gTLDFull Legal NameE-mail suffixDetail
.averyAVERY DENNISON CORPORATIONthomsentrampedach.comView
Question 23: Registry Services

KSregistry has been chosen as technical backend for registry operations because of the companyʹs extensive knowledge of the domain industry and technical infrastructure. The parent company of KSregistry, Key-Systems GmbH, has extensive knowledge in the area of handling gTLDs (as of today all gTLDs already supported) as well as more than 200 different ccTLDs (including com.br, de, jp, be, co.uk, us, etc.). This experience also covers IDN relevant topics as well as DNSSEC and industry best practice elements. Having participated in the early days of the IDN testbed of Verisign, which included the transition to the punycode standard in 2004, KSregistrysʹ parent company gained insight into transitioning processes and all aspects of IDNs. The KSregistry shared registry system (“SRS”) is based on the MetaRegistry platform, which is in use as the domain management platform of Key-Systems. The scalability of the system has been proven in 2007 by handling the transition of the former Namestore ccTLD system for countrycodes (other than CC and TV) from VeriSign to Key-Systems, as well as the growth of the customer base of Key-Systems. With more than 1800 reseller-registrars and over 3 million domain names under management, the systemsʹ scalability is proven with the number of domains under management and the number of simultaneous connections from different reseller-registrars. With more than 5 years of experience in running and maintaining an EPP server KSregistry can guarantee the compliance and stability required to run a gTLD EPP service in accordance with the ICANN specifications. The KSregistry staff has repeatedly assisted gTLD and ccTLD operators in improving their systems.

These technical and operational specifications for the Registry TLD consist of the following parts:

The EPP-based KSregistry (KSR) platform provides a stable, DNSSEC and IPv6-enabled SRS that is scalable, state-of-the-art, and secure.

All registry services will be provided by the KSregistry in a responsible manner adhering to all ICANN requirements for TLD operations. KSregistry has already been chosen as the new technical registry service provider by the operators of the following ccTLDs : dotDM, dotTC, dotVG and dotGD.

The goal is to operate an ICANN compliant technical registry platform meeting industry best practice standards to allow registrations under the applied for new top level domain.

All registry services described in our responses to questions 23-44 are managed in a contract based on a fixed yearly fee plus a per domain name fee per year.

Thus KSregistry has been mandated to manage all technical tasks related to operating our TLD, and will further support us with their legal resources, as described inter alia in our responses to question 27,31,35,39,43,44 as well as 28 and 29.

Hence, the responses to question 23-44 have been developed together with KSregistry.

All ICANN accredited registrars that meet the registry operators established eligibility criteria must use EPP (see section A below) to interact with the registry and manage their sponsored domain names. Due to the nature of the string as a “single registrant TLD,” it is expected that only a very limited number of registrars will seek accreditation.

All fundamental registry services will be subject to the SLAs as defined in question 24. All services are continuously monitored for compliance with the SLAs and to discover increased system load and performance issues prior to affecting the experience of the registrars or end-usersʹ of the TLD.

The registry will implement several blacklists to ensure compliance with ICANN guidelines, including but not limited to Specification 5 of the New gTLD agreement specifications.

All domain name availability checks and registrations will be checked against the implemented blacklists and eligible registration guidelines to ensure standard compliance and policy guidelines (such as hyphens in third and fourth place are only allowed for valid IDN registrations ʺxn--ʺ).

Two character labels, country and territory names as stated in ISO 3166-1 and all successors thereto, will be blocked and only released if a written confirmation of such a release is granted by the applicable governments. Detailed descriptions on the handling of reserved domain names can be found in answer to question 22.

None of the registry services are offered in a manner that is unique to this TLD. They are offered as standard registry services as is the case for established gTLDs today, and no new services are defined for this TLD.

KSregistry will support this TLD in accordance with the policies established by ICANN and the applicant leveraging a fully operational registry infrastructure supported by experienced professional staff and fully provisioned to immediately launch this and a number of other gTLDs to meet or exceed the Service Levels required in the ICANN contract.

Standard Policies and Dispute Resolution

Domain name registration in the zone are subject to the Uniform Dispute Resolution Policy (UDRP), PDDRP, URS and all successors thereto.

Inter-registrar transfers are subject to the ICANN transfer policy as described in

http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-en.htm and the transfer dispute policy as described in http:⁄⁄www.icann.org⁄en⁄transfers⁄dispute-policy-12jul04.htm.

The registry operator is committed to using best practice standards as described by industry members and ICANN.

Data Escrow Service

To ensure compliance with the Data Escrow requirements the registry will be using Iron Mountain to act as the third party data escrow agent (see answer 38 for details). All data uploaded to the escrow agent will follow the specifications published at http:⁄⁄tools.ietf.org⁄html⁄draft-arias-noguchi-registry-data-escrow-02 or any successor RFC.

The purpose of the third party data escrow service is to allow a registry data transition in the case that the registry provider fails to fulfill its SLA or is incapable of continuing the registry operations in a manner defined by ICANN.

Reports will be generated on a regular basis to be used for reportings to ICANN.


A. Receipt of Data from Registrars

A.1 Extensible Provisioning Protocol (EPP)

For the purpose of data exchange with the registrar, EPP is used in combination with an SSL encryption on a dedicated port. The registry will issue an SSL certificate for usage by the registrars.

Our EPP specifications follow the existing RFCs and will comply with all relevant successor standards. RFCs considered for the EPP protocol are: RFC 3735, 5730 – 5734, 5910 and 3915.

The following commands will be available for registry operation:

- CreateDomain, CreateContact, CreateHost
- ModifyDomain, ModifyContact, ModifyHost
- InfoDomain, InfoContact, InfoHost
- DeleteDomain, DeleteContact, DeleteHost
- CheckDomain, CheckContact, CheckHost
- TransferDomain
- RenewDomain

Check commands will be available for accredited registrars to check availability of contact handles, host objects, and domain names.

CreateContact will be used to create contact handles used for subsequent domain registrations and modifications.

CreateHost will be used to create host objects serving as nameservers.

CreateDomain will enable all ICANN accredited registrars to create a domain name under the respective TLD of this application.

Several ʺInfoʺ commands will be available to provision status information on domains, contacts and host objects to the accredited registrars.

See attached fig. Q23_Figure1.pdf.

Detailed EPP descriptions can be found in the answers to the questions 25, which are incorporated here by reference.

A.2 Production and Operational Testing and Evaluation (OT&E) EPP Servers

There will be two EPP servers to interact with the registry. One will be for production purposes and the other for testing and evaluation (referred to as the OT&E server) of new software versions and EPP client implementations. The production server consists of at least two load balanced servers (n+1). Each new stable production release will be released on the OT&E EPP server at least 30 days in advance. To increase security, a registrar IP address limitation is in place for the EPP servers (both production and OT&E).

A limitation on the allowable commands per time interval will prevent the registrar from affecting other clients in the SRS environment in regard to performance issues and increased system load.

Each registrar in the SRS environment will be entitled to up to five sessions from two different IP addresses. The registrar will be forced to update the registry password for the EPP servers and registrar extranet (see below) at least once every six months.

A.3 Registrar Extranet and SFTP Area

In addition to the EPP system the registrar can chose to interact with the registry through the registry specific registrar extranet and SFTP area. Access to the SFTP area will be secured by protocol specific encryption mechanisms. Aside from the EPP registrar-registry interaction, the registry extranet is mainly used to adjust registrar specific settings such as accounting, default values for RDDS (WHOIS), and reporting. Different tiers of access are granted to the registrars for this purpose. Access can be limited on a per user and group basis to either read only or write operations for the following objects: domains, hosts, contacts, user and group rights, accounting lists and current account statement.

The registrar extranet will enable registrars to update their IP address range and passwords for the EPP production, OT&E and SFTP areas. When changes are made to the IP address range a support agent will contact the registrar to verify the changes prior to the implementation. The registry will provide marketing material and⁄or detailed reports to all registrars on a regular basis via the registrar specific SFTP area.

Documents will be generated on a regular basis for all registrars and can be found in the SFTP area. These include transaction reports, monthly billing details, and detailed lists on domain names with a status of PendingDelete, domain names under registrarsʹ management, and contacts used.

Access to the registry extranet and SFTP area is also limited to a set of IP addresses as defined by the registrar during the accreditation process.

A.4 Support Case Handling

Each support case received by the KSregistry system either by email (ticket system) or phone will be subject to a passphrase authentication scheme. The passphrases are given during the registrar accreditation process and will be used to identify authorized persons belonging to the registrar. This will thwart any social hacking attempts by unauthorized users.

Support will be handled through 3 different locations:

- USA, VA, Leesburg: 8 am – 5 pm EST ⁄ UTC⁄GMT -5 hours
- Germany, St. Ingbert: 7 am – 6 pm UTC⁄GMT
- Mexico, Monterey: UTC⁄GMT -6 hours

Supported languages are: English, German, Spanish, French, Polish and Mandarin Chinese.

Registrar technical support will be available through a dedicated technical support team 24 x 7 x 365. The support team is committed to delivering support by utilizing best practices and industry standards.

A.5 Provisioning of Zone Status Information to Registrars

Registrars can query the status of a domain name with the “InfoDomain” command or through RDDS. In order to query status information on an existing host-object the command “InfoHost” is used.

The registry operator will inform registrars by email in the cases of unplanned (emergency) or scheduled maintenance.

Information on planned system maintenance will be sent to all accredited registrars at least 30 days prior to the deployment in the OT&E and production system. Registrars will also be informed in the event that system performance drops below normal operational standards and in the event of unforeseen system outages.


B. Dissemination of TLD Zone Files

Nameserver operations for the Registry TLD will comply with RFCs 1034, 1035, and 2182 and all future successors and updates thereto. Additional details on the dissemination of TLD Zone Files can be found in answers to question 35 of this application, which are incorporated here by reference.
Distribution of zone files among all secondary nodes will be handled by a dedicated hidden master.

Updates to the primary master node will be performed every 15 minutes and distributed to a secondary master node (operated by PCH.NET, an external service provider specialized in providing anycast DNS services). For additional stability, the two hidden primary servers (master nodes) will be used in two different geographic locations. All other anycast and unicast nodes will query the secondary master node for zone file updates and update their records accordingly. Several checks will ensure the integrity of the distributed zone file before it is uploaded to the master node. Zone transfers will use the AXFR⁄IXFR zone file transfer method after successful verification of the newly generated zone. The distribution of new zone files will be continuously checked with each of the client nodes.


C. Dissemination of Contact or Other Information Concerning Domain Name Registration

A port 43 RDDS (WHOIS) server (RFC 3912) will be available for legitimate WHOIS lookups. The service will be load balanced on a cluster system updated in near real time. Query limitations on a per IP and subnet basis will apply to prevent system abuse. IP addresses stated in the ICANN RADAR section will be entitled to an increased query limit to facilitate inter-registrar transfers. A website WHOIS will be available on the registryʹs website to facilitate legitimate WHOIS queries using a normal browser. All services will be provided in full compliance with the ICANN requirements and applicable law. Additional details will be described as part of the answer to question 26 (RDDS) and question 44 (IDN).

In order to prevent system abuse of the website whois, a Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) will be used. Each IP address will be entitled to up to six lookups per minute and up to 360 lookups per hour. Each subnet will be entitled to 12 lookups per minute and up to 720 lookups per hour.

IP Addresses listed in the ICANN RADAR section will be entitled to 20 lookups per minute and up to 1200 lookups per hour. For clients using Ipv6, appropriate limitations will be in place to prevent data mining and abusive WHOIS queries.

Information used for WHOIS lookups will be distributed to the WHOIS server cluster using default SQL replication mechanisms. A dedicated read-only database (load balanced) will be used to store all relevant data at the location of the WHOIS server. To prevent any unauthorized access to the database all external communications to the database are blocked.
The WHOIS output will contain information such as domain names and contacts associated with the domain name registration, dates such as registration date and expiration date, status of a domain name, and host objects.

Example Request: Query for domain “example.string” (please refer to Q26 section 8 for additional information concerning the WHOIS output)
Example Response:
Domain Name: EXAMPLE.STRING
Domain ID: 213232132-TLD
WHOIS Server: WHOIS.example.string
Referral URL: http:⁄⁄www.example.string
Updated Date: 2011-07-22T01:44:02Z
Creation Date: 2011-06-01T23:45:33Z
Registry Expiry Date: 2012-06-01T23:59:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR
Sponsoring Registrar IANA ID: 1234567890
Domain Status: clientTransferProhibited
Registrant ID: 123456-STR
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: SOMEWHERE
Registrant State⁄Province: AP
Registrant Postal Code: 12345
Registrant Country: EX
Registrant Phone: +1.5555522222
Registrant Fax: +1.55555544444
Registrant Email: EMAIL@EXAMPLE.STRING
Admin ID: 392839283-STR
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: SOMEWHERE
Admin State⁄Province: AP
Admin Postal Code: 12345
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.STRING
Tech ID: 392811183-STR
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: SOMEWHERE
Tech State⁄Province: AP
Tech Postal Code: 12345
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.STRING
Billing ID: 112811183-STR
Billing Name: EXAMPLE REGISTRAR BILLING
Billing Organization: EXAMPLE REGISTRAR LLC
Billing Street: 123 EXAMPLE STREET
Billing City: SOMEWHERE
Billing State⁄Province: AP
Billing Postal Code: 12345
Billing Country: EX
Billing Phone: +1.1235551234
Billing Phone Ext: 1234
Billing Fax: +1.5555551213
Billing Fax Ext: 93
Billing Email: EMAIL@EXAMPLE.STRING
Name Server: NS01.EXAMPLEREGISTRAR.STRING
Name Server: NS02.EXAMPLEREGISTRAR.STRING
DNSSEC: signedDelegation
DNSSEC: unsigned0


D. Internationalized Domain Names (IDNs)

The applicant will offer IDNs and is in compliance with 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. The registry will 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.
Full detailed description of IDN handling can be found in answers to question 44, which are incorporated here by reference.

The following languages will be supported for this TLD:

- German

See respective language table “Q44_Figure6.pdf” - attached to the answer of question 44.


E. DNS Security Extensions (DNSSEC)

DNS Servers will provide DNSSEC capability according to RFCs 5910, 4641, 4034 and all successors and updates thereto. EPP DNSSEC specifications will be implemented according to RFC 4310. Zones will be signed on the signing server and distributed to the hidden master nameservers which will then distribute them to the secondary servers. A full detailed description of DNS and DNSSEC related topics can be found in answers to question 43, which are incorporated here by reference.


F. Additional Proposed Registry Services

F.1 Bulk Zonefile Access

Clients with a legitimate interest in accessing the registry zone file will be entitled to access this file once a day. For this purpose a dedicated SFTP access will be granted and the zone file will be uploaded once a day. This service will be subject to an additional agreement fully executed between the interested party and the registry.

F.2 Tiered Registration

As this is a single registrant TLD, asidepart from a 30 days sunrise period no additional tiered registration phases will be offered.


G. List of Attachments

- Q23_Figure1.pdf - List of supported EPP commands ⁄ EPP object relationship
- Q23_Figure2.pdf - List of Codes throughout the Application



〉〉 SPECIAL NOTE: IN OUR RESPONSE TO QUESTIONS 25, 29, 32, 36, 42, 43, AND 44 WE ARE DEMONSTRATING EXAMPLES OF CODE TO ILLUSTRATE HOW OUR REGISTRY SERVICES WORK. OUR CODE CONTAINS THE BRACKETS ʺ〈ʺ AND ʺ〉ʺ. WHEN GENERATING HTML PREVIEW VERSIONS OF AN APPLICATION VIA THE TAS, WE HAVE DETECTED THAT BROWSERS, OR PROGRAMS SUCH AS MICROSOFT WORD AND ADOBE READER, DO NOT SHOW THESE CODES (THEY ARE, HOWEVER, SHOWN IF YOU OPEN THE FILE WITH NOTEPAD OR SIMILAR TEXT EDITORS). HENCE, WE HAVE DECIDED TO ATTACH CODE FOR QUESTIONS 25, 29, 32, 36, 42, 43, AND 44 IN ORDER FOR EVALUATORS TO HAVE AN EASY ACCESS TO ALL THE CODE EXAMPLES.