gTLD	Full Legal Name	E-mail suffix	Detail
.公益	China Organizational Name Administration Center	conac.cn	View

23. Registry Services
CONAC will provide registry services in compliance with the requirements in section 2.1 of Specification 6 attached to the Registry Agreement.

CONAC offers customary services such as the receipt of data from registrars concerning registration of domain names and name servers, dissemination of TLD zone files, dissemination of contact and other information concerning domain name registrations (WHOIS service), data escrow, Internationalized Domain Names (IDN) and DNS Security Extensions (DNSSEC). CONAC also has a Business Operation Support System (BOSS) to ensure the normal operation of the registry system.

CONAC conducts systematical risk assessments of the critical functions, identifies the security goals and requirements, develops the corresponding security strategies, security management regulations and plans, and takes effective measures from the perspective of management, technology and operation and maintenance to ensure system security. CONAC curbs the risk in unauthorized disclosure, alternation, insertion or destruction of registry data. Authentication and access control are also introduced to effectively improve business monitoring and auditing, detect abnormal behaviors and misuse and prevent unauthorized access.

CONAC pays close attention to the performance of all the services, and seeks feedback from the stakeholders. CONAC will respond in a timely manner to stakeholder requests on adding new registry services or modifying existing services. Any additional proposed registry services or services to be modified will be forwarded to ICANN for approval pursuant to the Registry Service Evaluation Policy at http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄rsep.html.

The WHOIS system is developed independently by CONAC R&D Department which holds ISO27001 and ISO9001 certificates and has a strong capability for software development. CONAC develops software in strict compliance with Software Development Life Cycle (SDLC), reviews and audits software products and development activities on basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC defines development scope, schedule, and cost. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA). During software designing, programming and software testing, CONAC reviews and audits the software products and development activities to ensure the quality of the software. The outcomes of the project including the design document, source code, testing report and user guide and so on shall be submitted to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems, then deploys the software that passes the tests in the production environment for operation, and continues to provide maintenance and technical supports.

Shared Registration System (SRS), Extensible Provisioning Protocol (EPP) interface, DNS, DNSSEC, data escrow system and BOSS are developed by highly experienced third-party software developers. CONAC selects the third-party developers based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developers develop software in strict compliance with SDLC, review and audit software products and development activities on basis of SQA to ensure all software meet relevant standards. During the planning phase, CONAC signs agreements with the third-party developers, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on SLA to the third-party developers. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developers shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developers.

23.1 Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers
23.1.1 Service Description
CONAC adopts a business model of registry-registrar separation. Therefore, CONAC does not directly accept registrations from registrants, but accredits registrars to process registrants’ application for “.公益” domain names.

In the architecture of registry, registrar and registrant, CONAC, as a registry, is primarily responsible for the establishment, operation and maintenance of SRS and the core database. Registrants can register domain names and complete domain name information management via any registrar accredited by CONAC.

CONAC receives information about registration of domain names and name servers from registrars via SRS. CONAC uses the EPP interface to receive registration information such as domain name, contact person, life cycle and so on, from registrars, and stores the information in the primary operations center. To ensure that only eligible public interest organizations can register domain names in the “.公益” TLD, CONAC will implement a verification process named Pre-registration Qualification Procedures (PQP) including pre-verification and re-verification. Registrars conduct pre-verification which requires prospective registrants to submit documentation certifying they are legitimate public interest organizations. CONAC will conduct re-verification via the BOSS system. Only when the registrant and the applied-for domain name have passed pre-verification and re-verification, can the domain name be valid. For a more detailed description of the PQP, please refer to section 29.2.1 of the responses to Question 29.

23.1.2 Service Level
CONAC strictly complies with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include EPP service availability≤864 min of downtime, EPP session-command Round-Trip Time (RTT)≤4000 ms for at least 90% of the commands, EPP query-command RTT≤2000 ms for at least 90% of the commands, EPP transform-command RTT≤4000 ms for at least 90% of the commands. If the EPP reaches the emergency threshold of 24-hour downtime⁄week, it will cause the emergency transition of the critical function.

23.1.3 Service Interface
CONAC SRS provides the EPP interface to facilitate the communication between CONAC and registrars.

CONAC provides accredited registrars with an EPP client Software Development Kit (SDK) and a complete guidebook, which can help registrars develop registrant-oriented registration service systems by themselves.

As a provider of domain name registration service system, CONAC can provide the registrar who does not have a registration service system with a general version of the registration service software, so as to assist registrars completing their registration management.

23.1.4 Security of the Registry Service
CONAC takes the following measures to guarantee the security of this service.
1. CONAC deploys security protection equipment and a security monitoring system to reinforce system security. For instance, CONAC deploys firewalls to enhance the security of the core database, and a monitoring system to monitor SRS performance and alert intrusions and attacks, so as to ensure continued service.

2. CONAC adopts a security strategy at the application level including limiting the number of sessions connected by TCP and the idle time, password verification for EPP sessions, implementing transport layer security (TLS) protocols, and registrar IP address verification.

3. CONAC sets up the backup operations center with the similar scale as the primary operations center. In the event that a fatal incident occurs and the primary operations center is shut down, the system can be switched to the backup operations center in a timely manner. After failure elimination, the system will be switched back.

These mechanisms will sufficiently ensure the security of operation data, and stability and continuity of the service.

23.1.5 Stability of the Registry Service
SRS and the EPP interface are developed pursuant to RFC3735, RFC5730, RFC5731, RFC5732, RFC5733, RFC5734 and RFC5910. Also, in accordance with RFC 3915, domain name grace period policy is supported in SRS and the EPP interface. SRS is an independent system, in which the application servers and database servers are deployed separately. The application servers are deployed using load balancing. With such a design, SRS does not directly affect or disturb the normal operations of other systems during the operation.

