CITIC Group Corporation
Capital Mansion, 6 Xinyuannanlu, Chaoyang District
Mr. Jing Zhao
Senior Information Analyst
P. R. China
|Dou Jianzhong||Executive Director|
|Gao Jianhong||Equity Director|
|Liu Zhiqiang||Worker’s Director|
|Qu Yonglan||Equity Director|
|Wang Jiong||Executive Director|
|Yang Jinming||Equity Director|
|Yu Zhensheng||Equity Director|
|Dou Jianzhong||Executive Director|
|Gao Jianhong||Equity Director|
|Liu Zhiqiang||Worker’s Director|
|Qu Yonglan||Equity Director|
|Wang Jiong||Executive Director|
|Yang Jinming||Equity Director|
|Yu Zhensheng||Equity Director|
|Zhang Xiaoping||Worker’s Supervisor|
|Zheng Yongqin||Worker’s Supervisor|
|Ministry of Finance of the Peopleʹs Republic of China||Not Applicable|
The applied-for gTLD string in this application is in ASCII format . It fully complies with the technical requirements specified in section 126.96.36.199.2 of ICANNʹs gTLD Application Guidebook. The ASCII label of this string consists entirely of letters (alphabetic characters a-z). It adopts the same character set as TLDs such as .net, .com, etc. And it can work well with many existing operating systems such as windows, linux, and is supported by common Internet Browsers, such as Firefox, Internet Explorer, Safari, Netscape. After being tested by the test system, there is no operational or rendering problems concerning the applied-for gTLD string .
Approved by the State Council, CITIC Group has transformed into a wholly state-owned company through comprehensive restructuring and changed its name to CITIC Group Corporation (“CITIC Group”), with RMB 183.70263 billion as the registered capital and Mr. Chang Zhenming as the legal representative.
CITIC Group was established in 1979 by Comrade Rong Yiren with the initiation and support by Comrade Deng Xiaoping. Since its inception, CITIC Group Corporation has given full play to the role of a pilot of national economic reform and an important window on China’s opening to the outside world and made explorations and innovation in many business fields with remarkable success. It has blazed a new trail of development for China’s “Reform and Opening-up” as well as the “Modernization Drive” by attracting and utilizing foreign capital, introducing advanced technologies, and adopting advanced and scientific international practice in operation and management thus building up good reputation and image both home and abroad with a remarkable performance.
Up to now, CITIC Group has developed into a large state-owned multinational conglomerate with a balanced development of both financial and non-financial businesses. Its financial business covers a full range of services including commercial banking, investment banking, trust, insurance, fund management and asset management and its non-financial business includes real estate, engineering contracting, energy and resources, infrastructure construction, machinery manufacturing and IT industry with clear overall strength and great momentum of development.
At the end of 2010, CITIC Group’s total assets stood at RMB 2539.1 billion, net assets RMB 172.5 billion, operating income RMB 263.9 billion and net profit RMB 33.4 billion. CITIC Group was enlisted in the Fortune Global 500 for the third consecutive year in 2011, ranking the 221st.
On the financial services side, CITIC Group drove business collaboration among its financial affiliates and upgraded its shared information platform. Fully capitalizing on this synergy, the affiliates registered new progress in co-underwriting, cross product design and client information sharing, and the Group further secured its position as an integrated financial service provider. As of the end of 2010, total assets of CITIC Group’s financial services stood at RMB 2.0958 trillion (US$329 Billion), an increase of 16% year on year (yoy), and total profit RMB 34.5 billion (US$5.43 Billion).
With regards to the non-financial business side, total assets of CITIC Group’s non-financial business stood at RMB 410.2 billion (US$64.6 Billion), an increase of 23.9% yoy, operating income in 2010 RMB 191.7 billion (US$30.19 Billion), up 38.8% yoy, and total profit RMB 19.2 billion (US$3.02 Billion), up 62.1% yoy.
Globally, the headcount for CITIC Group, as of the end of 2010, stood at 140,028. Moving forward, CITIC Group will carry out the development agenda for the next five-year period, embracing a client-centered business philosophy, and promoting overarching restructuring. New models of management and control will be explored, and key investments and projects conducted. More efforts shall be made in business and investment management as well as risk control. Tapping into its comprehensive advantage and synergy, the Group is expected to breakthrough in scientific development, and will continue to strive to be a world-renowned conglomerate that enjoys prominent overall strength, excellence in various sectors and market competitiveness.
CITIC Group is applying for “.citic” Top Level Domain (“applied-for TLD”) which is the commonly known shortened English name for CITIC Group.
The vision for the applied for gTLD “.citic” is to become the online brand for this Global Fortune 500 conglomerates. Through this gTLD, CITIC Group will be able to protect its brand and deliver the right impression and message to the end users, thus becoming the brand protection and brand building mechanism that the conglomerate deserves to have in this modern age of the internet. Furthermore, “.citic” will have a multiplier effect on CITIC Group’s efforts to expand and promote its range of businesses globally.
Currently, CITIC Group has over 30 million clients worldwide, which would drive traffic and recognition of the “.citic” domain when it is launched globally. This would also help accelerate the acceptance of “.citic” domain, and create a new market for these users that would like to have their own “.citic” domain name if and when CITIC Group decides to open it up to them. By offering customized “.citic” personal domain names and services like homepages, email accounts and applications, its multitude of clients, internal employees and business partners, CITIC Group can increase and improve these relevant parties’ trust and relationship with itself. This creates a virtuous cycle whereby CITIC Group can observe that its brand equity will increase through the usage of “.citic” domain names. By the third year, CITIC Group expects “.citic” to have about 10,000 domain names at a wholesale price of RMB 388 (US$61.10) per domain per year.
By consolidating all the domain names associated with CITIC Group and its subsidiaries, “.citic” will unify all of the conglomerate’s online related businesses, reposition them and create a solid foundation for the future. By doing so, CITIC Group can further increase the scope and range of its online related businesses while consolidating its position in the market. To fulfill this purpose and mission, CITIC Group will invest heavily on upgrading and improving the security and intelligence of its information technology backbone and architecture.
For the first time since the invention of the Internet, a company will have full ownership of a top level domain “brand” name. It is with this in mind that “.citic” term is first conceived. More importantly, with such leverage, CITIC Group, through “.citic”, can help to promote healthy competition from the registrars by dictating the level of service and quality expected that is consistent with the stature of such a Global Fortune 500 company.
Furthermore, this will increase the level of trust from the users as problems like phishing, domain redirection and domain parking will be eliminated. Users know that they can depend on such gTLDs that are the brand personification of the actual entity. At the same time, it is so much easier for users to remember instantly and search for such famous companies. The introduction of “.citic” in its IDN form will also greatly benefit the local users (500 million internet users alone in China) by providing better user experience and more choices for access.
Through the presence and increased access and usage of “.citic”, the online persona and brand of CITIC Group, “.citic” gTLD will benefit ICANN in successfully showcasing how a Global Fortune 500 company can effectively manage, protect and expand its online presence using a gTLD.
18 (b) How do you expect that your proposed gTLD will benefit registrants, Internet users, and others? What is the goal of your proposed TLD in terms of areas of specialty, service levels, or reputation?
As mentioned in Question 18(a), “.citic” is directly associated with CITIC Group. “.citic” is intended to be the online brand of CITIC Group, and is tasked with the responsibility of building and promoting the online brand. The registrants, internet users and others will understand that any domain under “.citic” is managed and supervised by CITIC Group.
Hence, internet users will be able to fully trust “. citic” domain names since they will know that they are being served by the CITIC Group.
On the service level, CITIC Group strives to provide high level service to its registrants and users. To this end, CITIC Group has partnered with KNET, the leading Registry Service provider in China to meet or even exceed the SLA standard of the performance per the Registry Agreement.
The KNET Shared Registry Platform (KSRP) is designed, implemented and operated to provide high availability, secure, robust and scalable registry services. Please refer to the answer on Question 23 for the details on the service level provided by CITIC Group.
Secure and trusted services shall come to be associated with “.citic” domain names as “.citic” is the official online brand of the global fortune 500 company, CITIC Group.
What do you anticipate your proposed TLD will add to the current space, in terms of competition, differentiation, or innovation?
Currently, CITIC Group has found it difficult to manage its domain name portfolio and maintain a consistent and secure brand image which unfortunately is currently scattered across several different TLDs. With the introduction and utilization of “.citic”, CITIC Group will be able to provide a consistent brand image and innovate on services for its customers, internet users and corporate internal users.
Firstly, CITIC Group shall make “.citic” a secure space dedicated for CITIC Group and its customers and partners.
In addition to that, through “.citic”, CITIC Group envisions providing innovative service to its customers based on its own offline products and services in close collaboration with different sectors and branches of CITIC Group.
For example, “.citic” may serve as a focal point for the online communications, internal communication and information sharing within the entire CITIC Group,. Cross sector or cross border collaboration or online training could rely on the “.citic” domain space to be carried out in a secure and stable manner.
Of course, the addition of “.citic” in the root will contribute to the competition on the domain name industry, offering more choices and services to CITIC Group and its customers, and better yet, offering a competitive environment for other TLDs to enhance their security and stability of their respective zones. This indirectly encourages the existing gTLDs to provide more innovative or better services at a lower price.
“.citic” will inspire trust and confidence in the consumers as they know that they are dealing with CITIC Group or⁄and its subsidiaries when they interact with “.citic” domain names.
The registrants of the “.citic” domain names can be confident that the registered domain names are managed and controlled by the CITIC Group with the highest security and availability. Cybersquatting, email fraud, phishing, spoof and other domain name abuses will not occur or will be greatly reduced when using “.citic” TLD.
To the internet users, “.citic” domain names bear the brand of CITIC Group and can be naturally affiliated with its products or services or employees of CITIC Group. Internet users hence will inherently trust the website that is offering CITIC products or services.
All in all, registrants, internet users and the general public shall regard “.citic” as the official online presence of CITIC Group, and the service on this space is an official offering by the CITIC Group. This TLD is trusted and secure managed by CITIC Group.
Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.
CITIC Group will place stringent registration policy for “. citic” domain names. All applications for domain names under “. citic” must have a supporting letter executed by the CITIC Group’s legal department prior to any registration. In the supporting letter, it will clearly indicate
• the domain name under “. citic” for which it is been approved
• the purpose of the domain name
• the registrant, administrative and technical contact for the domain name
CITIC Group will reject any domain name registration without the supporting letter. Registrars will all be instructed of the additional requirements.
Domain names can contain the English-language letters A through Z, the digits 0 through 9 and hyphens (LDH -- Letters, Digits, Hyphens).
a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 -
Hyphens however cannot be used for the first or last character of the second level domain name. Spaces and special characters (such as !, $, &, é, and so on) are not acceptable. The maximum number of LDH characters accepted for a second level domain is 63.
CITIC Group shall operate as a ʺthickʺ registry, in which all of the information associated with registered entities, including both technical information and social information is stored within a central registry repository.
CITIC Group shall deploy ante-audit mechanism. The domain name will not be registered unless all registration materials as well as the real ID and contact information of the registrants or their purveyors to be verified by the Audit team of the accredited registrars.
CITIC Group also commits itself to maintain timely, unrestricted and public access to accurate and complete WHOIS information, including registrant, technical, billing, and administrative contact information. Details of the WHOIS policy can be found in answer to Question 26.
• UDRP and URS as described in the answer to Question 29
• Sunrise process as describe in the answer to Question 29
• Geographic name restriction as described in answer to Question 22
• Trademark protection as describe in answer to Question 29
• Domain Name Lifecycle as describe in answer to Question 27
• Data Privacy as describe in Question 18(c) below
• Reserved list as describe in the answer to Question 29
Will your proposed TLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.
CITIC Group would adopt stringent policies to protect the privacy of registrants and its domain name users as per the ICANN WHOIS policy and China data protection regulation.
Specifically, CITIC Group is subjected to China’s Information Security Technology -- Guide of Personal Information Protection. In brief, the CITIC Group shall inform the registrants
i) The purpose of any personal information collected and scope of use
ii) The period in which these personal information will be stored
iii) The security measure and information protection policy to safeguard the personal information
iv) The rights of the registrants on the personal information
v) The registrant responsibility for accuracy of the personal information
In general, the Applicant stipulates how the personal information will be collected and used and how the WHOIS information will be displayed. Any information other than the WHOIS shall not be collected and used. No personal information will be collected without the consent of the registrants and the registrants shall have the Rights to Confidential, Rights to Knowledge, and Rights to Opt Out⁄Change Data⁄Prohibit Use.
The information submitted by the registrants shall be regarded as classified information and shall be processed by specially designated personnel. Without the written consent of registrants, the information collected cannot be used in the way other than WHOIS purpose.
The back-end registry service provider shall deploy security measures to protect the integrity of the database against potential stealth or unintended leakage. Please refer to answer to Question 30 for more information in this regard.
Describe whether and in what ways outreach and communication will help to achieve your projected benefits.
CITIC Group envisions the “.citic” TLD to be an integral part of its overall brand resource. The projected benefits such as consumer trust, recognition of “.citic” online and competition will be achieved through a series of promotion and marketing activities.
At the application stage, outreaches will be given to the subset of CITIC Group to raise the awareness of the online presence of “.citic” within the entire group. It will give the various sectors of the group a precious opportunity to promote their products and services or even more innovative application of the “.citic” through this dedicated cyberspace. Internal trainings shall be held in various sectors and branches to achieve the outreach purpose.
After that, outreach and promotion will go to the customers of CITIC Group. As the targeted users of the “.citic” domain names, the customers shall benefit enormously through the secure and trusted online experience on the “.citic” domain. Brochure and flyer illustrating the “.citic” domain names and its services will be presented at each and every CITIC Group outlet.
After the delegation of the applied-for string, offline and online advertisement will be used to attract their attention. Branding campaigns will also be conducted to promote the “.citic” TLD to convey the impression that “.citic” is the online presence of CITIC Group and any online services provided by using the “.citic” domain names” is reliable and trustworthy.
18 (c) What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences⁄costs imposed upon consumers?
The application and use of “.citic” TLD is meant to improve consumer trust and to minimize consumer costs. CITIC Group has developed and adopted several operating rules to this end.
CITIC Group will also adopt rights protection mechanisms to protect trademarks and geographic names. More information in this regard can be seen in the answer to Question 29.
CITIC Group will also adopt anti-abuse policy as described in the answer to Question 28 to prevent and mitigate any potential domain name abuse.
Answers should address the following points:
How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?
Specifically, with regards to multiple applications for a particular name, they would be addressed in the following manner, depending on who the applicants are:
i) During the pre-launch period, CITIC Group will implement a Sunrise service for trademark holders with supporting letter from the CITIC Group’s legal department. If there are multiple eligible applications, CITIC Group will resolve this using the internal dispute resolution mechanism (please refer to answer to Question 29 for details):
CITIC Group will setup a panel to facilitate the negotiations. This panel shall conduct internal negotiation by hearing both parties on the rights claims. The Panel then would come to a conclusion regarding the rights of the domain name registrant within 5 working days
ii) During open registration period, CITIC Group will abide by the first-come-first -served policy to registration applications.
Explain any cost benefits for registrants you need to implement (e.g. advantageous pricing, introductory discounts, bulk registration discounts).
The running of “.citic” is based on a cost-recovery basis. As such, there is no intention to provide any promotion or bulk registration discount.
Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.
As “.citic” TLD is not geared toward for profit, the magnitude of price increase per year will not be higher than 10% to offset the increase of operation cost. CITIC Group shall inform of the price adjustment to its registrars at least 6 months in advance.
CITIC Group will offer optional multi year registrations for up to ten years. Any registrants who make advance payment for multi year registrations will not be affected by any price adjustment during the period they had made advance payment for.
22． Describe proposed measures for protection of geographic names at the second level and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and⁄or release of such names.
To minimize any potential abuse of geographic names and to mitigate confusion and dispute, .citic Registry Operator would reserve the geographic names, and the reserved lists can be revised from time to time at the discretion of the Registry Operator. The reserved words and categories should be published on the website of .citic Registry Operator. In the event of release of such names, certain procedures will be observed to ensure the proper use of the geographic names.
22.1 The reservation list
22.1.1 Reserved list as per AGB
As per the Specification 5 of the Registry Agreement, .citic Registry Operator shall put the following geographic names on reservation. The reserved geographic names are:
Country and Territory Names. The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:
i. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU〉;
ii. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
iii. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
Regional or Continental Names. The names are listed as a UNESCO region on the UNESCO website (see http:⁄⁄www.unesco.org⁄new⁄en⁄unesco⁄worldwide⁄) or appearing on the “composition of macro geographical (continental) regions, geographical sub-regions, and selected economic and other groupings” (see http:⁄⁄unstats.un.org⁄unsd⁄methods⁄m49⁄m49regin.htm).
22.1.2 Reserved list of subdivisional names of the countries and territories
In addition to the Country and Territory Names reservation, .citic Registry Operator will also reserve the names of subdivisions of the countries and territories as listed on ISO 3166-2⁄3. Also, the national geographic names of China in which the registry registered will also be put to reserve list. The names lists include:
i. the short form (both in English and in Chinese) of subdivisional names of all country and territory names contained on the ISO 3166-2 list, as updated from time to time; the short form (both in English and in Chinese) of the country and territory names contained on the ISO 3166-3.
ii. The names (both in English and in Chinese) of the provinces and municipalities of China, including complete form and short form as well as unofficial abbreviation of the geographic names.
iii. The names (both in English and in Chinese) of the sub-regions of the provinces and the names of the cities and counties in China.
22.2. Procedures to release the Geographic Names
Normally, .citic TLD will not allow for the release of geographic names. However, the reserved geographic names may be released to the extent that .citic Registry Operator reaches agreement with the applicable government(s). The release of the geographic names shall follow the below described procedures.
22.2.1 The release of country and territory names
A) The Government or public authority concerned informs the GAC Secretariat of their request to register the name, and the designated beneficiary.
B) The GAC Secretariat authenticates the request and transfers it to the ICANN staff and to .citic Registry Operator.
C) .citic Registry Operator verifies the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary in the country concerned.
D) The designated beneficiary (the Registrant) registers the name, with an accredited .citic Registrar, using the authorization letter as their authority.
22.2.2 The release of national geographic names
The reserved national geographic names could be released on the condition that the applicable government(s) support the acceptable use of the domain names and reaches agreement with .citic Registry Operator. Under this circumstance, .citic Registry Operator would apply the following mechanism:
A) The government concerned informs the Registry of their request to register the name, and the designated beneficiary.
B) .citic Registry Operator checks the availability of the name and issues an authorization letter that is transmitted directly to the designated beneficiary
C) The designated beneficiary (the Registrant) registers the name, with an accredited .citic Registrar, using the authorization letter as their authority.
23. Registry Services
23.1. Registry Services
CITIC Group Corporation is the Registry Operator of the TLD ʺ.citicʺ (hereinafter referred to as ʺ.citicʺ Registry) that provides the services as specified in Specification 6, section 2.1 (a) and (b) in ICANNʹs Applicant Guidebook as well as those as specified in Appendix A. In particular, the ʺ.citicʺ Registry prohibit the use of wildcard per requirements specified in Specification 6, section 2.2.
The ʺ.citicʺ Registry provides other necessary services in accordance with the Consensus Policy of Specification 1.
The services provided by the ʺ.citicʺ Registry 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.
CITIC Group Corporation will outsource the technical operation to KNET (“Back-End Service Provider”) while the remaining operation will be handled by CITIC Group Corporation (“Business Operation Provider”).The KNET Shared Registry Platform (“KSRP”) is designed and implemented to provide robust and highly available registry services.
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 in Q23_attachment for the summary table of the services level agreement. For detailed information, please refer to corresponding sections.
KRSP conforms to the ISO27000 standard in its design, implementation and operations. KSRP institutes the following security measures:
a) A set of operations 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.
The ʺ.citicʺ Registry 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 an 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 ʺ.citicʺ Registry 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 ʺ.citicʺ Registry receives the data from Registrars concerning registrations of domain names and name servers.
The ʺ.citicʺ Registry provides the SRS service. Registrars collect the data from end users relating to registration contacts, domain names and name servers and submit them to the ʺ.citicʺ Registry via the SRS system; the ʺ.citicʺ Registry also provides add-on auxiliary services for Registrars to submit other business-related data as required by ʺ.citicʺ Registry;
23.2.1. Service Level
The service level of the SRS provided by the ʺ.citicʺ 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.
Only ICANN accredited Registrars are considered to be candidate Registrars for the ʺ.citicʺ Registry.
To connect to the SRS platform of the ʺ.citicʺ Registry, a Registrar must provide a set of fixed static IP addresses to the ʺ.citicʺ Registry 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.
The SRS service provided by the ʺ.citicʺ Registry fully 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 ʺ.citicʺ Registry 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 ʺ.citicʺ Registry will build its official website（www.nic.citic）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 ʺ.citicʺ Registry 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, ʺ.citicʺ Registry 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.
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.
188.8.131.52. 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.
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
KNET is in charge of the operation of the zone servers as part of the KSRP. KNET 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 ʺ.citicʺ Registry.
In addition to those described in 23.1.2, there are also the following security measures for zone server operations.
KNET 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;
KNET 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, KNET is developing 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.
In addition to those described in 23.1.3, the following stability measures apply to DNS zone servers.
a) KNET 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) KNET 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) KNET 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 ʺ.citicʺ Registry 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 ʺ.citicʺ Registry 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 ʺ.citicʺ Registry provides two types of Whois query service: general queries and searchable queries.
The ʺ.citicʺ Registry provides ICANN and other authorized third parties access to the ʺ.citicʺ zone files.
The ʺ.citicʺ Registry provides ICANN with bulk registration data through the interfaces specified by ICANN.
23.7.1. Service Level
The service level provided by ʺ.citicʺ Registry meets Specification 10 specified in the Applicant Guidebook. Please refer to the answer to Q26 Whois System (26.2.2) for details.
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.
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.
KSRP is designed to fully support DNSSEC. The ʺ.citicʺ Registry 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.
ʺ.citicʺ Registry deems DNSSEC as critical for its registry services. KNET plans to actively drive adoption of DNSSEC in KSRP in 3 stages:
a) Stage 1: Test-Bed. At this stage, KNET 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.
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.
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 ʺ.citicʺ Registry, KNET 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.
24. Shared Registration System（SRS）
ʺ.citicʺ Registry provides Registrars with a registration interface for the domain ʺ.citicʺ through KSRP provided by KNET. The SRS provided by KSRP complies with the requirements of ICANN and IANA as well as relevant RFCs and other technical standards. It is designed and implemented to provide highly available, secure, scalable and high performance services.
24.1.1. System Architecture
The SRS consists of the domain registration system (EPP server) and other subsystems for domain name registration. Please refer to Figure 24-1 in Q24_attachment for the system architecture of SRS. Below is the detailed description.
a) EPP Server
The EPP server provides Registrars with domain registry services such as the creation, modification, deletion and other key functions of domain, contact and host objects. It also provides support for the redemption grace period and DNSSEC as specified in relevant RFCs.
b) Registrar Business Support System
The registrar business support system provides supporting functions to Registrars concerning domain registration. Upon successful authentication, a Registrar may perform a real-time check of account balance, monthly bill report, and domain operation records. It may also check its payment and usage details within a year. The Registrar can also use the system to report any problem to online customer support staff for solutions. In addition, Registrars may retrieve specifications, FAQs and other technical documents concerning ʺ.citicʺ TLD domain name registration in the knowledge base.
Registrars may also access the business support system via FTP to download historical data such as domain operation records and billing reports upon successful authentication.
c) Registry Business Support System
Please refer to Figure 24-2 in Q24_attachment for the system architecture of the Registrar business support system.
The Registry business support system provides business staff of ʺ.citicʺ Registry with the support services concerning domain registration, including auditing of newly registered domains, recharging of registrarsʹ accounts, and locking⁄unlocking of domains.
The registry business support system will regularly compile the registered domain data and zone file into a data file with specified type and formatting of content as described in ICANNʹs Registry Agreement, and uploads the data file on specified SFTP for ICANN and its designee to access and download.
In addition, the registry business support system will regularly generate a data file with specified type and formatting of content as described in ICANNʹs Escrow Agreement, and uploads the data on specified SFTP of the escrow service provider NCC Group for its service provision.
d) Zone File Synchronization Service
The zone file synchronization service is responsible for synchronizing changes made to the SRS database to the master DNS nodes, and through which all global DNS nodes are subsequently updated.
The SRS database is the master database that stores information about domains, contacts and hosts submitted by the EPP server. It is replicated to the Whois database using the Oracle Advanced Replication. The Registrar & Registry (hereafter referred to as R&R) business support database stores the data relating to the support business, such as billing reports, and historical auditing records, etc..
24.1.2. Physical Architecture
Please refer to Figure 24-3 in Q24_attachment for physical architecture of SRS.
The SRS system and the R&R business support system are deployed in multiple servers that are clustered and load balanced via F5s; both the SRS master database and R&R business support database achieve high availability via Oracle Veritas. A disk array is deployed at the back-end for data storage redundancy and for high throughput database access.
24.1.3. Equipment List
Please refer to Table 24-1 in Q24_attachment for a list of equipment of the SRS (excluding any hardware shown in the topological diagram of the primary data center, such as routers or firewall).
24.2. Operations Plan
The SRS of the KSRP is able to provide 99.9% availability, ensuring the monthly down time not exceeding 43.2 minutes, therefore fully meet the 98% availability requirement specified in ICANNʹs Specification 10. In addition, the SRS is also redundantly deployed at the backup data center. If the primary data center goes off-line, registry services are switched over to the backup data center within 30 minutes to ensure high availability of the services.
Specifically, SRS ensures high availability in the following aspects:
a) The SRS software has been built via rigorous engineering disciplines such as code review, unit testing and daily builds. Any SRS build must pass the thorough integration testing, system testing and acceptance testing prior to deployment in production.
b) Both the hardware and software systems are redundantly deployed. Load balancers (F5) are deployed to distribute requests to server clusters to mitigate unplanned server hardware and software failures. For example, the EPP server is deployed on multiple servers as a cluster behind the load balancer so that even if one of the servers goes down, F5 will automatically distribute the requests to the rest of functioning servers, to ensure the registry services continuity.
c) The database of the SRS achieves high availability via Oracle Veritas to prevent any unplanned outages of the database backend.
The ʺ.citicʺ Registry plans to delegate 10,000 domain names within 3 years. When the registration volume reaches such target point, the ʺ.citicʺ Registry needs to handle about 30,060 transactions per day. The KSRP is designed to scale up to 30 million domains, and the performance test result shows that it is able to handle 3000 transactions per second. Hence KSRP is able not only to meet the current needs of ʺ.citicʺ Registry, but also to scale for future demand of ʺ.citicʺ Registry as the business grows.
Comparison with SLR Indicators
Please refer to the Table 24-2 in Q24_attachment for the contrast between the test results of the SRS and the SLR indicators specified in Specification 10.
SRS is developed and deployed using distributed technology that is able to scale both vertically and horizontally as follows:
a) Support vertical scalability by upgrading the hardware of online servers;
b) Support horizontal scalability by deploying server hardware and software systems in a cluster;
c) When the system load reaches the maximum capacity of the SRS system, it can be upgraded by adding more servers and bandwidth to meet the performance and throughput capacity needs
In order to ensure the security of the SRS, the KSRP has taken the following measures:
a) SSL⁄TLS protocol is used for connection between the SRS and the clients. When connecting the SRS, a Registrar is required to be authenticated with SRS using its user name, password, IP address and the digital certificate authorized by the KSRP; if the Registrar fails the ID authentication 3 times, it has to wait for 30 minutes before another attempt;
b) SRS has put a strict restriction on the number of connections created by Registrars as well as the idle time in TCP;
c) SRS is deployed in the DMZ in order to prevent unauthorized network access to the backend database.
24.2.5. Data Synchronization
Data synchronization between the master database of SRS and the Whois database is realized via Oracle Advanced Replication at an interval of 5 minutes.
Data synchronization between the primary and the backup data center is realized via Oracle Dataguard in almost real-time.
24.2.6. Operations and Maintenance
The following operations and maintenance measures have been established to guarantee the quality of services.
a) SRS is being monitored and protected on a 7×24 basis. With the monitoring system, KSRP keeps track of the performance of the whole system so that it can take timely measures to address any emergency;
b) The ʺ.citicʺ Registry and KSRP have established a thorough emergency response mechanism to effectively handle emergency situations. The mechanism provides handling and upgrading procedures for different types of failures based on pre-classified severity levels.
SRS fully complies with EPP and supports RFCs mentioned in Specification 6, including RFCs 5730～5734, RFC 3735 and RFC 3915.
KSRP supports IDN based on IETF RFC 3454 and RFCs 5890～5892. When the user registers a domain name under ʺ.citicʺ, SRS will store the domain data and its corresponding Punycode into the SRS database.
Regarding support for DNSSEC, KSRP has designed its interfaces according to RFC 5910. A plan is in place for smooth transition to DNSSEC in KSRP once DNSSEC-related tests are completed on the platform.
KNET has dedicated R&D personnel who closely follow the DNSSEC work in IETF and the industry, so that the platform can be timely upgraded to meet the requirements of ICANN in case there are changes in the future.
24.4. Resourcing Plan
The development and test work for SRS has been completed. Please refer to section 31.12.2 for the overall human resource planning of KSRP. Please refer to Table 24-3 in Q24_attachment for the resourcing plan of SRS system and the above 24.1.3 for equipment resource planning.
25. EPP (Extensible Provisioning Protocol)
ʺ.citicʺ Registry provides services to the public through KSRP provided by KNET. KSRP provides Registrars with a registry service interface for the domain name ʺ.citicʺ over EPP 1.0. KNET has years of experiences in implementation and maintenance of the EPP1.0 interface for the .cn Registry.
25.2. Introduction to EPP
EPP is an xml-based text protocol. It is widely used as a standard protocol for domain name registration between Registry and Registrar.
The EPP protocol suite consists of RFCs 5730～5734, RFC 3735, RFC 3915 and other relevant RFCs. The core of EPP is specified in RFC 5730, which defined the EPP commands, request-response mechanism, message format, result code and other basic protocol elements. RFCs 5731～5733 define the mapping of domain name, contact and host objects on EPP respectively. RFC 5734 explains how to safely implement EPP over TCP. RFC 3735 provides guidelines on how to extend EPP. RFC 3915 extends EPP to handle different redemption grace periods in registration life cycle. RFC 5910 describes how to support DNSSEC based on EPP. The aforementioned RFCs cover all functions, procedures and expansion mechanisms required by domain registry services.
EPP provides four basic service elements: service discovery, commands, response and an extension framework.
The EPP commands are divided into session management commands, query commands and object transform commands. The first category is used to establish and close connections between a client and the server; the second category is used to query information such as domain name, contact and host from server; the last category is used to manage the domain name, contact and host objects.
The responses to EPP commands must include a result code and a detailed description of the code. The result code is a 4-digit number. The first digit represents success or failure of command execution (1 for success, 2 for failure); the second digit represents the classification of responses (6 categories in total); the last 2 digits represent the explicit description of the result code in each category of response. For example, an result code for an EPP command is 1000, where 1 stands for success of command execution, the second digit 0 implies this EPP command is ʺProtocol Syntaxʺ (one category of responses), and the final two digits imply the description of the result code is ʺCommand completed successfullyʺ.
KSRP implements EPP based on TCP (refer to RFC 5734). The server listens on port 700. The client issues EPP commands to the server after both sides have passed the two-way certificate authentication and have successfully completed the execution of the Login command. The EPP server executes the received commands in order. Upon completion of processing an EPP command, the server packages the results into an EPP response to be returned to the client. Both sides repeat the request-response cycle until either the client requests the server to close the connection (via the Logout command) or the execution of a command requires that the server terminate the connection after the command execution (according to RFC 5730, the result codes 2500~ 2502 demand that the server proactively close the connection).
25.3. APIs Provided for Registrars via EPP
KSRP implements registration APIs for Registrars based on EPP1.0. These APIs cover all functions required by domain registry services, including opening and closing of connections, and processing of commands such as query, creation, modification, transfer and deletion of domain, contact and host objects.
a) Session Management
APIs provide Login command and Logout command to Registrars. By using these commands, Registrars can interact with KSRP, such as executing ID authentication (via Login command) or closing connections (via Logout command).
A Registrar sends the Login command to request ID authentication and session establishment with the EPP server. Upon successful authentication and session establishment with the EPP server, Registrars begin to send other EPP commands. Each of the subsequent commands from shall contain the authentication token and the Registrarʹs password. When the Registrar completes the session, it may send a Logout command to the EPP server to close the connection.
APIs provide the query commands such as Check command, Info command and Transfer command to Registrars. Registrars may use these APIs to query information or status about domains, contacts and host objects. (Please refer to Table 25-1 in Q25_attachment)
The Check command is used by Registrars to check the existence of the queried data objects (domain names, contacts or hosts).
The Info command is used by Registrars to retrieve the detailed information about domain names, contacts or hosts that exist in the Registry.
The Transfer command is used by Registrars to check the current transfer status of domain names and contacts.
In addition to the above-mentioned commands, Registrars may also use the Poll command to query and retrieve the asynchronously queued service messages from the EPP server.
c) Object Change
APIs provide several object change commands to Registrars. Through these commands, Registrars may create, modify, delete and perform other operations on domain names, contacts or hosts. (Please refer to Table 25-2 in Q25_attachment)
The Create, Update and Delete commands are used by Registrars to perform basic management functions on domain names, contacts and hosts.
The Renew command is used by Registrars to renew a domain name.
The Transfer command is used by Registrars to transfer domain names or contacts.
The Restore command is closely related to the redemption grace period. When a domain name is deleted, its EPP status is ʺpendingDeleteʺ and the RGP status is ʺredemptionPeriodʺ. Registrars are allowed to restore the deleted domain names to the normal state via the Restore command (Restore is not an EPP command in fact; it is implemented by the extended Update command).
KSRP ensures that all the APIs comply with RFC 3915 and RFC 5910 to support not only redemption grace period operation such as registry grace period and renew grace period but also DNSSEC.
During the add, renew, or transfer grace period, if a Registrars deletes a domain name, the cost incurred will be refunded to the Registrar by the Registry.
If a domain name expires, the Registry will determine whether to auto-renew a Registrarʹs account and enter the auto-renew grace period based on its account balance. If the Registrar deletes the domain name during the period, the renewal fee incurred will be refunded by the Registry.
Regarding the support for DNSSEC, Registrars may submit the information of Delegation Signer to the Registry over EPP and perform modification and deletion operations.
The interfaces of KSRP for Registrars comply with EPP1.0 as defined by IETF RFCs and support DNSSEC and redemption period functions.
25.4.1. Compliance with RFCs
The interfaces for Registrars mainly follow the RFCs 5730～5734 and RFC 3915. If the standard EPP canʹt meet certain specific business requirements, extensions will be made to KSRP based on RFC 3735.
a) Compliance with RFC 5730
RFC 5730 is an overall description of the EPP, mainly defining the EPP message format, result code and date format. KSRP strictly follows the RFC as the basis for its EPP implementation.
b) Compliance with RFC 5731
KSRP complies with RFC 5731 in implementing the domain-related command, such as Create, Modify, Delete, Check, Transfer and Info.
c) Compliance with RFC 5732
KSRP complies with RFC 5732 in implementing the host-related commands, such as Create, Update, Delete, Check, and Info.
d) Compliance with RFC 5733
KSRP complies with RFC 5733 in implementing the contact-related commands, such as Create, Update, Delete, Check, and Info.
e) Compliance with RFC 5734
KSRP complies with RFC 5734 in implementing TCP-based EPP and performs certificate-based authentication via TLS to ensure the data security.
f) Compliance with RFC 5735
KSRP has not yet used RFC 5735 to extend EPP protocol. However, if the ʺ.citicʺ Registry business requires functional expansion to be made to the standard EPP, KSRP will strictly follow the RFC 5735 and the requirements specified in the agreement and specifications in ICANNʹs Registry Agreement.
25.4.2. Specification Related to Redemption Period (RFC 3915)
KSRP complies with the RFC 3915 in implementing the registration life cycle policy, including add grace period, renew grace period, transfer grace period and auto-renew grace period, as well as the corresponding statuses.
25.4.3. Specification Related to DNSSEC (RFC 5910)
KSRP complies with RFC 5910 and RFCs 4033～4035 in implementing support for DNSSEC and enabling Registrars to submit their DS record to the Registry and to perform the modification and deletion operations.
25.5.1. Consistency with Technical Plan
The SRS of KSRP fully implements EPP1.0, covering all functionalities required by the domain name registry services. Moreover, it provides Registrars with the fully tested EPP client and detailed documentation of its APIs.
25.6. Resourcing Plan
The development and test work for the SRS has been completed. In addition, the OT&E (Operational Testing and Evaluation) environment is also made available at ote.tld.knet.cn via port 3121. Please refer to Table 25-3 in Q25_attachment for the resourcing plan.
26. Whois System
The ʺ.citicʺ Registry provides Whois services to the public through KSRP by KNET. The Whois system of KSRP is implemented in accordance with RFC 3912 and other requirements specified in Specification 4 of the Registry Agreement. It meets the SLR indicators specified in Specification 10 in terms of performance and availability, and provides scalability for growth.
26.1.1. Software Architecture
For the diagram of software architecture of Whois, please refer to Figure 26-1 in Q26_attachment. Below is the detailed description.
The Whois system consists of the Whois server and the Whois web server, which can be accessed from either command-line or web. The command line query requests directly access the Whois server while the web-based query requests access the web page on the Whois web server.
a) Full-text Search System
The full-text search system provides the searchable Whois functions via the Apache Solr. It scans the Whois database every 10 minutes. If there are any data changes, the search system will update the search indices accordingly.
The SRS master database synchronizes only the data fields required by the Whois system to the Whois database via Oracle Advanced Replication. Any sensitive data that may leak privacy information of Registrants or Registrars or are prohibited by local laws and regulations are not replicated.
26.1.2. Physical Architecture
For the physical architecture of Whois, please refer to Figure 26-2 in Q26_attachment. Below is the detailed description.
The Whois server and Whois web server are redundantly deployed on multiple servers that are load balanced behind the F5s.
The full-text search service is deployed on master and slave servers. The master server synchronizes data and changes indices with the Whois database. It then synchronizes the changed indices and data to several slave servers. These slave servers are clustered behind the load balancer (F5) to provide searchable Whois services.
There are multiple Whois servers that are behind the load balancer (F5) to achieve load balancing and high availability.
26.1.3. Equipment List
See the Table 26-1 in Q26_attachment for a list of equipment of the Whois system (excluding any hardware equipment appeared in the network topological diagram of the primary data center):
26.2. Operations Plan
The KSRP has adopted the following measures to ensure high availability of the Whois system.
a) The hardware equipment and software systems used for the Whois system are redundantly deployed as server clusters that are load balanced behind the F5s.
b) The Whois system is redundantly deployed at the backup data center. In case of any unexpected disasters, KSRP can be switched over the backup data center within 30 minutes to continue its Whois services.
KSRP ensures that the downtime due to outages will not exceed 43.2 minutes monthly, with a high service availability of 99.9%, exceeding the SLA indicator (98%) specified in Specification 10 of the Registry Agreement.
It is estimated that 10,000 domain names will be delegated under the ʺ.citicʺ TLD within 3 years after its launch and when the registration volume reaches such target point, there will be 11,833 queries a day. KSRP is designed to scale to handle 30 million domains. The performance test results shows that KSRPʹs Whois system is capable of handling 5000 queries per second or about 430 million queries a day with the maximum response time not exceeding 1150ms.
As a result, KSRP exceeds the performance indicator of the Whois system specified by ICANN and is scalable for future demands.
Comparison with SLR Indicators
See the Table 26-2 in Q26_attachment for the contrast between the test data of the Whois system and the SLR indicators specified in Specification 10.
The Whois system supports both vertical and horizontal scalability. When KSRP reaches its maximum domain name capacity, the performance and throughput capacity of the Whois system can be expanded by upgrading production server hardware (vertical scalability) and⁄or adding more servers and bandwidth (horizontal scalability).
26.2.4. Data Synchronization
Data in the SRS database are synchronized to the Whois database via Oracle Advanced Replication at an interval of 5 minutes; the changed data of Whois database are synchronized to the full-text search system at an interval of 10 minutes.
Given the above data synchronization intervals, the command-line query requests and the web-based query requests have a latency of about 5 minutes, and the searchable query has a latency of about 20 minutes. Both latencies fully meet the Whois data update time (a latency of 60 minutes) specified in Specification 10.
26.2.5. Searchable Whois
KSRP implements the searchable Whois function via the full-text search technology of Apache Solr. The user logs on to the page specified by the Whois Web Server after passing the ID authentication, and inputs the query criteria as required in Specification 4; the Whois Web Server will forward the query request to the full-text search system which searches and returns the qualified results to the result page of the Whois Web Server.
How to Prevent Abuse
The searchable Whois function may be abused by malicious users to send spams to the Registrants or Registrars by harvesting email addresses from the query result. Such abuses may cause negative impacts on the Registrants and Registrars that may violate local laws and policies.
The ʺ.citicʺ Registry will take the following measures to prevent the searchable Whois function from abuses without violating local laws and policies:
a) The user must input the correct CAPTCHA before submitting each searchable Whois query request.
b) Only those insensitive contents meeting Specification 4 are allowed to be displayed in query results.
c) No more than 20 results are allowed to return for each searchable Whois query.
d) Impose a cap on the maximum number of queries in unit time from the same IP address.
26.3. Compliance with Relevant Specifications
26.3.1. Compliance with RFC 3912
The Whois system complies with RFC 3912 and listens to port 43.The client interacts with the Whois Server via TCP to complete the request-response process: the Client submits a text-based request to the Whois server; the Whois server then returns the query result in a text-based response to the Client.
26.3.2. Compliance with Specification 4 of the Registry Agreement
KSRP fully complies with Specification 4 of the Registry Agreement in terms of Whois query, zone file access and bulk registration data access.
a) Whois Query
The Whois system fully meets the relevant requirements specified in Specification 4 in terms of data objects (domain name, Registrar and name server), contents, queries and response format.
The Whois system provides two query methods: command line query and web-based query. The former is implemented according to RFC 3912 where the client interacts with the Whois Server in a request-response pattern. The latter is implemented as follows: the user accesses a specified page, inputs the query contents, selects query criteria (domain name, Registrar, name server), types in a CAPTCHA and then submit the query request. After receiving the request, the Whois Web Server will check the CAPTCHA. If the code matches, the Whois Web Server will retrieve the query result from the Whois Server and show the response content to the users in the resulting page.
b) Zone File Access
The ʺ.citicʺ Registry allows third-party entities who enter into an agreement with the Registry to access the zone file through KSRP according to Specification 4. It also provides ICANN or other ICANN designated partners with bulk access to authoritative zone files in the format and manner as specified in Specification 4.
c) Bulk Registration Data Access
The ʺ.citicʺ Registry will provides ICANN with registration data at specified time through KSRP. The content and format of provided data completely comply with the applicable requirements in Specification 4.
Moreover, when a Registrar is no longer able to provide the domain registry services, the ʺ.citicʺ Registry will submit all domain name data owned by that Registrar to the ICANN within the specified period. The content and format of provided data completely comply with ICANNʹs requirements.
26.4. Resourcing Plan
The development and test work for the Whois system of the KSRP has been completed. See section 31.12.2 for the overall human resource planning of KSRP. For the resourcing plan of this system, please refer to Table 26-3 in Q26_attachment and the above 26.1.3 for equipment resource planning.
27. Registration Life Cycle
The ʺ.citicʺ Registry defines the life cycle of the domain names under ʺ.citicʺ based on IETF RFCs required by ICANN and its own business needs. The life cycle consists of 6 periods: Available, Pre-audit, Registered, Autorenew Period, Redemption Grace Period and Pending Delete.
Pre-audit is a new period added by the ʺ.citicʺ Registry to ensure that domain name registration complies with local policies and laws. A domain name first enters the Pre-audit period upon creation (the EPP status is pendingCreate, and the RGP status is N⁄A). After manually examined by the ʺ.citicʺ Registry, the domain name officially takes effect and enters the Registered period (the EPP status is serverTransferProhibited for the first 60 days, afterwards, it changes to ok; the RGP status is addPeriod for the first 5 days and then changes to N⁄A ). It takes no more than 3 days for a domain to be manually examined after creation.
Please refer to Figure 27-1 in Q27_attachment for the full life cycle of a domain name, covering the periods such as creation, taking effect, expiry and final deletion.
27.2. Registration Life Cycle and Status
There are totally 18 registration statuses defined for EPP in RFCs 5730～5734 and for RGP in RFC 3915, excluding those that can be set by Registrars, such as clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, and clientUpdateProhibited).
The EPP statuses include OK, inactive, pendingCreate, pendingDelete, pendingRenew, pendingTransfer, serverHold, serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, and serverUpdateProhibited.
The RGP statuses defined in RFC 3915 include addPeriod, autoRenewPeriod, renewPeriod, redemptionPeriod, transferPeriod, pendingRestore, and pendingDelete.
27.2.1. Transition of Registration Status
During the whole registration life cycle, the registration status of the domain name evolves as a result of the life cycle period changes and the operations performed. Please refer to Figure 27-2 in Q27_attachment for the registration status transition in creation and deletion period of life cycle.
Other operations may affect registration status transition in the life cycle as follows:
a) Update Operation
The Update operation may only be performed on a domain name that is in the Registered period. After the operation, the RGP and EPP status remains unchanged.
b) Renewal Operation
The Renewal operation may be performed on a domain name that is in either the Registered or the Auto-renew period.
When a domain name enters the Registered period, the EPP status is changed to pendingRenew (the previous status is ok) or is added with pendingRenew. After the operation Renewal is done, the EPP status changes back to the previous one. The RGP status changes to renewPeriod; it will change back to its previous status 5 days later.
When a domain name enters the Auto-renew period, the EPP status changes to ok, and the RGP status changes to renewPeriod; it will changes back to ʺN⁄Aʺ 5 days later.
c) Transfer Operation
The operation Transfer may only be performed on a domain name that is in the Registered period and has been registered for more than 60 days. After the operation is performed, the EPP status changes to pendingTransfer; it will change back to its previous status once the transfer is complete. The RGP status changes to transferPeriod; it will changes back to its previous status 5 days later.
d) Restore Operation
The operation Restore may only be performed on a domain name that is in the Redemption Grace Period. Once the Registrar submits a restore request, the RGP status of the domain name changes to pendingRestore; if a formal restoration report is submitted within 7 days, the domain name changes back to its normal registration status (EPP: ok; RGP: N⁄A), otherwise, the registration status of the domain name changes back to the previous one.
27.2.2. Description of Status Transition
For each life cycle period of a domain name, the registration status transition is listed as below:
a) serverHold: all operations on a domain name are forbidden and the domain name canʹt be normally resolved.
In the Registered Period, if the Registry receives any complaint about that domain name, it will set the domain nameʹs EPP status to serverHold. If relevant competent authority confirms that the domain name is being abused or engaged in fraud, the domain nameʹs EPP and RGP statuses will be set to pendingDelete and the domain name will be transitioned to the Pending Delete period. Otherwise, the Registry will restore the domain nameʹs EPP status to ok and reset the RGP status to ʺN⁄Aʺ.
b) serverTransferProhibited: the domain name may be renewed, modified or deleted but not transferred.
When a domain name is in the Registered period, the EPP status for the first 60 days is serverTransferProhibited. If the Registrar submits any Update request, pendingUpdate is added to the EPP status. When the Update is complete, the EPP status changes back to serverTransferProhibited. If the Registrar renews this domain name, its EPP status remains unchanged and the RGP status is added with renewPeriod which will be cancelled 5 days later. If the Registrar deletes the domain name, both the EPP status and the RGP status change to pendingDelete.
When a domain name is in Autorenew Period, the EPP status is OK, and the RGP status is autoRenewPeriod. After 45 days, if the Registrar doesnʹt make a deletion request, the EPP status changes to ok and the RGP status is cancelled; if the Registrar does make a deletion request within the 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod and will be cancelled 5 days later.
c) serverUpdateProhibied: a domain name may be renewed, transferred or deleted but not updated.
When a domain name is in the Autorenew Period, the EPP status is serverUpdateProhibited and serverTransferProhibited, and the RGP status is autoRenewPeriod. If the Registrar doesnʹt make a deletion request within 45 days, the EPP status changes to ok and the RGP status is cancelled. If the Registrar does make a deletion request within 45 days or its account balance is not enough for autorenewal, the EPP status changes to pendingDelete and the RGP status changes to redemptionPeriod. If the Registrar makes a renewal request within the redemption period, the EPP status changes to ok and the RGP status changes to renewPeriod, which will be cancelled after 5 days.
d) serverRenewProhibited: a domain name may be updated, transferred or deleted but not renewed.
e) ok: a domain name may be updated, renewed, transferred and deleted.
If the Registrar makes a transfer request, the EPP status changes to pendingTransfer,; it will change back to ok after the transfer operation is complete. The RGP status is set to transferPeriod that will last for 5 days.
If the Registrar makes a deletion request, the EPP status changes to pendingDelete and the RGP status is set to pendingDelete.
If there is any complaint about the improper use of the domain name, the EPP status changes to serverHold. If the domain name is confirmed to be free from any abuse or fraud, the EPP status changes back to ok; otherwise, both EPP and RGP statuses change to pendingDelete.
f) inactive: within this status, the domain name is not associated with a host and thus canʹt be resolved.
If the Registrar submits a deletion request, the EPP status changes to pendingDelete and the RGP status changes to pendingDelete.
If the Registrar submits an update request to associate the domain name with a host, the EPP status changes to ok.
g) pendingDelete: with this status, the domain name can neither be resolved, nor can it be updated or transferred.
If a domain name is in the Pre-audit or Registered period or its EPP status is inactive or serverHold when the deletion operation is being performed, the EPP status changes to pendingDelete. The RGP status is set to pendingDelete. The domain name will be deleted after 5 days.
If a domain name is in the Autorenew Period when the deletion operation is being performed, the EPP status changes to pendingDelete, and the RGP status is set to redemptionPeriod.
h) pendingTransfer: this status indicates that the domain transfer request has been accepted. With this status, no update, renew, or delete operation can be performed on the domain name although the domain name is resolvable in DNS. After the transfer is complete, the EPP status changes back to its previous status. The RGP status is set to transferPeriod, which will be cancelled after 5 days.
i) addPeriod: the RGP status is set to addPeriod for the first 5 days after a domain name enters the Registered period. After 5 days, the RGP status is cancelled. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
j) renewPeriod: when a domain renewal request is submitted, the RGP status changes to renewPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, registration fees will be refunded.
k) transferPeriod: when a domain name transfer request is submitted, the RGP status changes to transferPeriod of 5 days. After 5 days, the RGP status changes back to its previous one. If the Registrar deletes the domain name within 5 days, fees resulting from transfer will be refunded.
l) autoRenewPeriod: the RGP status of a domain name when it is in the Autorenew period. If the Registrarʹs account has enough money for renewal after the domain expires, the RGP status changes to autoRenewPeriod and the domain name will be automatically renewed for 1 year. The Autorenew period lasts for 45 days. If the Registrar doesnʹt delete the domain name or does perform the renewal operation after 45 days, the domain name returns to the Registered period and the RGP status is cancelled; otherwise the RGP status changes to redemptionPeriod.
m) redemptionPeriod: the RGP status of a domain when it is in the Redemption period. If the Registrar submits a restore request, the RGP status changes to pendingRestore, otherwise, it changes to pendingDelete after 30 days.
n) pendingRestore: an intermediate status only applicable to domain names in the Redemption period of a domain name. When a domain name is in the Redemption period, if the Registrar submits a restore request to the Registry within 30 days, the RGP status changes to pendingRestore. If the Registrar submits a formal restore request report to the Registry within the subsequent 7 days, the EPP status changes to ok and the RGP status is cancelled; otherwise the RGP status changes back to redemptionPeriod. If the Registrar doesnʹt perform any restore and⁄or renewal operations within 30 days, the RGP status changes to pendingDelete.
o) pendingCreate: With this status, a domain name cannot be resolved; nor can any operation be performed on it. After the registration request of a domain name is submitted, the domain name enters the Preaudit period with the EPP status being pendingCreate and the RGP status being N⁄A. After the registration request passes auditing, the domain enters the Registered period; the EPP status changes to serverTransferProhibited and the RGP status is set to addPeriod. If the request doesnʹt pass auditing, the Registry directly deletes the domain name. In this case, the domain name changes back to the Available period.
p) pendingRenew, pendingUpdate: these two statuses are not applicable. The renewal and update of ʺ.citicʺ are performed in real time, so there is no manual review or the third partyʹs verification.
27.3. Compliance with RFCs
Taking the local policies and laws as well as its own businesses needs into account, the ʺ.citicʺ Registry makes some extension for the registration life cycle of the domain name based on RFCs 5730～5734 and RFC 3915.
27.4.1. Commitment to Registrant
The Registry Operator signs agreements with Registrants via the Registrars. These agreements strictly follow the policies of registration life cycle and provide management functions for domain names as directed by ICANNʹs requirements, agreements and regulations.
27.4.2. Technical Plan
For SRS, the EPP status can be used to determine whether a domain name can be updated, renewed, transferred or deleted, etc. The SRS fully supports redemption grace period operations defined in the RFC 3915 using the RGP status;
For DNS, the EPP status of a domain name is needed to determine whether the domain name is deployed in the root DNS zone file. It is also used to decide whether DNS service will be provided to the domain name.
For Whois, the EPP and RGP statuses of a domain name will be shown to the user in the query results.
27.5. Resourcing Plan
Please refer to Table 27-1 in Q27_attachment for the resourcing plan.
28 Abuse Prevention and Mitigation
As a Brand TLD, the Applicant would not tolerate any abuse of the domain names under its management. In this section, the Applicant would describe the proposed policies and procedures to prevent abusive registrations and minimize other activities that have a negative impact on registrants and Internet users.
28.1 Domain Anti-Abuse Policies
28.1.1 Categorization of the abuses
The Applicant would like to adopt the definition on the abuse by the Registration Abuse Policy Working Group (RAPWG), that the abuse is an action that:
a. causes actual and substantial harm, or is a material predicate of such harm, and
b. is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.
However, the RAPWG also finds out that the differences between registration issues and use issues have a very distinct impact to the TLD when it comes to the capacity to contain these two abuses.
Registration issues are related to the core domain name-related activities performed by registrars and registries. These generally include (but are not limited) to the allocation of registered names; the maintenance of and access to registration (WHOIS) information; the transfer, deletion, and reallocation of domain names.
In contrast, domain name use issues concern what a registrant does with his or her domain name after the domain is created-the purpose the registrant puts the domain to, and⁄or the services that the registrant operates on it. These use issues are often independent of or do not involve any registration issues.
Pursuant to the classifications of the domain name abuses, the applicant would like to adopt the following policies and mechanisms to address the potential abuses concerning the .citic TLD.
28.1.2 Anti-abuse Policies
With reference to the final report of the RAPWG, the Applicant will adopt the following clauses in the Registration Agreement that the abusive use of domain names will result in registration cancellation, domain name suspension or take down action.
The abuses are categorized as the following types:
I) registration abuse, includes but not limited to Cybersquatting; Front-running; Gripe sites; Deceptive and⁄or offensive domain names; Fake renewal notices; Name spinning; False affiliation; Cross-TLD Registration Scam; Domain kiting ⁄ tasting.
II) Abusive uses of domain names, includes but not limited to phishing, pharming, spoofing, malware⁄Botnet, Pay-per-click\Traffic diversion.
The Registration Agreement states that the registrant ʺrepresent, warrant, and agree that you hold the necessary rights to use or permit to use any item, word, or term submitted through the Domain Name Registration Services, and that such use shall not in any way to the best of your knowledge and belief:
(i) violate or potentially violate any right of any third party, including infringement or misappropriation of any copyright, patent, trademark, trade secret, or other proprietary right;
(ii) constitute or potentially constitute violations, such as, without limitation, false advertisement, unfair competition, defamation, invasion of privacy, invasion of rights, and discrimination;
(iii) cause or potentially cause a business dispute, personal dispute, or any other dispute;
(iv) be or potentially be unlawful, harmful, fraudulent, libelous, slanderous, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, or otherwise offensive;
(v) be or potentially be racially, ethnically, or ethically objectionable; or
(vi) constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable law, including local, provincial, state, national, international, or other laws. ʺ
Pursuant the Registration Policy published on the website of the Applicant, the Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on suspension, takedown or similar status, that it deems necessary, in its discretion;
(1) to protect the integrity and stability of the registry;
(2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process;
(3) to avoid any liability, civil or criminal, on the part of the Applicant, as well as its affiliates, subsidiaries, officers, directors, and employees;
(4) per the terms of the registration agreement or
(5) to correct mistakes made by the Applicant or any Registrar in connection with a domain name registration.
The Applicant also reserves the right to place upon registry suspension, takedown or similar status a domain name during resolution of a dispute. Abusive uses, as defined above, undertaken with respect to .citic domain names shall give rise to the right of the Applicant to take such actions in its sole discretion.
28.2 Abuse prevention Mechanisms
28.2.1 Anti Abuse Contact Window
The Applicant will publish its domain name anti-abuse policies at the website (www.nic.citic), and also establish an online contact for handling of domain name abuse complaints. The contact information will include at least fixed telephone number, fax number and email address as listed below:
Fixed phone: 8610-59661032
Email: [email protected]
A team will be assigned to handle the complaints. All accredited registrars of the TLD will be required to set up a contact to liaise with the registry on abuse mitigation purpose. The anti-abuse policy will also be shown on the website of the registrars.
Any changes on the contact information will be published on the Registry Operatorʹs website, and will notify registrars and ICANN in a timely manner.
28.2.2 WHOIS accuracy Requirement
The Applicant believes that an accurate and genuine WHOIS information requirement is essential to the proper use of the domain name and is vital in tackling the abuses of the domain names. The applicant hence require the registry, registrars and registrants to make sure the WHOIS information of the registrant is accurate and genuine, any update of the WHOIS information shall be done in a timely manner.
Requirement for Registrants
When registering a .citic domain name, the Registrant has to consent to clause on WHOIS requirement at the Registration Agreement, and ensure that the submitted registration information is authentic, accurate and complete. The registrant has to consent that should there be any changes on the WHOIS information in the future, the registrant will update the registration information within 30 days upon occurrence of the changes.
The Registration Agreement states that the registrant must submit the following information:
a) The complete and accurate WHOIS information of the domain name required by the Registry pursuant to the Specification 4 of the Registry Agreement;
b) Signed copy of the Registration agreement.
The registrants also consent that the registrant is responsible for the accuracy of the WHOIS information of the domain name. Failure to adhere to the accuracy requirement will cause suspension or termination of the registration.
Requirement for Registrars
One of the requirements of the accredited registrar is that the registrar is capable of verifying the WHOIS information submitted by the .citic domain name registrant.
In the proposed RRA agreement with .citic Registry Operator, the Registrar is required to take necessary measures to verify the authenticity, accuracy and completeness of the registrant information before domain names registration. The verification mechanisms include but not limited to emails, SMS, and phone call verification. The identification of the registrant will also be verified.
The process for the WHOIS verification will be carried out as follows:
(1) The registrar will check the completeness of the registration material and documentation;
(2) The registrar will verify the WHOIS information of the registrant. The registration system of the registrar is required to send out email or SMS to each email address or mobile phone number of the registered domain name to ask for verification of the receiver. No reply will be deemed inaccurate information.
(3) The Identification material of the registrant is required. The individual registrant is required to submit the photocopy of the ID card or passport of the registrant, and the entity registrant is required to submit the photocopy of the Business Certificate or other legal documentation of the establishment of the entity.
Requirement for the Registry Operator
The Registry Operator will set up an annual evaluation process for Registrars on their performance on the WHOIS verification. The standard is based on the complaints received and the WHOIS inspection resulted performed by the Registry Operator based on the Registry-Registrar Agreement (RRA). The random inspection ratio is no less than 1%. If the proportion of qualified registrants in random inspection is lower than 90%, the Registrar is deemed unqualified. If the proportion of qualified registrants is 95% or higher, the Registrar are considered qualified. The unqualified registrar will be punished ,and the qualified registrar will be awarded and honored pursuant to the Registry-Registrar Agreement (RRA)
Requirement for the Back-end Service Provider
The applicant requires the Back-end Service Provider, KNET co., Ltd to carry out a random check on WHOIS information of the domain name registered on the SRS on a daily basis. KNET will verify the registrantʹs Identification via the authoritative database of the government offices to ensure their authenticity and accuracy.
Any inaccurate WHOIS information will be sent back to the contact of the Applicant mentioned above. The Applicant will request the registrar concerned to update the registrant information within 5 working days. Failure to do so would result in domain name suspension or takedown and the registrar will be noted as breach of the Registry-Registrar Agreement (RRA).
28.2.3 Reasonable Access Control
The registrar will provide with a secured online access to registrant to manage the domain names. This access may provide with a platform for domain name information update, domain name transfer request, renewal or deletion. The management system will be provided with SSL connection, reinforced password control and CAPTCHA verification. The system will send out notice to request the registrant change the password every three months. The registrant will be able to update registrant information, requesting domain name transfer Auth-code and domain name deletion. All these operations will require a verification process.
In the event of domain name transfer, the registrant will be required to obtain Auth-code at the losing registrar and give it to the gaining registrar. In addition to that, the losing registrar is required to send transfer notice to the administrative contacts and technical contacts of the registrant before transferring. The gaining registrar is required to notify the administrative contacts and technical contacts of the registrant after transferring.
In the event of the domain name update and deletion, the registrant will be required to verify the operation either via email or via written notice. In the meanwhile, the administrative contacts, technical contacts and billing contact of the registrant will all be informed of the operation.
28.2.4 Disposal of Orphan Glue Records
By definition of SSAC, a glue record becomes an ʺorphanʺ when the delegation point NS record referencing it is removed without also removing the corresponding glue record. The Applicant will adopt the management policy of not allowing orphan record.
KNET ,the Back-end Service Provider ,has designed The KNET Shared Registry Platform to automatically mark the generated orphan glue records and the date when suspending a domain name resolution or deleting a domain name. At the time that the orphan glue record is generated, the system will automatically send an email notice to the administrative contacts, technical contacts of the domain name and its sponsoring Registrars, informing the orphan glue record should be deleted within a 30-day grace period.
Moreover, the registry system will carry out scanning and cleansing program on orphan glue records on a daily basis. Those orphan glue records that are no longer used as well as those that exceed the 30-day grace period will be deleted.
When provided with evidence that the glue is indeed present to abet malicious conduct, the Applicant will take the following action:
1) Upon reception of the complaint, the Applicant will coordinate with its back-end provider, KNET on the issue;
2) KNET will report back on the status of the orphaned glue record according to its daily scanning record within 24 hours;
3) The Applicant shall instruct an immediate deletion order to KNET to remove the orphan glue record and KNET will delete the record within 8 hours upon receipt of the order.
28.3 Abuse Mitigation Mechanism
The Applicant will set up an anti-abuse mechanism to act swiftly to mitigate any abuse and take down any infringing .citic domain names. Based on the nature of the abuses mentioned above, the Applicant shall act in three levels to counteract to potential registration abuse and domain use abuse:
28.3.1 Registration abuse mitigation mechanism
Since the mission of .citic TLD is to serve the interest of CITIC Group Corporation, the Applicant does not seek any commercial interests, the Applicant regards prudent and proper use of domain names higher than pure volume.
The Applicant will adopt such rules in the Registration Agreement to prevent infringement on the right of third parties or violation on applicable laws and regulations. The Registry-Registrar Agreement also states that the Registrar is responsible for the WHOIS accuracy of the domain names.
In practice, The Applicant will require any domain name registration request to provide with a supporting letter to certify that its applied domain name is approved by CITIC Group Corporation. . On top of that, the accurate WHOIS information of the domain name will be verified. Details of the WHOIS information verification mechanism can be seen on the above section. Any inaccurate WHOIS information could lead to domain name cancellation or rejection.
Through the strict requirement and audit process prior to registration, the .citic TLD shall avert or mitigate at least several registration abuses in question. Please refer to the Table 28-1 in Q28_attachment for the more details.
In the event of compliant on domain registration abuses, the applicant will follow the procedures as described below:
1) the Applicant will put the domain name in question on registry lock, then
2) the Applicant will determine the nature of the complaints, if this falls within the ability of the Applicant, the Applicant will instruct the sponsoring registrar to take down the domain name pursuant to Registry-Registrar Agreement (RRA) or Registration Agreement;
3) Should this complaint be beyond the ability of the Applicant, the Applicant will follow the procedure that is described in the following section.
28.3.2 Abuse mitigation mechanism
With regard to abusive use of .citic domain names, which may concern phishing, pharming, malware downloading, etc., the Applicant will rely on the registrars, the interested parties or the Internet users to detect the abuse, and in collaboration with other third party security vendors or Law Enforcement Agencies, to tackle such abusive use of the .citic domain names.
A typical process to tackle the registration abuse is as such:
1) Any complaints to the domain names shall be sent to the abovementioned contact via telephone, fax or email;
2) Upon receipt of the complaints, the Applicant shall identify the abuse incidents involving the domain names with the help from other third party security vendors or Law Enforcement Agencies if necessary in five days;
3) Once the abuse is identified, a notice of breach will be sent to the domain name registrant, registrar and any party concerned and request immediate action to mitigate the abuse in 24 hours;
4) Should the Applicant receive no response from the registrant or the registrar, pursuant to the RRA, the Operator shall notify the registrar to take a suspension action or takedown within 4 hours; the Applicant shall also notify the registrant on the action taken via the contact method contained in the WHOIS.
The registrant is also allowed to dispute the suspension or takedown action should the registrant if the domain name is suspended mistakenly. The procedure for the plea and process is as follow:
1) The registrant file the plead to the Applicant via the contact information published on the website with the evidence that the domain name is registered and used in accordance to the Registration Agreement;
2) The Applicant will direct the evidence to the party who is identify the complaints to review. If the evidence is approved and the restore order is issued, the Applicant will instruct the registrar to restore the domain name within five working days pursuant to Registration Agreement and Registry-Registrar Agreement (RRA).
28.3.3 Domain names dispute Mechanism
Sometimes the domain name abuse complaints will have to go through dispute resolution provider. When the domain name in question is in dispute or other legal proceedings, the Applicant will take the following actions to prevent abuse:
i) When the domain name dispute is filed via the Uniform Rapid Suspension Policy, the Applicant will ʺlockʺ the domain name in question within 24 hours upon receipt of the ʺNotice of Complaintʺ, restricting all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. After the ʺlockʺ operation, the Applicant will notify the URS Provider immediately upon locking the domain name (Notice of Lock). The Applicant will also take action as per described by the URS Provider.
ii) Domain name disputes may also be filed under Uniform Dispute Resolution Procedure (UDRP). The Applicant shall monitor its accredited registrars to implement the arbitration result.
Details of the Dispute resolution mechanisms please refer to answer to Question 29.
28.3.4 Collaboration with other parties
Externally, the Applicant will work with other parties to prevent and mitigate the abuses on its domain names. The procedures or mechanisms of the cooperation will be described as follows:
With contractual relationship with ICANN, the Applicant is obliged to abide by the legal obligations described on the Registry Agreement. The Applicant also consent to the Consensus policies and temporary policies specification described in the Specification 1 of the Registry Agreement. Details of the consensus policies can be found at this address: http:⁄⁄www.icann.org⁄en⁄general⁄consensus-policies.htm.
With regard to Temporary Policies, the Applicant shall comply with and implement all specifications or policies established by the ICANN Board on a temporary basis. The Applicant pledges that the Temporary Policies will be implemented within a month upon the notice of the policies. In the event of a conflict between Registry Services and Consensus Policies or any Temporary Policies, the Consensus Polices or Temporary Policy shall control.
With CNCERT⁄CC and other security providers
The Applicant will establish a contact window with CNCERT⁄CC, and other security providers to take down domain name abuse incidents concerning .citic domain names. On the other hand, the Applicant will rely on them to identify domain name abuse incidents. The collaboration mechanism is as follows:
1) The Applicant will instruct the sponsoring registrar to send email notification the registrant (administrative contact, technical contact or billing contact) concerned to respond to the domain abuse complaints upon receipt of the takedown notice from CNCERT⁄CC; the notification requires the registrant to respond within 5 days; in the meanwhile, the domain name in question will be put in ʺlockʺ status;
2) Should there be no response from the registrant, the Applicant will instruct the sponsoring registrar to put the domain name in suspension take down and a notice of takedown will be sent to the email address of the registrant.
28.4 Resourcing Plan
It is advised that at least one auditor is furnished to carry out the registration accuracy audit, and a legal counsel is advised to address the abuse complaints.
On the technical side, the staff will be allocated to following area to ensure a swift and effective action to address the abuses.
29. Rights Protection Mechanisms:
Abusive use policies, takedown procedures, registrant pre-verification, authentication procedures
As described on Specification 7 of the Registry Agreement, “Registry Operator shall implement and adhere to any rights protection mechanisms (“RPMs”) that may be mandated from time to time by ICANN”.
As a TLD aiming at protecting and promoting the brand of CITIC Group Corporation online, the Applicant will implement a proper Right Protection Mechanism (RPM) to safeguard trade mark, geographic names and other naming rights based on the RPMs mandated by the Registry Agreement. The implemented RPM includes registration prevention mechanism, anti-abuse mechanism and dispute resolution mechanism. The Applicant believes that along with reinforced anti-abuse mechanisms deployed as in answer to Question 28, the RPM shall effectively protect the legal right holders and mitigate the infringement or encroachment on it.
29.1. Reserved name list
Pursuant to the Specification 5 of Registry Agreement, except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve (i.e., Registry Operator shall not register, delegate, use or otherwise make available such labels to any third party, but may register such labels in its own name in order to withhold them from delegation or use) names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:
2. Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations.
2. two-character labels. All two-character labels shall be initially reserved.
3. Tagged Domain Names. Labels may only include hyphens in the third and fourth position if they represent valid internationalized domain names in their ASCII encoding (for example ʺxn--ndk061nʺ).
4. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the TLD. Registry Operator may use them, but upon conclusion of Registry Operatorʹs designation as operator of the registry for the TLD they shall be transferred as specified by ICANN: NIC, WWW, IRIS and WHOIS.
5. Country and Territory Names. The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level and at all other levels within the TLD at which the Registry Operator provides for registrations:
5.1. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union
5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
5.4. Reserved list of the names of countries and regions subdivisions
In addition to the reserved Country and Territorynames, .citic registry operator shall reserve the names of countries and regions subdivisions which are listed in ISO 3166-2⁄3 table. The national geographic names in China where the registry is operating will also be included in the reserve name list:
1) the abbreviation of the countries and regional subdivision names(in both Chinese and English) which listed in ISO 3166-2⁄3, and the abbreviation of the countries and regional subdivision names (in both Chinese and English) which listed in ISO 3166-3；
2) the full names and abbreviations (in both Chinese and English) of Chinese provinces and municipalities under direct jurisdiction of the central government, and the unofficial abbreviations of geographical names
3) the full names and abbreviations of municipal administrative regions in China’s provinces.
Provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.
6. Full names and official abbreviations of international inter-governmental organizations;
7. Names of PRC national institutions;
8. The proper names of CITIC Group Corporationʹs leaders, trademarks, institutions, as well as the products and services.
29.2 Registrant pre-verification and Authentication
As mentioned in answer to Question 18, the Applicant has set a restrictive qualification requirement for .citic domain names. The registration application has to be audited by the registrars and should be audited by the Registry Operator before the domain name is activated and properly provisioned.
The Registration Agreement states that the registrant “represent, warrant, and agree that you hold the necessary rights to use or permit to use any item, word, or term submitted through the Domain Name Registration Services, and that such use shall not in any way to the best of your knowledge and belief:
(i) violate or potentially violate any right of any third party, including infringement or misappropriation of any copyright, patent, trademark, trade secret, or other proprietary right;
(ii) Constitute or potentially constitute violations, such as, without limitation, false advertisement, unfair competition, defamation, invasion of privacy, invasion of rights, and discrimination;
(iii) Cause or potentially cause a business dispute, personal dispute, or any other dispute;
(iv) Be or potentially be unlawful, harmful, fraudulent, libelous, slanderous, threatening, abusive, harassing, defamatory, vulgar, obscene, profane, hateful, or otherwise offensive;
(v) Be or potentially be racially, ethnically, or ethically objectionable; or
(vi) Constitute a criminal offense, give rise to civil liability, or otherwise violate any applicable law, including local, provincial, state, national, international, or other laws. ”
29.2.1. Registrant pre-verification
The accredited Registrar of .citic TLD must perform a pre-audit process on each domain name registration applications, requesting the registrant to submit the documentary evidence to verify that its applied domain name is approved by CITIC Group Corporation. Registrars are also required to perform WHOIS verification of the registrant. Details of the WHOIS verification mechanism can be found in answer to Question 28. Any breach on the abovementioned principles will result in the annulment of the registration. Any Registrar who violates the above stipulation will also be subject to penalties or even be disaccredited.
The Applicant performs a random auditing on the registered domain names within five-day Grace Period. Any detection on Rights violation will result in rejection of the registration of the domain name.
29.3. Start-up rights protection measures
As required in Applicant Guidebook, the Applicant will implement 2 start-up right protection mechanisms: the Sunrise period and a Trademark Claims service.
Sunrise Service: although the Applicant would like to reserve or block any names in the TMCH, the Applicant will implement a 60-day Sunrise service period for eligible trademark holders to register or reserve its names at the second-level of the .citic TLD at the pre-launch period. However, as a TLD with the purpose to serve itself, the Applicant also reserve the right to deny any trademark name registration request at its sole discretion.
Proposed Sunrise Registration Process
I) For a Sunrise service, Sunrise eligibility requirements (SERs) will be met as a minimum requirement, verified by Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP).
If someone is seeking a sunrise registration, the Registry Operator will provide a notice to the holder of the trademark in the Clearinghouse that is an Identical Match to the name to be registered.
Sunrise eligibility requirements (SERs)
The proposed SERs include: (i) ownership of a mark (that satisfies the criteria in section 7.2 of TRADEMARK CLEARINGHOUSE in gTLD application Guidebook), (ii) optional registry elected requirements re: international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.
Sunrise Dispute Resolution Policy (SDRP)
The proposed SDRP must allow challenges based on at least the following four grounds: (i) at time the challenged domain name was registered, the registrant did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.
Trademark Claims service: although it is highly unlikely that the Trademark names will be easily registered due to the stringent qualification requirement by the Applicant, the Applicants still would like commit itself to offering the Trademark Claims service at the initial open registration phase for 60 days.
Proposed Trademark Claims service
i) At the first 60-day Trademark Claims Service, The registry operator will send a Trademark Claims Notice (as described in the attachment of the Trademark Clearinghouse) to the prospective registrant, with a link to the Trademark Clearinghouse Database.
ii) The prospective registrant is suggested to access the Trademark Clearinghouse Database to check the trademark right.
iii) If the domain name is registered in the Clearinghouse, the registrar (again through an interface with the Clearinghouse) will promptly notify the mark holders(s) of the registration after it is effectuated;
iv) in the meantime, The Registry Operator will be reported by The Trademark Clearinghouse Database when registrants are attempting to register a domain name that is considered to contain the element of a trademark.
29.4 Dispute Resolution Mechanisms
If any institution or individual raises a dispute over any registered domain names, then such dispute will be settled via Uniform Dispute Resolution Procedure (UDRP) by the dispute resolution body either authorized by the Applicant or other Dispute resolution service provider accredited by ICANN.
Pursuant to the Specification 7 of the Registry Agreement, the Applicant will comply with the following dispute resolution mechanisms as they may be revised from time to time:
a. the Trademark Post-Delegation Dispute Resolution Procedure (Trademark PDDRP) and the Registry Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN. the Applicant agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Registry Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination; and
b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN, including the implementation of determinations issued by URS examiners.
Furthermore, In the event of dispute among right holders, the Applicant shall implement the following rules before applying the Uniform Domain Name Dispute Resolution Policy (UDRP).
Of course, the parties involved in the dispute can also take the dispute to court should they are dissatisfied with the arbitration result. The Applicant shall observe any court order on the dispute.
29.5 Resourcing Plan
Given the resource plans placed in the Abuse Prevention and Mitigation plan in answer to Question 28, it is advised that the legal counsel that is in charge of the abuse complaints will be sufficient to carry out the Right Protection Mechanisms described in this section.
30A. Security Policy
According to ICANNʹs New gTLD Applicant Guidebook, the ʺ.citicʺ Registry has selected KSRP as the back-end service platform. To ensure security, KSRP is implemented in accordance with the internationally accepted ISO 27000, with full consideration of the security aspects of services and data as required by ICANN.
30A.1. Description of Information Security Policies
KSRP is built to achieve the following goals in accordance with ISO 27000:
a) Ensure that the information system supporting critical businesses is free from any outage resulted from failure, virus or attacks. The service level meets the committed SLA;
b) Safely and effectively protect the user information so that it will not be leaked, missing, falsified and unavailable;
c) Be able to rapidly, effectively and properly recover the system platform from any disaster.
To meet these goals, KNET has implemented the information security management policies in accordance with ISO 27000 in the following 12 aspects:
a) Assets security management
b) Human resources security
c) Physical and environmental security
d) Operation regulations
e) Storage media management
f) Backup of data and services
g) Network infrastructure security
h) Network security events monitoring
i) Access control
j) Application services security
k) Information security events management
l) Management of business continuity
The ISO 27000 series that are followed by KSRP include:
a) ISO 27001: Information Security Management System
b) ISO 27002: Code of Practice for Information Security Management
c) ISO 27004: Information Security Management Measurement
d) ISO 27035: Information Security Incident Management Classification
30A.2. Overview of Information Security System Framework
KSRP is designed and built in the following information security measures to mitigate security risks caused by mistakes occurred in day to day work.
30A.2.1. Assets Management
KSRP recognizes and classifies the assets of the data centers and DNS nodes as follows:
a) Data: databases and database manuals;
b) Services: telecommunication services as well as other public utilities and their contracts;
c) Hardware resources: network equipment, host brand, model, configuration parameters and operating manuals or instructions;
d) Software resources: SRS server software, DNS software, Whois software, Registrar business support system, Registry business support system, mail server software, applicable website software and respective installation manuals and configuration files.
In order to effectively protect information resources above, KNET classifies the platform assets by both importance and sensitivity. Please refer to Table 30A-1 in Q30_attachment.
30A.2.2. Human Resources Management
a) Establish definite posts with clearly defined duties to ensure people can really understand the nature of that post he⁄she applies for;
b) For crucial posts (posts above the director level, DBA and security specialist), KNET will carefully evaluate the applicantsʹ background to ensure that they are qualified for such posts. The background information under evaluation may include a) personal profile; b) resume; c) academic level and professional qualifications; d) identity; e) other details;
c) The New Employee On-board Procedures clearly stipulate that the new employee sign a confidentiality agreement with the company shall his⁄her post require;
d) The Human Resources Department will regularly conduct training sessions for new employees to ensure all staff members are full aware of the serious consequences of information security threats;
e) The security commissioner regularly performs inspections on employeesʹ work to ensure that they perform their jobs in a way conforming to the security policies;
f) The Employee Exit Procedures shall stipulate that work handover be done well before an employee leaves the company. The Human Resources Department shall not handle the exit procedures until the employeeʹs manager confirms that his⁄her authority to access the internal systems has been revoked.
30A.2.3. Physical Environment Security
a) KSRP has established two enclosed and controlled physical work environment: one is a peripheral work environment called the Office Zone; the other is an internal environment called the Monitoring Center.
b) The company staff enters the the Office Zone with an access card. Non-company personnel are not allowed to enter the zone without permission.
c) Any visiting guest must always be escorted by a staff member.
d) The Monitoring Center is protected by stricter security measures. Only staff members received a higher security clearance are allowed to enter.
e) In order to ensure the secure operation of the system and identify any failings in regular work, we have applied video monitoring to the office zone and so we can provide the subsequent security auditing work with some evidence.
f) KSRP employs identity card and fingerprint authentication for access control. It combines physical security access with other security protection measures to build a secure working environment.
g) To ensure timely response to emergency, KSRP has deployed dual-backup support for communication services and utility facilities in the data center, including Internet access lines, telephone lines, electricity, power supplies, and air conditioning.
30A.2.4. Operation Regulations
KSRP has established strict procedures for managing changes to the online services which include Software Testing Procedures, Services Deployment Procedures, and Services Change⁄Upgrade Procedures. The following provisions are stipulated:
a) Before changes are made to the online services, the new software shall be strictly tested and pass the security validation scanning performed by the security specialist;
b) Operation personnel shall obtain the approved change request before deploying the changes in production;
c) Operations personnel shall back up software and data in production before rolling out changes to ensure that they can roll back the changes in case of deployment failures;
d) Operations personnel shall strictly follow the instructions stated in Service Deployment Practice Manual when rolling out changes to services in production;
e) After changes are made to the services in production, Operations personnel shall submit the services installation and maintenance documents to the O&M Department.
f) After changes are made to the services in production, the system administrator will perform an all-round monitoring on them.
30A.2.5. Storage Media Management
Except for system administrators, other staff members are not allowed to copy data between the production environment and the external media. Only the system administrators are authorized to perform data upload⁄download operations and all these actions are logged by KSRP for auditing.
The system administrator backs up a variety of data and application services logs from production to tapes as required every day. KSRP designates special personnel to keep these tapes in a safe place and rotate them for reuse once the data retention periods expire.
30A.2.6. Backup of Data and Services
KSRP backs up data and services with two objectives:
a) The services can be recovered as soon as possible in case of any disaster⁄failure;
b) The business can be audited at any time if needed;
To achieve these two goals, KSRP backs up the following assets:
a) Data in the databases;
b) Software resources (including binary code and relevant source code, configuration files and design documents) and operation log;
c) The standard operating system and third-party services software;
d) All equipment, models, specifications and other documents to the installation, operations and maintenance of the service environment.
Assets backup shall be done by the person in charge, and inspected by the security specialist on a periodic basis. Any identified issues shall be fixed as required.
The backup and inspection patterns vary by the natures of the assets. Different equipment, models, specifications as well as the installation and maintenance manuals, services and relevant documents shall be backed up and inspected when they are created and⁄or altered; the software resources and operation logs shall be backed up daily and inspected on an periodic basis; the data in the databases shall be backed up and inspected daily.
There are three daily data backup copies for KSRP data, one stored in the primary data center, one stored in the backup data center, and one copy stored on a tape as offline backup. This ensures that the system services can be recovered properly in case any man-made⁄natural accident occurs.
30A.2.7. Security of Network Environment
The KSRP network infrastructure is divided into two zones by firewalls: internal protection zone and the DMZ. The database platform is placed in the internal protection zone protected by a database firewall in front of all the front ends; the operating network environment is placed in the DMZ for providing services to the outside.
As the services provided by KSRP are Internet-based, the whole network infrastructure is very important for the platform. In order to maintain a robust and secure network environment, dedicated network professionals are assigned as the principal for all the network equipment assets to ensure the whole network is secure, smooth and fault-tolerant.
The duties of the network professionals include:
a) Design the network topology;
b) Ensure all network equipment are working normally;
c) Ensure these equipment are reachable to each other over the network;
d) Maintain passwords for all network equipment to keep unauthorized people from accessing these equipment;
e) Keep the network equipment highly available; timely back up all network routing policies and firewall control policies in order to ensure timely recovery from any failure;
f) Audit network security events to timely identify any potential threats.
30A.2.8. Network Security Events Monitoring
In addition to assisting the network professionals to maintain a secure, smooth and robust network environment, system administrators have another important role of monitoring various events occurred over the network.
KSRP is equipped with management functions to perform comprehensive monitoring over network equipment, servers and applications. A system administrator carries out the following daily tasks to manage network and services events with the monitoring platform:
a) The system administrator inspects various network and services events from the network management equipment, IDS equipment and the monitoring platform;
b) The system administrator follows the Services and Maintenance Manual to handle any identified network events;
c) The system administrator follows the Evens Response Procedures for any identified events that require communications.
30A.2.9. Access Control
In order to ensure only authorized users are allowed to access the services provided in the operating environment, KNET has enforced the following operation rules as part of the assets management requirements:
30A.2.9.1. Passwords Management
a) The identity authentication is based on user name⁄password; the password must be strong;
b) If the user tries to login with a wrong password 3 times in a row, the account is locked for at least one hour in order to prevent any malicious login attempts.
30A.2.9.2. Identity Authentication and Authorization:
a) Before accessing any system serving specific users, the user shall pass the identity authentication;
b) The user authority shall only be assigned by the system administrator.
30A.2.9.3. Routing Policies:
a) KSRP blocks remote access to the network via Internet for management purposes ;
b) For any privileged user logging on to any application system, the source IP address of the userʹs machine shall be qualified;
c) Any session that stays idle for over 30 minutes shall be disconnected;
d) For services only open to specific IP addresses, routing qualifications shall be provisioned for such IP addresses on the firewall.
30A.2.9.4. Host Restrictions:
a) Logging on to the operating system of a host shall be done via SSH;
b) Any operations done on the host after login shall be logged for auditing purpose.
c) The ROOT account of the host can only be accessed by the administrator; the ROOT account shall not be used unless it is absolutely necessary.
d) The host password shall be changed regularly.
30A.2.9.5. Firewall Protection:
a) All application services (except for DNS services) shall be placed behind the firewall for security purpose;
b) Only the ports used by these application services shall be open via the router and firewall; all other ports shall be closed.
c) The maximum number of connections shall be capped for all application services to mitigate risks of large-scale malicious attacks.
30A.2.9.6. Data Encryption:
a) Any confidential business data shall be transferred via HTTPS;
b) Any data files shall be transferred via VPN.
30A.2.9.7. Security Auditing:
a) The user list and user access authority shall be reviewed on a regular basis to ensure the authority is up-to-date and invalid accounts are timely removed;
b) The network access log of the user shall be audited by the security specialist on a regular basis.
30A.2.10. Security of Application Services
KSRP ensures security of the application services in two aspects: 1) security of the operating system; 2) security of the application programs.
Security of the operating system is guaranteed by the following measures:
a) Uniformly install the operating system and security-related patches;
b) Turn on the firewall and only open the ports required by the application services;
c) Regularly check the operating system users and system files to ensure the important system files are not compromised.
Security of the application programs is guaranteed by the following measures:
a) For the application services provided to specific users, those users shall pass the identity authentication (certificate authentication or password authentication). If password is used, the password strength shall comply with the security policies;
b) If a specific user performs any operation on data via the application system, the system shall check the userʹs identity and rejects the operation if it is unauthorized. A detailed log shall be created for any authorized change for auditing;
c) The Measures of Administration of Source Code Security prohibits anyone from disclosing the source code to any third party;
d) Before any application services being put online, the security specialist shall perform a security scan on the software to identify any potential security threats;
e) The system administrator shall use the configuration administration tools to ensure the version of the service software in the operating environment complies with that of the software provided by the R&D Department;
f) The Security Management Procedures of Application Service requires that the security specialist track any defects of the third-party software disclosed by the company and timely upgrade the software;
g) The security specialist shall carry out reinforcement on the firewall and operating system in order to reduce the risks caused by any malicious intrusion to the application services.
30A.2.11. Information Security Events Management
On KSRP，information security events are managed by the information security professionals who are in charge of collection and analysis of all information security events as well as formulation and implementation of the remedial solutions.
The information security specialist collects security events through two channels: the network monitoring log of the system, and authoritative websites disclosing security vulnerabilities.
The information security specialist works out a platform improvement plan after collecting and analyzing applicable security events. The plan will be submitted to the corporate management for approval before execution.
30A.2.12. Security Management of Business Continuity
Information systems of KSRP are classified by their importance as below:
a) Critical information systems: DNS services;
b) Important information systems: SRS services, Whois query, Registrar business support platform, Registry business support platform;
c) General information systems: websites, mail system, etc.
One of the following two cases constitutes an outage of an information system: 1) the system fails to provide services to the public; 2) the services level fails to meet the SLA. If the outage lasts for a while, it is considered as an event. The longer the event lasts, the bigger the loss is.
In addition, if user data of KSRP is leaked, missing or falsified, these occurrences are also considered as events. The bigger the ratio of affected data, the greater the loss caused by the event.
For the classification of events occurred on KSRP, please refer to Table 30A-2 in Q30_attachment:
In order to address the above-mentioned circumstances, KSRP has designed a series of services backup & restore procedures to ensure service continuity.
30A.3. Security Commitment to Registrants
KSRP provides the following security commitments to Registrants:
a) The availability of the DNS services is 100% monthly;
b) The availability of the SRS services is 99.9% monthly;
c) The availability of the Whois services is 99.9% monthly;
d) Service outage to the primary data center caused by disasters such as earthquake and flood, shall not last for more than 1 hour with almost no data loss.
e) Any data related to the Registrants will not be leaked;
It appears the WHOIS Server is temporarily unavailable, please try again later.