Back

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

gTLDFull Legal NameE-mail suffixDetail
.topJiangsu Bangning Science & Technology Co.,Ltd.55hl.comView
23. Registry Services
23.1. Registry Services
The Applicant is the Registry Operator of ʺ.STRINGʺ.
The Applicant will be responsible for providing the services as specified in Specification 6 section 2.1(a) and (b) and Appendix A in the ICANN’s Applicant Guidebook as well as those as specified in Appendix A. In particular, The Applicant shall prohibit the use of wildcard per requirements specified in Specification 6, section 2.2.
The Applicant provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the Applicant will abide with the requirements of ICANN and IANA and shall comply to the technical standards as specified in Specification 6, Section 1 of the ICANN’s Application Guidebook. The Applicant shall also implement support for IDN, DNSSEC and IPv6.
The Applicant will outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled by Zodiac Holdings Limited.
The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide robust and highly available registry services.
Zodiac Holdings Limited, ie the Business Registry Operator (“BRO”) will have a combined business registry operation team for all its TLD Registry operation. The Business Operation Provider shall provide an effective business operation team that guarantee the highest performance to ensure business continuity as well as reducing domain name abuses.
Note: The Specifications stated in this document refer to the Specifications in ICANNʹs gTLD Applicant Guidebook.
23.1.1. Service Level
KSRP conforms to the requirements in Specification 10 of ICANNʹs Applicant Guidebook. For the summary of the service level agreement, please refer to Table 23-1 (attached in Q23 answer).
23.1.2. Security
KSRP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:
a) A set of operation policies and procedures that shall be strictly followed by service operations personnel.
b) A set of security policies that shall be strictly followed for service management and engineering activities.
c) A monitoring center that is only accessible by authorized staff members. Any management operation is performed on a bastion host only after an authorized staff member successfully logs in to the bastion host with a correct password; comprehensive logging and auditing are enforced for all activities for the entire process;
d) All equipment and services are being monitored on a 7×24 basis by a technical team. In case of emergency, risks will be assessed and mitigated with minimum delay.
e) The firewalls, IDS and network traffic monitoring system are deployed in to provide network layer security and protection against attacks;
f) The databases, applications, source code, documents, system logs and other business data of all services are backed up offsite and offline on a regular basis so that they can be restored quickly in case of a failure;
g) Critical data are transferred via a secure channel, such as VPN, HTTPS, and TSIG with data validation to ensure security and integrity.
Additional measures specific to a subsystem will be documented in the section of that subsystem.
23.1.3. Stability
The Applicant adopts the following measures to ensure the stability of its services. Additional measures specific to a subsystem will be documented in the section of that subsystem.
a) A primary data center and a geo-dispersed backup data center are deployed in an active⁄standby manner; when the primary data center is not available, the backup data center is activated to continue the services; high availability of the services are guaranteed by measures such as database hot standby and server clustering via load balancing;
b) The services provided by the Applicant fully comply with relevant RFCs and other widely accepted industry technical standards. The system will undergo a series of sustained stress testing before the service is open to the public;
c) All equipment, power supplies, network interfaces and network connectivity are deployed in a redundant way so that no single point of failure would result in service interruption;
d) During the daily operation of the services, the operating team closely monitors the system in terms of equipment load, network bandwidth and response performance to ensure capacity sufficiency and redundancy during peak business hours;
e) The SLAs of all registry services are actively monitored and maintained pursuant to ICANN requirements (Specification 10 of gTLD Application Guide book).
23.2. The Receipt of Data from Registrars Concerning Registrations of Domain Names and Name Servers
The Applicant receives the data from Registrars concerning registrations of domain names and name servers.
The Applicant provides the SRS service. Registrars collect the data from end users related to registration contacts, domain names and name servers and submit them to the Applicant via the SRS system; the Applicant also provides add-on auxiliary services for Registrars to submit other business-related data as required by the Applicant;
23.2.1. Service Level
The service level of the SRS provided by the Applicant meets the requirements specified in Specification 10 of ICANNʹs Applicant Guidebook. Please refer to the answer to Q24 Share Registration System (24.2.2) for details.
23.2.2. Security
Only ICANN accredited Registrars are considered to be candidate Registrars for the Applicant.
To connect to the SRS platform of the Applicant, a Registrar must provide a set of fixed static IP addresses to the Applicant beforehand. The SRS service only opens specified service ports to those static IP addresses provided by the Registrar. Dynamic IP addresses are not accepted.
The SRS system employs a combination of Registrar ID, high-security password authentication, Registrar certificate authentication and encryption protocol to ensure the connection between the Registry and a Registrar is secure and robust for data transfer.
To mitigate the risk of malicious cybersquatting, the SRS system enforces a cap on the maximum number of sessions between the Registry and a Registrar, and the maximum number of transactions in unit time from a Registrar.
23.2.3. Stability
The SRS service provided by the Applicant complies with the relevant policy requirements of ICANN. It conforms with the EPP1.0 and other relevant RFCs including RFCs 5730-5734, RFC 3735 and RFC 3915.
The Applicant provides Registrars with the adequately tested EPP Client SDK and manual.
The SRS service puts a cap on the number of connections and the transaction volume in unit time for each Registrar System capacity for peak business hours is ensured by hardware redundancy and load balancing.
23.3. Information Publication
The Applicant will build its official website to make the following information available:
a) Registration management policies;
b) Hotline and Email address for complaints⁄reporting;
c) Public key for DNSSEC;
d) Incident report;
e) Advanced notice of planned outage (due to system upgrade, etc.)
f) SLA report;
g) Whois service.
The Applicant will also release necessary information on these topics via Email to relevant parties including ICANN,IANA,Registrars,Registrants etc.
23.4. Provision of Status Information Relating to the Zone Servers for the TLD
When a Registrar requests for any information such as the status of zone servers, the Applicant will provide such information to the Registrar via Email or by telephone following the pre-defined procedures.
In case there is a change made or planned to be made to the zone servers, such as adjustment of volume of nodes and status transition, affected Registrars will be informed in accordance with the pre-defined procedures.
For security and stability concerns, the service is only made available to those accredited Registrars according to the pre-defined procedures.
23.5. Dissemination of TLD Zone Files
The dissemination of TLD zone files from the central database to DNS service nodes is done by the zone file generation program, dissemination program and the hierarchically and globally distributed DNS system.
All changes in DNS records generated by the data centers are first updated to the primary DNS node; these updates are then disseminated by the master⁄slave update mechanisms to all other DNS nodes.
23.5.1. Service Level
The SRS service level provided by the Applicant meets the Specification 10 of the ICANNʹs Applicant Guidebook. Please refer to the answer to Q35 DNS Service (35.3) for details.
23.5.2. Security
In addition to those described in 23.1.1, the following security measures are also adopted.
The data source of zone files is stored in the domain name database deployed behind the internal firewall with the top-level network security policies. The zone files generation program and the SRS system are located in the DMZ.
The zone files dissemination program supports two modes: full update and incremental update. The incremental update is invoked periodically while the full update is triggered only by unusual circumstances to ensure service ability.
a) Full update. The zone files generation program reads the data in the domain name database to generate the complete zone files. The database connection used by the generation program is read-only. The generated zone files will undergo a series of checks in terms of integrity, syntax and data change rate before invoking the subsequent dissemination procedures.
The data change rate check inspects whether the number of lines in the zone files and⁄or their sizes have changed significantly. If the change is over 5% since the last backup, alarm will be triggered.
Once the zone files are generated and pass the validations, they will be first transferred to the hidden master DNS server. When the system invokes full update, they will be distributed to the global authoritative DNS nodes through the master⁄slave update mechanism of DNS.
b) Incremental update. This program monitors any zone-file-related data changes occurred in the SRS database. When such changes occur, the changed data will be sent to the hidden primary DNS on a periodic basis, and then disseminated to the global authoritative DNS nodes by the master⁄slave update mechanism of DNS. The system automatically checks incremental update data and confirms that each update is properly performed. If any abnormal changes are detected, the system automatically generates an alarm and aborts the update.
23.5.2.1. Data Transfer Security
a) The data transfer between the hidden primary DNS and the global distributed resolution nodes is done via VPN;
b) Digital signature is added using TSIG;
c) Some specified test is performed to check the consistency of the DNS data.
23.5.3. Stability
In addition to those described in 23.1.2, the following stability measures apply to zone file dissemination:
a) The interfaces between the SRS and the hidden master DNS server conforms to RFC 2136 and RFC 2137;
b) Zone files of the hidden master DNS are transferred to the global distributed DNS nodes via incremental zone files using the TSIG per RFC 1995, RFC 1996 and RFC 2845.
23.6. Operations of the Registry Zone Servers
The Back-End Service Provider is in charge of the operation of the zone servers as part of the KSRP. It has many years of experiences in developing and operating domain name system in China.
The operations of the zone servers mainly involve synchronization of resolution data, response to DNS queries, statistics monitoring and reporting, and continuous improvement of security, stability and performance. The goal is to provide correct, reliable and fast DNS services to the global Internet users for the Applicant.
23.6.1. Security
In addition to those described in 23.1.2, there are also the following security measures for zone server operations.
The Back-End Service Provider has deployed global production zone servers based on RFC 2870, such that:
a) The capacity exceeds 3 times of the peak traffic volume;
b) Recursive queries and other services such as remote Internet protocols including HTTP, TELNET, RLOGIN and FTP are strictly forbidden;
c) Hidden primary DNS servers are deployed in the system for zone file updates;
The Back-End Service Provider has established the primary⁄backup data centers and globally distributed DNS nodes with access to the Internet from more than one ISP in each location to ensure uninterrupted DNS services against natural and⁄or human-caused disasters.
Zone file transfer is secured by ACL policies of routers⁄switches⁄IPtables, restriction of IP address in zone files such as allow-notify and allow-transfer, as well as TSIG.
The primary and backup data centers use VPN to ensure network layer security of data transfer.
KSRP employs sophisticated automated monitoring system to timely detect any failures of zone servers as well as other software and⁄or hardware failures, and resolve traffic anomalies. It performs real-time monitoring and analyses to detect potential attacks and to take necessary actions against them.
In addition, The Back-End Service Provider is developing a domain security software to further enhance KSRPʹs abilities to handle more sophisticated security threads. The new capabilities will be gradually applied to the shared TLD production once it is fully developed and tested.
23.6.2. Stability
In addition to those described in 23.1.3, the following stability measures apply to DNS zone servers.
a) The Back-End Service Provider uses the latest stable version of ISC BIND and NSD to ensure that DNS software deployed for KSRP are most updated against known security vulnerabilities.
b) The primary and backup data centers use VPN for secure and stable data transfer.
c) The Back-End Service Provider has provisioned additional network bandwidth in each of the data centers hosting the DNS zone servers to handle unexpected high volume domain name queries to DNS servers. Refer to specific sections for details.
d) The Back-End Service Provider uses BGP+Anycast technologies to build the global distributed domain name resolution service platform where polices can be adjusted to schedule and limit traffic in any unusual circumstances (especially in the case of DDoS attacks).
23.7. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations in the TLD
The Applicant provides the domain name query, contact query and name server query services according to the data contents and formats requirements stated in Specification 4 of ICANNʹs Applicant Guidebook.
The Applicant provides the Web Whois and Whois Server services and disseminates contact and other information concerning TLD server registration according to the Registryʹs protocols.
The Applicant provides two types of Whois query service: general queries and searchable queries.
The Applicant provides ICANN and other authorized third parties access to the “.STRING” zone files.
The Applicant provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level
The service level provided by the Applicant meets Specification 10 specified in the Applicant Guidebook. Please refer to the answer to Q26 Whois System (26.2.2) for details.
23.7.2. Security
In addition to those described in 23.1.2, the following security measures apply to services in section 23.7.
a) No sensitive data are stored in Whois database.
b) The Web Whois service uses the CAPTCHA to reduce automated malicious queries.
c) Both Web Whois and Whois Server services impose a cap on the maximum number of queries in unit time from the same IP address to reduce the query volume from automated programs.
23.7.3. Stability
In addition to those described in 23.1.3, the following stability measures apply to services in section 23.7.
a) The Whois service follows RFC 3912, meeting the requirements specified in Specifications 4, 6 and 10 of the ICANNʹs gTLD Applicant Guidebook.
b) The Whois service runs on redundant server clusters that are load balanced; an offsite backup data center is established to address disastrous emergencies.
23.8. Internationalized Domain Name Service
The TLD applied in this application is an internationalized domain name. The Back-End Service Provider formulated the IDN policies for ʺ.STRINGʺ TLD and developed KSRP based on the latest IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄implementation-guidelines.htm).
The IDN labels in the Applicant follow the .CN Chinese IDN Table and KSRPʹs IDN support complies with the IETF protocols (RFC 3454, 3490, 3491 and 3492) and IDNA2008 (RFC 5890, 5891, 5892, 5893 and 5894).
KSRP accepts IDN registration requests and performs registration for the original applied IDN. Any newly registered domain names must go through pre-auditing by the auditing system of the Registry business support platform. The audit system will generate a group of IDNs from those variant characters of the new domain name based on RFC 3743 and display those in the group that are already registered. An auditor will perform the pre-auditing on these variants using a set of predefined examination rules. The auditor may reject the registration of the new domain name if it is deemed to cause confusion due to visual similarity.
The query function of the Whois system accepts domain names in both UTF8 and ASCII formats.
The zone file generation program directly reads the domain name Punycode strings and other relevant data stored in the database to generate zone files. KSRPʹs zone file dissemination subsystem described in 23.5 supports zone data in Punycode format.
23.8.1. Security
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國. The Back-End Service Provider is confident that registration of the IDNs through the above-mentioned technical business system is free from any security risk.
23.8.2. Stability
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國, The Back-End Service Provider is confident that the performance of the IDN business following the above-mentioned technical business system is free from any stability risk.
Theoretically, creating IDN domain names takes longer in KSRP due to additional computational overhead incurred by the existence of IDN variants. However, such simple computations have a very small impact on the performance. In order to improve the performance of DNS data dissemination, the SRS system stores the corresponding Punycode character strings for the registered IDNs, consequently eliminating additional computation brought by zone files generation. Moreover, since only the original character string within the group of variants is allowed to be submitted by the user, storage capacity for IDN is not increased.
Meanwhile, compared with ASCII-based domain names, IDNs do exhibit a common display problem. However, the display of Chinese characters currently has matured and the Registry services provided for ʺ.STRINGʺ have very good support for displaying Chinese domain names.
In summary, the introduction of IDNs in ʺ.STRINGʺ Registry shall have negligible impact on the performance of its Registry services.
23.9. DNSSEC
KSRP is designed to fully support DNSSEC. The Applicant provides the following DNSSEC services:
a) Authentication and distribution of public keys of KSKs;
b) DNSSEC-based DNS services;
c) Data protection during zone files transfer.
The Applicant deems DNSSEC as critical for its registry services. The Back-End Service Provider plans to actively drive adoption of DNSSEC in KSRP in 3 stages:
a) Stage 1: Test-Bed. At this stage, The Back-End Service Provider intends to build an internal test-bed on which the technical tracking, verification and testing will be performed; the DNSSEC chain of trust will be built on a small set of selected second and lower level domains under the applied TLD; the DNSSEC Operational Practices (RFC 4641) will be followed and exercised. The goal is to complete the technical verification of DNSSEC and to develop best practice documentations based on the lessons learned. This stage is estimated to last for 6 months;
b) Stage 2: Public Trial. At this stage, the chain of trust will be built on domain names that are registered for trial based on the best practice developed at the first stage, and the DNSSEC policies will be verified or adjusted based on the trial results. This stage is estimated to last for 6 months;
c) Stage 3: Production. At this stage, the DNSSEC will be put into use officially according to the achievements of the previous two stages. The implementation of DNSSEC will be applied to the TLD and all of its sub domains in production KSRP.
After implementation of DNSSEC, the performance indicators of relevant services will be affected to some extent, such as increase in storage capacity, in CPU load and memory of the resolution system and in network bandwidth for resolution services. However, such implementation has only negligible impact on resolution query performance and QPS. Through vertical extension, horizontal extension and bandwidth upgrade, KSRP will still be able to sufficiently meet and exceed the service levels required by ICANN stated in this application.
23.9.1. Security
DNSSEC is one of the important measures against the security defect of DNS system. The public key infrastructure (PKI) is used to add a digital signature to each resource record set to improve the security level of domain system.
There are two kinds of keys, KSK (Key-signing Key) and ZSK (Zone-signing Key), created for DNSSEC. The former is used to sign DNSKEY resource record sets while the latter is used to generate signatures for all resource records within the zone, including KSK record sets.
KSRP uses hardware encryption equipment HSM (complying with FIPS 142-2 level 3) to generate keys; the keys stored in an HSM cannot be exported; they are automatically synchronized among the HSMs. Unauthorized access to private keys of KSK and ZSK is strictly forbidden, and offline storage is achieved with best possible efforts.
A periodic key update system is established, in which the KSK lifetime is 1 year and the ZSK lifetime is 1 month.
23.9.2. Stability
The DNSSEC deployment in KSRP is compliant with RFCs 4033~4035, RFC 4310, RFC 4509, RFC 4641, RFC 5155, RFC 5910 for DNS data origin authentication, data integrity verification and authenticated denial of existence.
KSRP is designed to fully support DNSSEC, by reserving interfaces for SRS, Whois and DNS systems.
As DNSSEC signature involves significant computation and data volume, generation and verification these signatures will result in much more CPU time; the disk space incurred by signatures and keys storage will be 10 times or more of that without DNSSEC.
Before DNSSEC is fully deployed for the Applicant, The Back-End Service Provider will upgrade KSRP capacity in database backend servers, disk space, network bandwidth, DNSSEC signing device, other supporting systems and equipment to ensure operation stability and redundancy.
gTLDFull Legal NameE-mail suffixDetail
.商城Zodiac Capricorn Limitedzodiac-corp.comView
23. Registry Services
23.1. Registry Services
The Applicant is the Registry Operator of ʺ.STRINGʺ.
The Applicant will be responsible for providing the services as specified in Specification 6 section 2.1(a) and (b) and Appendix A in the ICANN’s Applicant Guidebook as well as those as specified in Appendix A. In particular, The Applicant shall prohibit the use of wildcard per requirements specified in Specification 6, section 2.2.
The Applicant provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the Applicant will abide with the requirements of ICANN and IANA and shall comply to the technical standards as specified in Specification 6, Section 1 of the ICANN’s Application Guidebook. The Applicant shall also implement support for IDN, DNSSEC and IPv6.
The Applicant will outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled by Zodiac Holdings Limited.
The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide robust and highly available registry services.
Zodiac Holdings Limited, ie the Business Registry Operator (“BRO”) will have a combined business registry operation team for all its TLD Registry operation. The Business Operation Provider shall provide an effective business operation team that guarantee the highest performance to ensure business continuity as well as reducing domain name abuses.
Note: The Specifications stated in this document refer to the Specifications in ICANNʹs gTLD Applicant Guidebook.
23.1.1. Service Level
KSRP conforms to the requirements in Specification 10 of ICANNʹs Applicant Guidebook. For the summary of the service level agreement, please refer to Table 23-1 (attached in Q23 answer).
23.1.2. Security
KSRP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:
a) A set of operation policies and procedures that shall be strictly followed by service operations personnel.
b) A set of security policies that shall be strictly followed for service management and engineering activities.
c) A monitoring center that is only accessible by authorized staff members. Any management operation is performed on a bastion host only after an authorized staff member successfully logs in to the bastion host with a correct password; comprehensive logging and auditing are enforced for all activities for the entire process;
d) All equipment and services are being monitored on a 7×24 basis by a technical team. In case of emergency, risks will be assessed and mitigated with minimum delay.
e) The firewalls, IDS and network traffic monitoring system are deployed in to provide network layer security and protection against attacks;
f) The databases, applications, source code, documents, system logs and other business data of all services are backed up offsite and offline on a regular basis so that they can be restored quickly in case of a failure;
g) Critical data are transferred via a secure channel, such as VPN, HTTPS, and TSIG with data validation to ensure security and integrity.
Additional measures specific to a subsystem will be documented in the section of that subsystem.
23.1.3. Stability
The Applicant adopts the following measures to ensure the stability of its services. Additional measures specific to a subsystem will be documented in the section of that subsystem.
a) A primary data center and a geo-dispersed backup data center are deployed in an active⁄standby manner; when the primary data center is not available, the backup data center is activated to continue the services; high availability of the services are guaranteed by measures such as database hot standby and server clustering via load balancing;
b) The services provided by the Applicant fully comply with relevant RFCs and other widely accepted industry technical standards. The system will undergo a series of sustained stress testing before the service is open to the public;
c) All equipment, power supplies, network interfaces and network connectivity are deployed in a redundant way so that no single point of failure would result in service interruption;
d) During the daily operation of the services, the operating team closely monitors the system in terms of equipment load, network bandwidth and response performance to ensure capacity sufficiency and redundancy during peak business hours;
e) The SLAs of all registry services are actively monitored and maintained pursuant to ICANN requirements (Specification 10 of gTLD Application Guide book).
23.2. The Receipt of Data from Registrars Concerning Registrations of Domain Names and Name Servers
The Applicant receives the data from Registrars concerning registrations of domain names and name servers.
The Applicant provides the SRS service. Registrars collect the data from end users related to registration contacts, domain names and name servers and submit them to the Applicant via the SRS system; the Applicant also provides add-on auxiliary services for Registrars to submit other business-related data as required by the Applicant;
23.2.1. Service Level
The service level of the SRS provided by the Applicant meets the requirements specified in Specification 10 of ICANNʹs Applicant Guidebook. Please refer to the answer to Q24 Share Registration System (24.2.2) for details.
23.2.2. Security
Only ICANN accredited Registrars are considered to be candidate Registrars for the Applicant.
To connect to the SRS platform of the Applicant, a Registrar must provide a set of fixed static IP addresses to the Applicant beforehand. The SRS service only opens specified service ports to those static IP addresses provided by the Registrar. Dynamic IP addresses are not accepted.
The SRS system employs a combination of Registrar ID, high-security password authentication, Registrar certificate authentication and encryption protocol to ensure the connection between the Registry and a Registrar is secure and robust for data transfer.
To mitigate the risk of malicious cybersquatting, the SRS system enforces a cap on the maximum number of sessions between the Registry and a Registrar, and the maximum number of transactions in unit time from a Registrar.
23.2.3. Stability
The SRS service provided by the Applicant complies with the relevant policy requirements of ICANN. It conforms with the EPP1.0 and other relevant RFCs including RFCs 5730-5734, RFC 3735 and RFC 3915.
The Applicant provides Registrars with the adequately tested EPP Client SDK and manual.
The SRS service puts a cap on the number of connections and the transaction volume in unit time for each Registrar System capacity for peak business hours is ensured by hardware redundancy and load balancing.
23.3. Information Publication
The Applicant will build its official website to make the following information available:
a) Registration management policies;
b) Hotline and Email address for complaints⁄reporting;
c) Public key for DNSSEC;
d) Incident report;
e) Advanced notice of planned outage (due to system upgrade, etc.)
f) SLA report;
g) Whois service.
The Applicant will also release necessary information on these topics via Email to relevant parties including ICANN,IANA,Registrars,Registrants etc.
23.4. Provision of Status Information Relating to the Zone Servers for the TLD
When a Registrar requests for any information such as the status of zone servers, the Applicant will provide such information to the Registrar via Email or by telephone following the pre-defined procedures.
In case there is a change made or planned to be made to the zone servers, such as adjustment of volume of nodes and status transition, affected Registrars will be informed in accordance with the pre-defined procedures.
For security and stability concerns, the service is only made available to those accredited Registrars according to the pre-defined procedures.
23.5. Dissemination of TLD Zone Files
The dissemination of TLD zone files from the central database to DNS service nodes is done by the zone file generation program, dissemination program and the hierarchically and globally distributed DNS system.
All changes in DNS records generated by the data centers are first updated to the primary DNS node; these updates are then disseminated by the master⁄slave update mechanisms to all other DNS nodes.
23.5.1. Service Level
The SRS service level provided by the Applicant meets the Specification 10 of the ICANNʹs Applicant Guidebook. Please refer to the answer to Q35 DNS Service (35.3) for details.
23.5.2. Security
In addition to those described in 23.1.1, the following security measures are also adopted.
The data source of zone files is stored in the domain name database deployed behind the internal firewall with the top-level network security policies. The zone files generation program and the SRS system are located in the DMZ.
The zone files dissemination program supports two modes: full update and incremental update. The incremental update is invoked periodically while the full update is triggered only by unusual circumstances to ensure service ability.
a) Full update. The zone files generation program reads the data in the domain name database to generate the complete zone files. The database connection used by the generation program is read-only. The generated zone files will undergo a series of checks in terms of integrity, syntax and data change rate before invoking the subsequent dissemination procedures.
The data change rate check inspects whether the number of lines in the zone files and⁄or their sizes have changed significantly. If the change is over 5% since the last backup, alarm will be triggered.
Once the zone files are generated and pass the validations, they will be first transferred to the hidden master DNS server. When the system invokes full update, they will be distributed to the global authoritative DNS nodes through the master⁄slave update mechanism of DNS.
b) Incremental update. This program monitors any zone-file-related data changes occurred in the SRS database. When such changes occur, the changed data will be sent to the hidden primary DNS on a periodic basis, and then disseminated to the global authoritative DNS nodes by the master⁄slave update mechanism of DNS. The system automatically checks incremental update data and confirms that each update is properly performed. If any abnormal changes are detected, the system automatically generates an alarm and aborts the update.
23.5.2.1. Data Transfer Security
a) The data transfer between the hidden primary DNS and the global distributed resolution nodes is done via VPN;
b) Digital signature is added using TSIG;
c) Some specified test is performed to check the consistency of the DNS data.
23.5.3. Stability
In addition to those described in 23.1.2, the following stability measures apply to zone file dissemination:
a) The interfaces between the SRS and the hidden master DNS server conforms to RFC 2136 and RFC 2137;
b) Zone files of the hidden master DNS are transferred to the global distributed DNS nodes via incremental zone files using the TSIG per RFC 1995, RFC 1996 and RFC 2845.
23.6. Operations of the Registry Zone Servers
The Back-End Service Provider is in charge of the operation of the zone servers as part of the KSRP. It has many years of experiences in developing and operating domain name system in China.
The operations of the zone servers mainly involve synchronization of resolution data, response to DNS queries, statistics monitoring and reporting, and continuous improvement of security, stability and performance. The goal is to provide correct, reliable and fast DNS services to the global Internet users for the Applicant.
23.6.1. Security
In addition to those described in 23.1.2, there are also the following security measures for zone server operations.
The Back-End Service Provider has deployed global production zone servers based on RFC 2870, such that:
a) The capacity exceeds 3 times of the peak traffic volume;
b) Recursive queries and other services such as remote Internet protocols including HTTP, TELNET, RLOGIN and FTP are strictly forbidden;
c) Hidden primary DNS servers are deployed in the system for zone file updates;
The Back-End Service Provider has established the primary⁄backup data centers and globally distributed DNS nodes with access to the Internet from more than one ISP in each location to ensure uninterrupted DNS services against natural and⁄or human-caused disasters.
Zone file transfer is secured by ACL policies of routers⁄switches⁄IPtables, restriction of IP address in zone files such as allow-notify and allow-transfer, as well as TSIG.
The primary and backup data centers use VPN to ensure network layer security of data transfer.
KSRP employs sophisticated automated monitoring system to timely detect any failures of zone servers as well as other software and⁄or hardware failures, and resolve traffic anomalies. It performs real-time monitoring and analyses to detect potential attacks and to take necessary actions against them.
In addition, The Back-End Service Provider is developing a domain security software to further enhance KSRPʹs abilities to handle more sophisticated security threads. The new capabilities will be gradually applied to the shared TLD production once it is fully developed and tested.
23.6.2. Stability
In addition to those described in 23.1.3, the following stability measures apply to DNS zone servers.
a) The Back-End Service Provider uses the latest stable version of ISC BIND and NSD to ensure that DNS software deployed for KSRP are most updated against known security vulnerabilities.
b) The primary and backup data centers use VPN for secure and stable data transfer.
c) The Back-End Service Provider has provisioned additional network bandwidth in each of the data centers hosting the DNS zone servers to handle unexpected high volume domain name queries to DNS servers. Refer to specific sections for details.
d) The Back-End Service Provider uses BGP+Anycast technologies to build the global distributed domain name resolution service platform where polices can be adjusted to schedule and limit traffic in any unusual circumstances (especially in the case of DDoS attacks).
23.7. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations in the TLD
The Applicant provides the domain name query, contact query and name server query services according to the data contents and formats requirements stated in Specification 4 of ICANNʹs Applicant Guidebook.
The Applicant provides the Web Whois and Whois Server services and disseminates contact and other information concerning TLD server registration according to the Registryʹs protocols.
The Applicant provides two types of Whois query service: general queries and searchable queries.
The Applicant provides ICANN and other authorized third parties access to the “.STRING” zone files.
The Applicant provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level
The service level provided by the Applicant meets Specification 10 specified in the Applicant Guidebook. Please refer to the answer to Q26 Whois System (26.2.2) for details.
23.7.2. Security
In addition to those described in 23.1.2, the following security measures apply to services in section 23.7.
a) No sensitive data are stored in Whois database.
b) The Web Whois service uses the CAPTCHA to reduce automated malicious queries.
c) Both Web Whois and Whois Server services impose a cap on the maximum number of queries in unit time from the same IP address to reduce the query volume from automated programs.
23.7.3. Stability
In addition to those described in 23.1.3, the following stability measures apply to services in section 23.7.
a) The Whois service follows RFC 3912, meeting the requirements specified in Specifications 4, 6 and 10 of the ICANNʹs gTLD Applicant Guidebook.
b) The Whois service runs on redundant server clusters that are load balanced; an offsite backup data center is established to address disastrous emergencies.
23.8. Internationalized Domain Name Service
The TLD applied in this application is an internationalized domain name. The Back-End Service Provider formulated the IDN policies for ʺ.STRINGʺ TLD and developed KSRP based on the latest IDN Implementation Guidelines (http:⁄⁄www.icann.org⁄en⁄topics⁄idn⁄implementation-guidelines.htm).
The IDN labels in the Applicant follow the .CN Chinese IDN Table and KSRPʹs IDN support complies with the IETF protocols (RFC 3454, 3490, 3491 and 3492) and IDNA2008 (RFC 5890, 5891, 5892, 5893 and 5894).
KSRP accepts IDN registration requests and performs registration for the original applied IDN. Any newly registered domain names must go through pre-auditing by the auditing system of the Registry business support platform. The audit system will generate a group of IDNs from those variant characters of the new domain name based on RFC 3743 and display those in the group that are already registered. An auditor will perform the pre-auditing on these variants using a set of predefined examination rules. The auditor may reject the registration of the new domain name if it is deemed to cause confusion due to visual similarity.
The query function of the Whois system accepts domain names in both UTF8 and ASCII formats.
The zone file generation program directly reads the domain name Punycode strings and other relevant data stored in the database to generate zone files. KSRPʹs zone file dissemination subsystem described in 23.5 supports zone data in Punycode format.
23.8.1. Security
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國. The Back-End Service Provider is confident that registration of the IDNs through the above-mentioned technical business system is free from any security risk.
23.8.2. Stability
With many years of experiences in operating.CN (supporting IDN) and .中国⁄.中國, The Back-End Service Provider is confident that the performance of the IDN business following the above-mentioned technical business system is free from any stability risk.
Theoretically, creating IDN domain names takes longer in KSRP due to additional computational overhead incurred by the existence of IDN variants. However, such simple computations have a very small impact on the performance. In order to improve the performance of DNS data dissemination, the SRS system stores the corresponding Punycode character strings for the registered IDNs, consequently eliminating additional computation brought by zone files generation. Moreover, since only the original character string within the group of variants is allowed to be submitted by the user, storage capacity for IDN is not increased.
Meanwhile, compared with ASCII-based domain names, IDNs do exhibit a common display problem. However, the display of Chinese characters currently has matured and the Registry services provided for ʺ.STRINGʺ have very good support for displaying Chinese domain names.
In summary, the introduction of IDNs in ʺ.STRINGʺ Registry shall have negligible impact on the performance of its Registry services.
23.9. DNSSEC
KSRP is designed to fully support DNSSEC. The Applicant provides the following DNSSEC services:
a) Authentication and distribution of public keys of KSKs;
b) DNSSEC-based DNS services;
c) Data protection during zone files transfer.
The Applicant deems DNSSEC as critical for its registry services. The Back-End Service Provider plans to actively drive adoption of DNSSEC in KSRP in 3 stages:
a) Stage 1: Test-Bed. At this stage, The Back-End Service Provider intends to build an internal test-bed on which the technical tracking, verification and testing will be performed; the DNSSEC chain of trust will be built on a small set of selected second and lower level domains under the applied TLD; the DNSSEC Operational Practices (RFC 4641) will be followed and exercised. The goal is to complete the technical verification of DNSSEC and to develop best practice documentations based on the lessons learned. This stage is estimated to last for 6 months;
b) Stage 2: Public Trial. At this stage, the chain of trust will be built on domain names that are registered for trial based on the best practice developed at the first stage, and the DNSSEC policies will be verified or adjusted based on the trial results. This stage is estimated to last for 6 months;
c) Stage 3: Production. At this stage, the DNSSEC will be put into use officially according to the achievements of the previous two stages. The implementation of DNSSEC will be applied to the TLD and all of its sub domains in production KSRP.
After implementation of DNSSEC, the performance indicators of relevant services will be affected to some extent, such as increase in storage capacity, in CPU load and memory of the resolution system and in network bandwidth for resolution services. However, such implementation has only negligible impact on resolution query performance and QPS. Through vertical extension, horizontal extension and bandwidth upgrade, KSRP will still be able to sufficiently meet and exceed the service levels required by ICANN stated in this application.
23.9.1. Security
DNSSEC is one of the important measures against the security defect of DNS system. The public key infrastructure (PKI) is used to add a digital signature to each resource record set to improve the security level of domain system.
There are two kinds of keys, KSK (Key-signing Key) and ZSK (Zone-signing Key), created for DNSSEC. The former is used to sign DNSKEY resource record sets while the latter is used to generate signatures for all resource records within the zone, including KSK record sets.
KSRP uses hardware encryption equipment HSM (complying with FIPS 142-2 level 3) to generate keys; the keys stored in an HSM cannot be exported; they are automatically synchronized among the HSMs. Unauthorized access to private keys of KSK and ZSK is strictly forbidden, and offline storage is achieved with best possible efforts.
A periodic key update system is established, in which the KSK lifetime is 1 year and the ZSK lifetime is 1 month.
23.9.2. Stability
The DNSSEC deployment in KSRP is compliant with RFCs 4033~4035, RFC 4310, RFC 4509, RFC 4641, RFC 5155, RFC 5910 for DNS data origin authentication, data integrity verification and authenticated denial of existence.
KSRP is designed to fully support DNSSEC, by reserving interfaces for SRS, Whois and DNS systems.
As DNSSEC signature involves significant computation and data volume, generation and verification these signatures will result in much more CPU time; the disk space incurred by signatures and keys storage will be 10 times or more of that without DNSSEC.
Before DNSSEC is fully deployed for the Applicant, The Back-End Service Provider will upgrade KSRP capacity in database backend servers, disk space, network bandwidth, DNSSEC signing device, other supporting systems and equipment to ensure operation stability and redundancy.