23.2 Dissemination of TLD Zone Files
23.2.1 Service Description
DNS resolution system is accountable for the dissemination of “.公益” TLD zone file. DNS resolution system implements distributed deployment by using anycast and unicast technology. Anycast sites are located in Beijing, Shanghai, Guangzhou, Chengdu, Hong Kong and USA, and cover many Internet Service Providers (ISP) including China Mobile, China Telecom, China Unicom, Hong Kong PCCW Limited, China Science and Technology Network (CSTN), and USA AT&T. All ISPs support IPv4, and CSTN and AT&T also support IPv6. Unicast site is located in the primary operations center in Beijing, and the backup unicast site is located in the backup operations center in Chengdu. Unicast sites use a different AS number from anycast sites. With the technical plan, CONAC realizes the geographic diversity deployment with multi-site distribution, and the reachability of IPv4 and IPv6. For the distribution of DNS resolution sites, please refer to Figure 1 of Q23_attachment.

There are two steps in “.公益” TLD zone file dissemination. The first step is for SRS to generate a zone file to the primary DNS server in the primary operations center. The second step is to synchronize zone file from the primary DNS server to the secondary DNS servers in each site using transmission and update notification mechanism.

To ensure the security of the service, dissemination of “.公益” TLD zone file also includes data synchronization from the primary operations center to the backup operations center. The first is quasi-real time data synchronization between the core database of the primary operations center and the core database of the backup operations center through Oracle Dataguard. The second is data update from SRS to the primary DNS server in the backup operations center.

CONAC permits the authorized third parties who comply with the Zone File Access Agreement (see section 2.1.1 of Specification 4 of Registry Agreement) to access the designated Internet host server, download zone file data, and transmit TLD zone file, associated cryptographic checksum files and a copy of the TLD zone file, no more than once per 24-hour period. The format of the zone file complies with the requirement of section 2.1 in Specification 4 attached to the Registry Agreement.

23.2.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include DNS service availability 0 minute downtime (100% availability), DNS name server availability≤ 432 min of downtime, TCP DNS resolution RTT≤1500 ms for at least 95% of the queries, UDP DNS resolution RTT≤500 ms for at least 95% of the queries, DNS update time ≤60 min for at least 95% of the probes. In the unlikely event that DNS service across all servers reaches the emergency threshold of 4 hours downtime per week, this will trigger the emergency transition of the critical function.

CONAC provides 7X24X365 file transfer protocol (FTP) service.

23.2.3 Service Interface
Data updates from SRS to the primary DNS server of the primary operations center and data updates from the primary DNS server to the secondary DNS servers are all in strict compliance with RFC1034, RFC2181, RFC3901, and RFC4472.

The third party access to the zone file is realized via a zone file FTP service provided by CONAC.

23.2.4 Security of the Registry Service
CONAC will take the following measures to ensure the performance, availability and attack resistance ability of the DNS resolution service.
1. Primary DNS servers in the primary⁄backup operations center are in shadow, and do not provide resolution service, for the sake of the security of the primary DNS servers.
2. DNS resolution system adopts anycast and unicast technology. CONAC deploys 8 DNS sites in the aforementioned 6 cities.
3. Management and communication between servers in the resolution sites and primary DNS server is secured through a transmission channel that supports Internet Protocol Security (IPSec) Virtual Private Network (VPN). Thus, secure encrypted transmission can be realized, and data security can be ensured.
4. Each resolution site has diverse hardware and software configurations which are monitored in real time. Real-time monitoring can detect the abnormal behavior of the software or the hardware, and inform the management team enabling prompt response and resolution.
5. As for Internet users’ access, each user is required to provide information that can sufficiently identify and locate the user. Zone file access and download are only available to users who are authorized and in compliance with Zone File Access Agreement.
6. CONAC will implement various measures for security through the use of Intrusion Detection System⁄Intrusion Prevention System (IDS⁄IPS), traffic cleansing, and real time monitoring.
7. CONAC has well defined policies and procedures for ensuring a secure registry environment. See the response to Question 30a and 30b for details.

23.2.5 Stability of the Service
CONAC’s DNS resolution system uses the most widely used DNS resolution software in the root server, namely, BIND and NSD. The DNS resolution system is an independent system using load balancing. Therefore, it will not directly affect nor interfere the normal operations of other systems.

CONAC’s DNS resolution system complies with RFC1034, RFC1035, RFC1982, RFC2181, RFC2182, RFC2671, RFC3226, RFC3596, RFC3597, RFC4343 and RFC5966. The interface that updates resolution data from SRS to the primary DNS server meets the standard of RFC2136 and RFC2137.

Zone file updates from the primary DNS server to the secondary DNS servers in the 8 resolution sites comply with RFC1996 and RFC2845. Incremental updates are adopted as the basic zone file transmission mechanism to relieve network bandwidth pressure. In the unlikely event that failure occurs to incremental updates, full updates provide a backup.

The primary operations center and the backup operations center are connected with a 10 Mb dedicated connection for incremental updates to relieve pressure on the network. In case of special occasions, the bandwidth can be temporarily upgraded from 10Mb to 100Mb according to emergency response procedures to meet the demands of system services.

23.3 Dissemination of Contact and Other Information Concerning Domain Name Registrations (WHOIS Service)
23.3.1 Service Description
WHOIS is accountable for the dissemination of contact and other information concerning domain name registrations. For the “.公益” domain name information query service, CONAC WHOIS provides the public with Port-43 WHOIS queries, web-based WHOIS queries. In consideration of the special needs of ICANN and the public, bulk WHOIS queries and searchable WHOIS queries are also offered. CONAC will also support RESTful WHOIS, once provided in the final standardized form agreed in the IETF.

Port-43 WHOIS queries and web-based WHOIS queries support exact-match query, thick model WHOIS, as well as queries for domain name data, registrar data and name-server data. Query format and response format comply with the requirements on domain name data, registrar data, and name-server data in section 1.4, 1.5, and 1.6 of Specification 4 attached to the Registry Agreement. In domain name query, the query response format complies with the format in the Specification 4, except that the Punycode form of the domain name will be displayed behind the domain name. In addition, if the domain name is shown differently in simplified Chinese and traditional Chinese, the domain name will be displayed in two different rows.

Bulk WHOIS queries meet requirements in section 3 Bulk Registration Data Access to ICANN of Specification 4 attached to the Registry Agreement.

Searchable WHOIS queries support queries for domain name data. Query conditions meet searching field match in section 1.8.2 and 1.8.3 and Boolean search in section 1.8.4 of the Specification 4. The response format is consistent with corresponding requirements in the Specification 4 for domain name query, except that the Punycode form of the domain name will be displayed behind the domain name. In addition, if the domain name is shown differently in simplified Chinese and traditional Chinese, the domain name will be displayed in two different rows.

CONAC WHOIS queries service provides associated security measures to prevent abusive conducts.

23.3.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Service performance parameters on a monthly basis include Registration Data Directory Services (RDDS) availability≤ 864 min of downtime, RDDS query RTT≤2000 ms for at least 95% of the queries, and RDDS update time ≤60 min for at least 95% of the probes. In the unlikely event that WHOIS service reaches the emergency threshold of 24-hour⁄week, this will trigger the emergency transition of the critical function.

Except for Port-43 WHOIS queries and web-based WHOIS queries, bulk WHOIS queries and searchable WHOIS queries are supported by independent WHOIS servers, and thus service performance of Port-43 WHOIS queries and web-based WHOIS queries will not be affected. CONAC will provide RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.3 Service Interface
In Port-43 WHOIS queries, a registrar initiates a socket connection through the WHOIS client. WHOIS server accepts the connection and the registrar’s WHOIS queries at Port 43. When information is retrieved in the system, the result will be sent to WHOIS client. When all the query data is returned to the client, the socket connection will be automatically closed and the WHOIS query process is ended. If the query information cannot be retrieved by the WHOIS server, a result code and a human-readable description of the result code are returned before the query process is ended.

In a web-based WHOIS query, query for domain name, registrar and name server is supported. Internet users can enter WHOIS queries in the Web page for WHOIS. The query is submitted to the system in the form of tables. WHOIS will respond to the query, and display the results in HTML page.

The searchable WHOIS query can also be realized through web. Bulk WHOIS query is realized via Secure File Transfer Protocol (SFTP) services.

CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.4 Security of the Registry Service
This service highlights the protection of national secrets, commercial secrets and privacy. In consideration of requirements on secret and privacy protection in China as well as ICANN requirements in this regard, SRS duplicates relevant domain name data into WHOIS instances in core database and WHOIS mirror database via its WHOIS data synchronization interface function, and relevant domain name data exclude sensitive data. As there is no sensitive data in WHOIS relevant database, the leakage of sensitive information through WHOIS can be avoided.

CONAC implements the following mechanism to ensure the security of WHOIS services.
1. Security devices and monitoring system are deployed to reinforce the security capability of the system. For instance, firewalls are placed in front of WHOIS. There is also security strategy configuration to prevent malicious attacks and ensure the continuity of the service.

2. Security strategy is implemented at the application level. For instance, idle time and numbers of sessions connected by each transmission control protocol (TCP) are limited. Web-based WHOIS queries use picture based code technology for security, and Port-43 WHOIS queries limit the visiting times of one IP address in unit time to prevent the frequent and malicious visit. In addition, CONAC will implement abuse prevention policies to ensure the security of the WHOIS service. More details can be found in section 26.4 of the response to Question 26.

3. Redundant back-up and load balancing are implemented to ensure the security of WHOIS architecture. The backup operations center is set up, which is of the similar scale as the primary operations center. When a fatal failure occurs to the primary operations center, the system can be switched to the backup operations center in a timely manner. After trouble shooting and resolution of the failure, it will be switched back to the primary operations center.

23.3.5 Stability of the Registry Service
WHOIS is developed in strict compliance with RFC3912, Specification 4 and Specification 10 of the Registry Agreement. WHOIS query format and response format are in compliance with the requirements in Specification 4 of Registry Agreement. The performance of the WHOIS will be tested so as to meet the requirements in section 2 Service Level Agreement Matrix of Specification10 of Registry Agreement.

The registration service system and the EPP interface are in strict compliance with RFC3735, RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, which ensures the stability of the system and data security.

WHOIS is an independent system deployed using load balancing, so it will not directly affect nor interfere the normal operations of other systems.

23.4 Internationalized Domain Names Service
23.4.1 Service Description
“.公益” TLD is a Chinese top level domain. Registration and resolution for simplified Chinese domain name (ASCII included) and traditional Chinese domain name (ASCII included) under “.公益” TLD are supported. CONAC selects “.CN Chinese IDN table” registered and released in IANA website (available at http:⁄⁄www.iana.org⁄domains⁄idn-tables⁄tables⁄cn_zh-cn_4.0.html) as the IDN table used by “.公益” TLD. On the basis of the IDN table, all variants corresponding to the registered “.公益” domain name are taken out and reserved except for the variant domain name which is provided to registrants free of charge, so that the registrant’s interests are protected. IDN services are as follows.

1. CONAC accepts registrars’ registration application for simplified Chinese domain name (ASCII included) and traditional Chinese domain name (ASCII included) under “.公益” TLD. CONAC uses “.CN Chinese IDN Table” which is registered and published on the IANA website and CONAC’s website, so that the expected IDN registrants easily access to the information. CONAC will accept registration for simplified Chinese domain name or traditional Chinese domain name. The mixture of simplified Chinese and traditional Chinese is forbidden. CONAC will implement the registration policy that the registrant applying for a simplified Chinese domain name will be given the traditional counterpart of the domain name free of charge, provided the traditional counterpart submitted by the registrant is in accordance with Chinese IDN table and passes registrar’s and CONAC’s verification. Other forms of variants of the registered domain name, if any, will be reserved and prohibited from new registration. Likewise, the registrant applying for a traditional Chinese domain name will be given the simplified counterpart of the domain name free of charge. Simplified Chinese domain name and traditional Chinese domain name are parallelly provisioned in zone files. This policy will provide the global internet users who use simplified Chinese or traditional Chinese with service of the same quality. The data in the core database for domain name registration are stored in the Unicode format. Unicode of the registered domain name is supported by and can be directly submitted to SRS and EPP interface.

2. CONAC supports the resolution for “.公益” Chinese domain name. When DNS system generates zone file, it can directly read the Punycode strings stored in the database, and add “xn--” before the strings.

3. CONAC supports Chinese WHOIS queries for “.公益” TLD. In Port-43 WHOIS and web-based WHOIS, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query. In searchable WHOIS query, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query, and the response formats meet Specification 4 requirements. In domain name query, the query response format complies with the format in Specification 4, except that Punycode form of the domain name will be displayed behind the domain name. In addition, if the domain name is shown differently in simplified Chinese and traditional Chinese, the domain name will be displayed in two different rows. CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.4.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. The introduction of Chinese domain name will not impair the service level of DNS, RDDS and EPP.

23.4.3 Service Interface
1. SRS and EPP interface. The SRS interface is designed to accept Unicode characters.
2. DNS system. The zone file of DNS system only stores the domain names in the format of Punycode. Therefore, there is no need for change to DNS architecture to support the resolution of “.公益” domain name.
3. WHOIS system. In designing WHOIS system, support to Chinese IDN has been taken into full consideration.

23.4.4 Security of the Registry Service
To prevent malicious registration for similar domain names, spoofing and attacks, CONAC requires registrars to pre-verify the eligibility of registrants and the compliance of the domain name according to Implementing Rules for “.公益” Domain Name Registration (including registrars, registration application and verification, registration fee, domain name disputes, and user complaints) available at http:⁄⁄www.conac.cn. CONAC will re-verify the registration application submitted by registrars in accordance with the same criteria as that of the pre-verification. CONAC has developed effective policies against variant abuse and for anti-abuse protection.

23.4.5 Stability of the Service
This service complies with RFC5890, RFC5891, RFC5892, RFC5893 and RFC5894. Thus SRS⁄EPP, DNS, WHOIS can effectively support the registration and management of “.公益” TLD. By having a policy that limits domain names to simplified Chinese or traditional Chinese and forbids the mixture of the two, the equivalence of simplified Chinese and traditional Chinese is addressed. As a result of implementing the equivalence policy, the volume for registered domain names will at most double (DNSSEC impacts considered). But it does not negatively impact on the stability of the system, as the designed system storage capability exceeds the projected maximum registration volumes, system storage devices can be further extended, and the designed peak transaction processing capability is no less than 3 times the estimated volumes.

23.5 DNS Security Extensions (DNSSEC)
23.5.1 Service Description
In compliance with relevant RFCs concerning DNSSEC, CONAC has established a registry system that can support DNSSEC. EPP interface can support DNSSEC, and CONAC is capable of accepting public key materials (DS records) from registrants through registrars via EPP interface. As DNSSEC is taken into account in designing the registry system, relevant fields are reserved to support the storage of four resource records, namely, Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) and Next Secure3 (NSEC3). Public Key Infrastructure- Certification Authority (PKI-CA) key management system, policies and procedures for key generation, exchange and storage are properly established. At the time of launching DNSSEC, CONAC can ensure that zone files of “.公益” TLD are signed, DS records from child domains are verified and accepted.

DNSSEC services for “.公益” TLD includes the following three aspects.
1. Data origin authentication. It is to verify that the data come from the right name server.
2. Assurance of data integrity. It is to verify that nothing is changed in data transmission.
3. Authenticated denial of existence. It allows a security-aware resolver to authenticate authoritative DNS error indications.

The above information is released to the public in a DNSSEC Policy Statement (DPS) in the response to Question 43.

23.5.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. After the deployment of DNSSEC, our service performance will meet and be superior to ICANN’s service level requirements. In the unlikely event that DNSSEC proper resolution reaches the emergency threshold of 4-hour downtime per week, it will cause the emergency transition of the critical function.

23.5.3 Service Interface
CONAC will provide a DNSSEC interface that will comply with ICANN requirements.
1. Generating Zone-Signing Key (ZSK), Key-Signing Key (KSK) public⁄private key pairs;
2. Generating zone files with DNSSEC records including public key;
3. Incrementally signing the authorized zone files;
4. Submitting KSK-corresponding DS record to root zone;
5. Receiving public key materials (DS records) of “.公益” sub-domain;
6. Signing DS record of the sub-domain.

23.5.4 Security of the Registry Service
DNSSEC is one of the critical measures to address the security defect of DNS system. With robust key management system, CONAC will use Public Key Infrastructure (PKI) to add a digital signature for each resource record so as to improve domain name system security.

DNSSEC establishes two kinds of keys, KSK and ZSK to realize the security of “.公益” TLD zone. KSK is used to sign the DNSKEY resource records. ZSK is used to generate signatures for all the resource records in the zone. Both ZSK’s private key and KSK’s private key are forbidden from unauthorized access, and offline storage should be ensured. A regular update system is established for key management, in which the usage period of KSK is 2 years, and the usage period of ZSK is 3 months (90 days).

23.5.5 Stability of the Registry Service
As COANC’s registry system complies with RFC4033, RFC4034, RFC4035, RFC4310, RFC4509, RFC4641, RFC5155 to support DNSSEC, origin authentication of DNS data, data integrity authentication and authenticated denial of existence will be realized. While implementing DNSSEC, SRS⁄EPP, WHOIS and DNS system need to be modified accordingly.

As a result of large volume of data request for DNSSEC signature, not only the network load of DNS will be increased, but also signature generation and authentication take up more time of CPU and I⁄O. Therefore, disk space taken by signature and key will be around 10 times as large as that before DNSSEC deployment. Accordingly, network bandwidth, server performance, and storage capability in management system need to be increased or upgraded, but as CONAC takes full account of the impact brought by DNSSEC deployment in designing the system, the impact is negligibly minor.

gTLD	Full Legal Name	E-mail suffix	Detail
.政务	China Organizational Name Administration Center	conac.cn	View

23. Registry Services
CONAC will provide registry services in compliance with the requirements in section 2.1 of Specification 6 attached to the Registry Agreement.

CONAC offers customary services such as the receipt of data from registrars concerning registration of domain names and name servers, dissemination of TLD zone files, dissemination of contact and other information concerning domain name registrations (WHOIS service), data escrow, Internationalized Domain Names (IDN) and DNS Security Extensions (DNSSEC). CONAC also has a Business Operation Support System (BOSS) to ensure the normal operation of the registry system.

CONAC conducts systematical risk assessments of the critical functions, identifies the security goals and requirements, develops the corresponding security strategies, security management regulations and plans, and takes effective measures from the perspective of management, technology and operation and maintenance to ensure system security. CONAC curbs the risk in unauthorized disclosure, alternation, insertion or destruction of registry data. Authentication and access control are also introduced to effectively improve business monitoring and auditing, detect abnormal behaviors and misuse and prevent unauthorized access.

CONAC pays close attention to the performance of all the services, and seeks feedback from the stakeholders. CONAC will respond in a timely manner to stakeholder requests on adding new registry services or modifying existing services. Any additional proposed registry services or services to be modified will be forwarded to ICANN for approval pursuant to the Registry Service Evaluation Policy at http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄rsep.html.

The WHOIS system is developed independently by CONAC R&D Department which holds ISO27001 and ISO9001 certificates and has a strong capability for software development. CONAC develops software in strict compliance with Software Development Life Cycle (SDLC), reviews and audits software products and development activities on basis of Software Quality Assurance (SQA) to ensure all software meet relevant standards. During the planning phase, CONAC defines development scope, schedule, and cost. During the demand analysis phase, CONAC proposes business demands and performance demands based on Service Level Agreement (SLA). During software designing, programming and software testing, CONAC reviews and audits the software products and development activities to ensure the quality of the software. The outcomes of the project including the design document, source code, testing report and user guide and so on shall be submitted to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems, then deploys the software that passes the tests in the production environment for operation, and continues to provide maintenance and technical supports.

Shared Registration System (SRS), Extensible Provisioning Protocol (EPP) interface, DNS, DNSSEC, data escrow system and BOSS are developed by highly experienced third-party software developers. CONAC selects the third-party developers based on ISO27000 and ISO9000 certificates and Capability Maturity Model Integration (CMMI). CONAC and the third-party developers develop software in strict compliance with SDLC, review and audit software products and development activities on basis of SQA to ensure all software meet relevant standards. During the planning phase, CONAC signs agreements with the third-party developers, stipulating development scope, schedule, cost, confidentiality as well as conditions for acceptance. During the demand analysis phase, CONAC proposes business demands and performance demands based on SLA to the third-party developers. During software designing, programming and software testing, CONAC participates in reviewing and auditing the software products and development activities to ensure the quality of the software. At the end of the project, the third-party developers shall submit the development outcomes including design document, source code, testing report, user guide and so on to CONAC. CONAC performs business test, performance test, and security test of the software in its own testing systems. The software that has passed the testing will be deployed in the production environment for operation, and maintained by the third-party developers.

23.1 Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers
23.1.1 Service Description
CONAC adopts a business model of registry-registrar separation. Therefore, CONAC does not directly accept registrations from registrants, but accredits registrars to process registrants’ application for “.政务” domain names.

In the architecture of registry, registrar and registrant, CONAC, as a registry, is primarily responsible for the establishment, operation and maintenance of SRS and the core database. Registrants can register domain names and complete domain name information management via any registrar accredited by CONAC.

CONAC receives information about registration of domain names and name servers from registrars via SRS. CONAC uses the EPP interface to receive registration information such as domain name, contact person, life cycle and so on, from registrars, and stores the information in the primary operations center. To ensure that only eligible members of the Chinese government organization community are able to register domain names in the “.政务” TLD, CONAC will implement a verification process named Pre-registration Qualification Procedures (PQP) including pre-verification and re-verification. Registrars conduct pre-verification which requires prospective registrants to submit documentation certifying they are legitimate members of the community. CONAC will conduct re-verification via the BOSS system. Only when the registrant and the applied-for domain name have passed pre-verification and re-verification, can the domain name be valid. For a more detailed description of the PQP, please refer to section 29.2.1 of the responses to Question 29.

23.1.2 Service Level
CONAC strictly complies with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include EPP service availability≤864 min of downtime, EPP session-command Round-Trip Time (RTT)≤4000 ms for at least 90% of the commands, EPP query-command RTT≤2000 ms for at least 90% of the commands, EPP transform-command RTT≤4000 ms for at least 90% of the commands. If the EPP reaches the emergency threshold of 24-hour downtime⁄week, it will cause the emergency transition of the critical function.

23.1.3 Service Interface
CONAC SRS provides the EPP interface to facilitate the communication between CONAC and registrars.

CONAC provides accredited registrars with an EPP client Software Development Kit (SDK) and a complete guidebook, which can help registrars develop registrant-oriented registration service systems by themselves.

As a provider of domain name registration service system, CONAC can provide the registrar who does not have a registration service system with a general version of the registration service software, so as to assist registrars completing their registration management.

23.1.4 Security of the Registry Service
CONAC takes the following measures to guarantee the security of this service.
1. CONAC deploys security protection equipment and a security monitoring system to reinforce system security. For instance, CONAC deploys firewalls to enhance the security of the core database, and a monitoring system to monitor SRS performance and alert intrusions and attacks, so as to ensure continued service.

2. CONAC adopts a security strategy at the application level including limiting the number of sessions connected by TCP and the idle time, password verification for EPP sessions, implementing transport layer security (TLS) protocols, and registrar IP address verification.

3. CONAC sets up the backup operations center with the similar scale as the primary operations center. In the event that a fatal incident occurs and the primary operations center is shut down, the system can be switched to the backup operations center in a timely manner. After failure elimination, the system will be switched back.

These mechanisms will sufficiently ensure the security of operation data, and stability and continuity of the service.

23.1.5 Stability of the Registry Service
SRS and the EPP interface are developed pursuant to RFC3735, RFC5730, RFC5731, RFC5732, RFC5733, RFC5734 and RFC5910. Also, in accordance with RFC 3915, domain name grace period policy is supported in SRS and the EPP interface. SRS is an independent system, in which the application servers and database servers are deployed separately. The application servers are deployed using load balancing. With such a design, SRS does not directly affect or disturb the normal operations of other systems during the operation.

23.2 Dissemination of TLD Zone Files
23.2.1 Service Description
DNS resolution system is accountable for the dissemination of “.政务” TLD zone file. DNS resolution system implements distributed deployment by using anycast and unicast technology. Anycast sites are located in Beijing, Shanghai, Guangzhou, Chengdu, Hong Kong and USA, and cover many Internet Service Providers (ISP) including China Mobile, China Telecom, China Unicom, Hong Kong PCCW Limited, China Science and Technology Network (CSTN), and USA AT&T. All ISPs support IPv4, and CSTN and AT&T also support IPv6. Unicast site is located in the primary operations center in Beijing, and the backup unicast site is located in the backup operations center in Chengdu. Unicast sites use a different AS number from anycast sites. With the technical plan, CONAC realizes the geographic diversity deployment with multi-site distribution, and the reachability of IPv4 and IPv6. For the distribution of DNS resolution sites, please refer to Figure 1 of Q23_attachment.

There are two steps in “.政务” TLD zone file dissemination. The first step is for SRS to generate a zone file to the primary DNS server in the primary operations center. The second step is to synchronize zone file from the primary DNS server to the secondary DNS servers in each site using transmission and update notification mechanism.

To ensure the security of the service, dissemination of “.政务” TLD zone file also includes data synchronization from the primary operations center to the backup operations center. The first is quasi-real time data synchronization between the core database of the primary operations center and the core database of the backup operations center through Oracle Dataguard. The second is data update from SRS to the primary DNS server in the backup operations center.

CONAC permits the authorized third parties who comply with the Zone File Access Agreement (see section 2.1.1 of Specification 4 of Registry Agreement) to access the designated Internet host server, download zone file data, and transmit TLD zone file, associated cryptographic checksum files and a copy of the TLD zone file, no more than once per 24-hour period. The format of the zone file complies with the requirement of section 2.1 in Specification 4 attached to the Registry Agreement.

23.2.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Monthly service performance parameters include DNS service availability 0 minute downtime (100% availability), DNS name server availability≤ 432 min of downtime, TCP DNS resolution RTT≤1500 ms for at least 95% of the queries, UDP DNS resolution RTT≤500 ms for at least 95% of the queries, DNS update time ≤60 min for at least 95% of the probes. In the unlikely event that DNS service across all servers reaches the emergency threshold of 4 hours downtime per week, this will trigger the emergency transition of the critical function.

CONAC provides 7X24X365 file transfer protocol (FTP) service.

23.2.3 Service Interface
Data updates from SRS to the primary DNS server of the primary operations center and data updates from the primary DNS server to the secondary DNS servers are all in strict compliance with RFC1034, RFC2181, RFC3901, and RFC4472.

The third party access to the zone file is realized via a zone file FTP service provided by CONAC.

23.2.4 Security of the Registry Service
CONAC will take the following measures to ensure the performance, availability and attack resistance ability of the DNS resolution service.
1. Primary DNS servers in the primary⁄backup operations center are in shadow, and do not provide resolution service, for the sake of the security of the primary DNS servers.
2. DNS resolution system adopts anycast and unicast technology. CONAC deploys 8 DNS sites in the aforementioned 6 cities.
3. Management and communication between servers in the resolution sites and primary DNS server is secured through a transmission channel that supports Internet Protocol Security (IPSec) Virtual Private Network (VPN). Thus, secure encrypted transmission can be realized, and data security can be ensured.
4. Each resolution site has diverse hardware and software configurations which are monitored in real time. Real-time monitoring can detect the abnormal behavior of the software or the hardware, and inform the management team enabling prompt response and resolution.
5. As for Internet users’ access, each user is required to provide information that can sufficiently identify and locate the user. Zone file access and download are only available to users who are authorized and in compliance with Zone File Access Agreement.
6. CONAC will implement various measures for security through the use of Intrusion Detection System⁄Intrusion Prevention System (IDS⁄IPS), traffic cleansing, and real time monitoring.
7. CONAC has well defined policies and procedures for ensuring a secure registry environment. See the response to Question 30a and 30b for details.

23.2.5 Stability of the Service
CONAC’s DNS resolution system uses the most widely used DNS resolution software in the root server, namely, BIND and NSD. The DNS resolution system is an independent system using load balancing. Therefore, it will not directly affect nor interfere the normal operations of other systems.

CONAC’s DNS resolution system complies with RFC1034, RFC1035, RFC1982, RFC2181, RFC2182, RFC2671, RFC3226, RFC3596, RFC3597, RFC4343 and RFC5966. The interface that updates resolution data from SRS to the primary DNS server meets the standard of RFC2136 and RFC2137.

Zone file updates from the primary DNS server to the secondary DNS servers in the 8 resolution sites comply with RFC1996 and RFC2845. Incremental updates are adopted as the basic zone file transmission mechanism to relieve network bandwidth pressure. In the unlikely event that failure occurs to incremental updates, full updates provide a backup.

The primary operations center and the backup operations center are connected with a 10 Mb dedicated connection for incremental updates to relieve pressure on the network. In case of special occasions, the bandwidth can be temporarily upgraded from 10Mb to 100Mb according to emergency response procedures to meet the demands of system services.

23.3 Dissemination of Contact and Other Information Concerning Domain Name Registrations (WHOIS Service)
23.3.1 Service Description
WHOIS is accountable for the dissemination of contact and other information concerning domain name registrations. For the “.政务” domain name information query service, CONAC WHOIS provides the public with Port-43 WHOIS queries, web-based WHOIS queries. In consideration of the special needs of ICANN and the public, bulk WHOIS queries and searchable WHOIS queries are also offered. CONAC will also support RESTful WHOIS, once provided in the final standardized form agreed in the IETF.

Port-43 WHOIS queries and web-based WHOIS queries support exact-match query, thick model WHOIS, as well as queries for domain name data, registrar data and name-server data. Query format and response format comply with the requirements on domain name data, registrar data, and name-server data in section 1.4, 1.5, and 1.6 of Specification 4 attached to the Registry Agreement. In domain name query, the query response format complies with the format in Specification 4, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows.

Bulk WHOIS queries meet requirements in section 3 Bulk Registration Data Access to ICANN of Specification 4 attached to the Registry Agreement.

Searchable WHOIS queries support queries for domain name data. Query conditions meet searching field match requirements in section 1.8.2 and 1.8.3 and Boolean search in section 1.8.4 of the Specification 4. The response format is consistent with corresponding requirements in the Specification 4 for domain name query, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows.

CONAC WHOIS queries service provides associated security measures to prevent abusive conducts.

23.3.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. Service performance parameters on a monthly basis include Registration Data Directory Services (RDDS) availability≤ 864 min of downtime, RDDS query RTT≤2000 ms for at least 95% of the queries, and RDDS update time ≤60 min for at least 95% of the probes. In the unlikely event that WHOIS service reaches the emergency threshold of 24-hour⁄week, this will trigger the emergency transition of the critical function.

Except for Port-43 WHOIS queries and web-based WHOIS queries, bulk WHOIS queries and searchable WHOIS queries are supported by independent WHOIS servers, and thus service performance of Port-43 WHOIS queries and web-based WHOIS queries will not be affected. CONAC will provide RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.3 Service Interface
In Port-43 WHOIS queries, a registrar initiates a socket connection through the WHOIS client. WHOIS server accepts the connection and the registrar’s WHOIS queries at Port 43. When information is retrieved in the system, the result will be sent to WHOIS client. When all the query data is returned to the client, the socket connection will be automatically closed and the WHOIS query process is ended. If the query information cannot be retrieved by the WHOIS server, a result code and a human-readable description of the result code are returned before the query process is ended.

In a web-based WHOIS query, query for domain name, registrar and name server is supported. Internet users can enter WHOIS queries in the Web page for WHOIS. The query is submitted to the system in the form of tables. WHOIS will respond to the query, and display the results in HTML page.

The searchable WHOIS query can also be realized through web. Bulk WHOIS query is realized via Secure File Transfer Protocol (SFTP) services.

CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.3.4 Security of the Registry Service
This service highlights the protection of national secrets, commercial secrets and privacy. In consideration of requirements on secret and privacy protection in China as well as ICANN requirements in this regard, SRS duplicates relevant domain name data into WHOIS instances in core database and WHOIS mirror database via its WHOIS data synchronization interface function, and relevant domain name data exclude sensitive data. As there is no sensitive data in WHOIS relevant database, the leakage of sensitive information through WHOIS can be avoided.

CONAC implements the following mechanism to ensure the security of WHOIS services.
1. Security devices and monitoring system are deployed to reinforce the security capability of the system. For instance, firewalls are placed in front of WHOIS. There is also security strategy configuration to prevent malicious attacks and ensure the continuity of the service.

2. Security strategy is implemented at the application level. For instance, idle time and numbers of sessions connected by each transmission control protocol (TCP) are limited. Web-based WHOIS queries use picture based code technology for security, and Port-43 WHOIS queries limit the visiting times of one IP address in unit time to prevent the frequent and malicious visit. In addition, CONAC will implement abuse prevention policies to ensure the security of the WHOIS service. More details can be found in section 26.4 of the response to Question 26.

3. Redundant back-up and load balancing are implemented to ensure the security of WHOIS architecture. The backup operations center is set up, which is of the similar scale as the primary operations center. When a fatal failure occurs to the primary operations center, the system can be switched to the backup operations center in a timely manner. After trouble shooting and resolution of the failure, it will be switched back to the primary operations center.

23.3.5 Stability of the Registry Service
WHOIS is developed in strict compliance with RFC3912, Specification 4 and Specification 10 of the Registry Agreement. WHOIS query format and response format are in compliance with the requirements in Specification 4 of Registry Agreement. The performance of the WHOIS will be tested so as to meet the requirements in section 2 Service Level Agreement Matrix of Specification10 of Registry Agreement.

The registration service system and the EPP interface are in strict compliance with RFC3735, RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734, which ensures the stability of the system and data security.

WHOIS is an independent system deployed using load balancing, so it will not directly affect nor interfere the normal operations of other systems.

23.4 Internationalized Domain Names Service
23.4.1 Service Description
“.政务” TLD is a Chinese top level domain. Registration and resolution for simplified Chinese domain name (ASCII included) under “.政务” TLD are supported. CONAC selects “.CN Chinese IDN table” registered and released in IANA website (available at http:⁄⁄www.iana.org⁄domains⁄idn-tables⁄tables⁄cn_zh-cn_4.0.html) as the IDN table used by “.政务” TLD. After ICANN’ s delegation of “.政務” TLD(the variant of the applied for “.政务” TLD) to CONAC, on the basis of the IDN table, all variants corresponding to the registered “.政务” domain name are taken out and reserved except for the variant domain name which is provided to registrants free of charge, so that the registrant’s interests are protected. IDN services are as follows.

1. CONAC accepts registrars’ registration application for simplified Chinese domain name (ASCII included) under “.政务” TLD. CONAC uses “.CN Chinese IDN Table” which is registered and published on the IANA website and CONAC’s website, so that the expected IDN registrants easily access to the information. Since resolution to variant management has not been decided by ICANN yet, CONAC will pay close attention to the development of variant policy. CONAC believes that it is in the best interest of IDN Internet users to have the reserved variant allocated to the TLD registry for the relevant string. Initially, CONAC only accepts the domain name registration in simplified Chinese. Once ICANN finally determines the variant policy and “.政務” TLD(the variant of the applied for “.政务” TLD) is delegated to CONAC, CONAC will accept registration for simplified Chinese domain name or traditional Chinese domain name. The mixture of simplified Chinese and traditional Chinese is forbidden. CONAC will implement the registration policy that the registrant applying for a simplified Chinese domain name will be given the traditional counterpart of the domain name free of charge, provided the traditional counterpart submitted by the registrant is in accordance with Chinese IDN table and passes registrar’s and CONAC’s verification. Other forms of variants of the registered domain name, if any, will be reserved and prohibited from new registration. Likewise, the registrant applying for a traditional Chinese domain name will be given the simplified counterpart of the domain name free of charge. Simplified Chinese domain name and traditional Chinese domain name are parallelly provisioned in zone files. This policy will provide the global internet users who use simplified Chinese or traditional Chinese with service of the same quality. The data in the core database for domain name registration are stored in the Unicode format. Unicode of the registered domain name is supported by and can be directly submitted to SRS and EPP interface.

2. CONAC supports the resolution for “.政务” Chinese domain name. When DNS system generates zone file, it can directly read the Punycode strings stored in the database, and add “xn--” before the strings.

3. CONAC supports Chinese WHOIS queries for “.政务” TLD. In Port-43 WHOIS and web-based WHOIS, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query. In searchable WHOIS query, Internet users can choose to input simplified Chinese, traditional Chinese, the combination of the simplified Chinese and ASCII, the combination of the traditional Chinese and ASCII, or Punycode for registration data query, and the response formats meet Specification 4 requirements. In domain name query, the query response format complies with the format in Specification 4, except that Punycode form of the domain name will be displayed behind the domain name. In addition, after ICANN’ s delegation of “.政務” TLD (the variant of the applied for “.政务”TLD) to CONAC, the domain name will be displayed in two different rows. CONAC will provide a RESTful WHOIS service once provided in the final standardized form agreed in the IETF.

23.4.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of the Registry Agreement. Our service performance meets and is superior to ICANN’s service level requirements. The introduction of Chinese domain name will not impair the service level of DNS, RDDS and EPP.

23.4.3 Service Interface
1. SRS and EPP interface. The SRS interface is designed to accept Unicode characters.
2. DNS system. The zone file of DNS system only stores the domain names in the format of Punycode. Therefore, there is no need for change to DNS architecture to support the resolution of “.政务” domain name.
3. WHOIS system. In designing WHOIS system, support to Chinese IDN has been taken into full consideration.

23.4.4 Security of the Registry Service
To prevent malicious registration for similar domain names, spoofing and attacks, CONAC requires registrars to pre-verify the eligibility of registrants and the compliance of the domain name according to Implementing Rules for “.政务” Domain Name Registration (including registrars, registration application and verification, registration fee, domain name disputes, and user complaints) available at http:⁄⁄www.conac.cn. CONAC will re-verify the registration application submitted by registrars in accordance with the same criteria as that of the pre-verification. CONAC has also developed effective policies against variant abuse and for anti-abuse protection.

23.4.5 Stability of the Service
This service complies with RFC5890, RFC5891, RFC5892, RFC5893 and RFC5894. Thus SRS⁄EPP, DNS, WHOIS can effectively support the registration and management of “.政务” TLD. By having a policy that limits domain names to simplified Chinese or traditional Chinese and forbids the mixture of the two after ICANN’ s delegation of “.政務” TLD(the variant of the applied for “.政务” TLD) to CONAC, the equivalence of simplified Chinese and traditional Chinese is addressed. As a result of implementing the equivalence policy, the volume for registered domain names will at most double (DNSSEC impacts considered). But it does not negatively impact on the stability of the system, as the designed system storage capability exceeds the projected maximum registration volumes, system storage devices can be further extended, and the designed peak transaction processing capability is no less than 3 times the estimated volumes.

23.5 DNS Security Extensions (DNSSEC)
23.5.1 Service Description
In compliance with relevant RFCs concerning DNSSEC, CONAC has established a registry system that can support DNSSEC. EPP interface can support DNSSEC, and CONAC is capable of accepting public key materials (DS records) from registrants through registrars via EPP interface. As DNSSEC is taken into account in designing the registry system, relevant fields are reserved to support the storage of four resource records, namely, Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS) and Next Secure3 (NSEC3). Public Key Infrastructure- Certification Authority (PKI-CA) key management system, policies and procedures for key generation, exchange and storage are properly established. At the time of launching DNSSEC, CONAC can ensure that zone files of “.政务” TLD are signed, DS records from child domains are verified and accepted.

DNSSEC services for “.政务” TLD includes the following three aspects.
1. Data origin authentication. It is to verify that the data come from the right name server.
2. Assurance of data integrity. It is to verify that nothing is changed in data transmission.
3. Authenticated denial of existence. It allows a security-aware resolver to authenticate authoritative DNS error indications.

The above information is released to the public in a DNSSEC Policy Statement (DPS) in the response to Question 43.

23.5.2 Service Level
CONAC will strictly comply with section 2 Service Level Agreement Matrix of Specification 10 of Registry Agreement. After the deployment of DNSSEC, our service performance will meet and be superior to ICANN’s service level requirements. In the unlikely event that DNSSEC proper resolution reaches the emergency threshold of 4-hour downtime per week, it will cause the emergency transition of the critical function.

23.5.3 Service Interface
CONAC will provide a DNSSEC interface that will comply with ICANN requirements.
1. Generating Zone-Signing Key (ZSK), Key-Signing Key (KSK) public⁄private key pairs;
2. Generating zone files with DNSSEC records including public key;
3. Incrementally signing the authorized zone files;
4. Submitting KSK-corresponding DS record to root zone;
5. Receiving public key materials (DS records) of “.政务” sub-domain;
6. Signing DS record of the sub-domain.

23.5.4 Security of the Registry Service
DNSSEC is one of the critical measures to address the security defect of DNS system. With robust key management system, CONAC will use Public Key Infrastructure (PKI) to add a digital signature for each resource record so as to improve domain name system security.

DNSSEC establishes two kinds of keys, KSK and ZSK to realize the security of “.政务” TLD zone. KSK is used to sign the DNSKEY resource records. ZSK is used to generate signatures for all the resource records in the zone. Both ZSK’s private key and KSK’s private key are forbidden from unauthorized access, and offline storage should be ensured. A regular update system is established for key management, in which the usage period of KSK is 2 years, and the usage period of ZSK is 3 months (90 days).

23.5.5 Stability of the Registry Service
As COANC’s registry system complies with RFC4033, RFC4034, RFC4035, RFC4310, RFC4509, RFC4641, RFC5155 to support DNSSEC, origin authentication of DNS data, data integrity authentication and authenticated denial of existence will be realized. While implementing DNSSEC, SRS⁄EPP, WHOIS and DNS system need to be modified accordingly.

As a result of large volume of data request for DNSSEC signature, not only the network load of DNS will be increased, but also signature generation and authentication take up more time of CPU and I⁄O. Therefore, disk space taken by signature and key will be around 10 times as large as that before DNSSEC deployment. Accordingly, network bandwidth, server performance, and storage capability in management system need to be increased or upgraded, but as CONAC takes full account of the impact brought by DNSSEC deployment in designing the system, the impact is negligibly minor.