| gTLD | Full Legal Name | E-mail suffix | Detail | | .tatar | Limited Liability Company ʺCoordination Center of Regional Domain of Tatarstan Republicʺ | cctld.ru | View |
1. INTRODUCTION
The Applicant plans to provide the following services:
a) Domain Name Registration Services.
b) Dissemination of TLD zone files.
c) Dissemination of contact or other information concerning domain name registrations (WHOIS).
d) DNS Security Extensions (DNSSEC).
e) Registrar services.
f) End-user services.
The registry services will be implemented with regard for stability and safety requirements set forth in ICANN policies.
To maintain the stable environment, registry services will be provided in accordance with applicable standards and recommendations of IETF and best practices whose value was proven by international Internet community and ICANN.
For safety reasons the access to services for registrars and other users is limited by using technical means, such as access list management, number of requests limit assignment, usage of cryptography and management of login names and passwords. Detailed security policies are described in the answer to Evaluation Question #30 (b).
The second-level domain name registration, as well as receipt or update of registry data are implemented in compliance with RFC 5730-5734, 3915 and do not affect the bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.
DNS services comply with the officially applied standards (RFC 1035 and Specification 4 to the Registry Agreement (hereinafter – Specification 4)) and, due to employment of a distributed system, they do not create conditions which negatively impact bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.
WHOIS service is implemented in compliance with Specification 4 and RFC 3912.
DNSSEC service is implemented in compliance with RFC 4033-4035, 5155, 5910.
2. DOMAIN NAME REGISTRATION SERVICES
A full range of standard domain registration services will be provided. All this services are made available for any ICANN-accredited registrar who has entered into Registry-Registrar Agreement (RRA) with Registry Operator (hereinafter – Registrar).
The services enumerated in this section cannot be provided for an object that has EPP status prohibiting the operation. The Registrar sponsoring object cannot override the restriction set by the Registry. The complete description of statuses is provided in RFC 5730-5733.
2.1. Domain name registration
Domain name registration service consists of the insertion of the domain name, registration period, registrant and registrant’s contacts, NS records into the registry database. The record is entered on the basis of an application submitted by the registrant to the Registrar.
Registrars process the registrantʹs domain name registration orders through SRS using EPP. The domain can be registered for a period from 1 to 10 years at the Registrar’s discretion, but no more than 10-year period, provided that:
- All necessary contact objects were created in the registry;
- The registered domain name meets the requirements set forth in the second-level domain registration policy in .TATAR gTLD (The registration policy overview is given in the answer to Evaluation Question #18);
- The domain name has not been registered and is not retained in the Reserved Names List;
- The Registrar fulfils all the terms set forth in the agreement with the Registry Operator including, but not limited to, compliance with the technical and administrative policies.
Having met these conditions, the domain name registration shall be carried out by SRS. Information on registered domain names shall be available via WHOIS public server.
Upon a successful domain name registration, the Registrar is charged a fee in the amount defined in RRA.
To manage domain name registration process EPP protocol is in use, as described in the answer to Evaluation Question #25. The service uses the EPP Domain Mapping «create» query command.
2.2. Domain name renewal
Domain name may be renewed for the period of 1 to 10 years, but no more than 10 years Renewal may be carried out only by the Registrar sponsoring the domain name.
Renewal is permitted from the moment of domain name registration in the registry database and through the beginning of the redemption grace period. Where the request for a domain renewal beyond the permitted period has been submitted or where after the renewal for the number of years defined by the Registrar the registration expiration timeline is in excess of 10 years, the request is rejected.
Upon successful completion of the domain renewal the sponsoring Registrar is charged a fee per RRA terms.
The service uses the EPP Domain Mapping «renew» query command.
2.3. Domain Auto-Renewal
When a domain reaches its expiration date the registry will automatically renew the domain for one additional year and charge the sponsoring Registrar. The Registrar has the Auto Renew grace period (0-45 days, depending on the Registrar policy) to delete the domain and receive a refund for the automatic renewal.
2.4. Domain recovery within Redemption Grace period (RGP)
The domain name can be recovered during the Redemption Grace Period in compliance with policies and procedures established in .TATAR gTLD and RFC 3915.
The service uses the EPP Domain Mapping «update» query command with the EPP Extension Redemption Grace Period Mapping «restore»; provided, however, that in the case of (i) Bulk Transfers under Part B of the ICANN Policy on Transfer of Registrations between Registrars and (ii) Large Incidents, Restore may be accomplished by e-mail or fax using a Restore Request Form as specified by Registry Operator .TATAR.
Upon successful recovery of the domain from RGP the sponsoring Registrar of the domain name is charged a domain name recovery fee per RRA terms.
2.5. Domain transfer
Domain transfer is performed by Registrars in compliance with ICANN Inter-Registrar Transfer Policy (IRTP), RRA agreement and .TATAR regulations.
For domain transfer the Registrars use the EPP Domain Mapping «transfer» request or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part.
The financial details of domain transfers are completely described in the answer to Evaluation Question #27.
The detailed restrictions of domain transfers are described in the answer to Evaluation Question #25 and #27.
2.6. Domain deletion
The domain can be deleted by the sponsoring Registrar prior to expiration of the domain registration term or during the Auto-Renew Grace period.
The service uses the EPP Domain Mapping «delete» query command.
The details of domain deletion including financial ones are described in the answer to Evaluation Question #27.
When a domain is deleted, all Host objects for which this domain is the parent domain will also be deleted. The orphan glue record policy is described in the answer to Evaluation Question # 28.
2.7. Transform functions
All services enumerated in this section are non-billable.
The following features allow data within the registry to be manipulated by Registrars:
2.7.1. Update Domain
A Registrar uses the Update Domain service to change attributes of a domain for which it is the sponsoring Registrar. Attributes that can be changed include: the corresponding contacts, nameservers, EPP Domain-related extensions, including DNSSEC, and domain status. The domain name cannot be delegated if less than 2 nameservers are associated with it. The sponsoring Registrar can set EPP-statuses for the domain, which preclude some operations: clientUpdateProhibited disables the domain information update, clientRenewProhibited disables the domain renewal, clientTransferProhibited disables the domain transfer, clientDeleteProhibited disables the domain deletion. Update Domain uses the EPP Domain Mapping «update» command.
2.7.2. Add Nameserver
Registrars use the Add Nameserver service to create a new host object in the registry. Nameservers can only be created by the sponsoring Registrar of the parent domain object. A nameserver can be created with up to 13 IP addresses. Add Nameserver uses the EPP Host Mapping «create» command.
2.7.3. Modify Nameserver
Registrars use the Modify Nameserver service to change the IP addresses associated with a nameserver or change the name or statuses. The modification of a nameserver can only be performed by the sponsoring Registrar of the nameserver. Modify Nameserver uses the EPP Host Mapping «update» command.
2.7.4. Delete Nameserver
Registrars use the Delete Nameserver service to remove a host object from the registry. A Registrar can only delete a nameserver for which it is the sponsoring Registrar. A nameserver can only be deleted if is not associated with any domains in the registry. Delete Nameserver uses the EPP Host Mapping «delete» command.
2.7.5. Add Contact
Registrars use the Add Contact service to create a new contact object in the registry. Add Contact uses the EPP Contact Mapping «create» command.
2.7.6. Modify Contact
Registrars use the Modify Contact service to change the attributes including statuses of a contact object. The modification of a contact can only be performed by the sponsoring Registrar of the contact. Modify Contact uses the EPP Contact Mapping «update» command.
2.7.7. Delete Contact
Registrars use the Delete Contact service to remove a contact object from the registry. A Registrar can only delete a contact for which it is the sponsoring Registrar. A contact can only be deleted if is not associated with any domains in the registry. Delete Contact uses the EPP Contact Mapping «delete» command.
2.7.8. Transfer Contact
Registrars use the Transfer Contact service to change a domainʹs sponsoring Registrar. Transfer Contact uses the EPP Contact Mapping «transfer» transform command. A contact can only be transferred if is not associated with any domains in the registry. The different operations that can be performed using the «transfer» command are: Request, Query, Cancel, Approve, Reject.
2.8. Querying functions
The following query types will be available to Registrars so they can examine information within the registry. All services enumerated in this section are non-billable.
2.8.1. Check Domain
Registrars use the Check Domain service to find out if a domain exists as a valid object in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ to the Check Domain request. Check Domain uses the EPP Domain Mapping «check» command.
2.8.2. Query Domain
Registrars use the Query Domain service to retrieve the domain information of a domain object in the registry. Only the sponsoring Registrar of a domain can retrieve its domain information. Query Domain uses the EPP Domain Mapping «info» command.
2.8.3. Query Domain Transfer Status
Registrars use the Query Domain Transfer Status service to find out the status of a domain transfer. Query Domain Transfer Status uses the EPP Domain Mapping «transfer» query command (while actually initiating a transfer is billable). Please note that this is different from the EPP «transfer» transform command.
2.8.4. Check Nameserver
Registrars use the Check Nameserver service to check to see if a nameserver object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the nameserver requested. Check Nameserver uses the EPP Host Mapping «check» command.
2.8.5. Query Nameserver
Registrars use the Query Nameserver service to retrieve the host objectʹs information for a nameserver. Only the sponsoring Registrar of the nameserver can query for a nameserverʹs information. Query Nameserver uses the EPP Host Mapping «info» command.
2.8.6. Check Contact
Registrars use the Check Contact service to check to see if a contact object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the contact requested. Checking contact existence is a non-billable operation. Check Contact uses the EPP Contact Mapping «check» command.
2.8.7. Query Contact
Registrars use the Query Contact service to retrieve the contact objectʹs information for a contact. Query Contact uses the EPP Contact Mapping «info» command.
2.8.8. Query Contact Transfer Status
Registrars use the Query Contact Transfer Status service to find out the status of a contact transfer. The query for contact transfer status information is a non-billable operation (while actually initiating a transfer is billable). Query Contact Transfer Status uses the EPP Contact Mapping «transfer» query command.
3. DISSEMINATION OF TLD ZONE FILES
All services enumerated in this section are non-billable.
3.1. Zone file generation and publication
Zone file generation constitutes the process of creation of a zone file using the SRS database as an authoritative source of information about registered domains and nameservers associated with them. The zone file is formed on the Primary Database server from the registry database records on schedule.
The zone file is transmitted onto both Hidden Primary DNS Servers through a special procedure which uses checksum verification. Should the checksums of the Primary Database and the Hidden Primary DNS match, the file handling continues, otherwise a zone file backup error message would be formed. Zone file is transmitted via RSYNC over SSH.
In the zone file updates all modifications, additions and deletions of objects made by Registrars in a given 30-minute period are recorded. Incomplete modifications are not recorded into the zone file during its generation, thus ensuring compliance with Specification 10 to Registry Agreement.
Serial numbers are assigned to every generated zone file using methods described in RFC 1982.
For the sake of an extra control during zone file generation special mechanisms are enabled. The number of delegated domains is calculated upon generation. Should the number of delegated domains be down by more than 10% vis-a-vis the value reported under the previous generation, a subsequent zone file processing is not performed and the error message to the operator is generated.
Where a suspicious decrease in number of records is not detected, both Hidden Primary DNS servers are pulled for the latest (=largest) Serial number from the SOA record. One (1) is added to this number and a new Serial number is entered into the formed zone file.
The state of the Hidden Primary DNS servers is monitored constantly to ensure the presence of pivotal sources, such as hard disc space, processor load rate, etc. Where resources have exhausted, a message is formed to notify the operator thereof. For example, where the available hard disc space is down to value under 4 GB an alerting message of approaching the minimum allowable threshold is formed, while where the available disk space is down to less than 2 GB, a message of disc space critical level is formed.
The zone file is generated in the RFC 1035 format in compliance with requirements set forth in Specification 4.
3.2. Zone file distribution
Zone distribution occurs immediately following zone publication on Hidden Primary DNS servers. Zone file being distributed to secondary DNS servers in a secure manner, using data encryption and secure channels. The zone is distributed onto secondary servers with the use of AXFR (RFC 5936) for entire zone file updates. IXFR (RFC 1995) incremental update method is supported and tested but will not be used due to the moderate zone files size for .TATAR TLD. The safeguard from modifications is ensured by using TSIG (RFC 2845). The keys for TSIG are subject to rollover every six months. The secondary servers are configured to accept updates only from Hidden Primary DNS servers.
For the time being the zone update is planned to be carried out by the generation and full zone file unload method. The dynamic updates use has been tested, and, where appropriate (for example, if during a new file generation time becomes unacceptably long), it is possible to switch over to them.
The roll-out of the zone file in DNS system will take 10 minutes or less than that.
Detailed architecture of the Hidden Primary and secondary DNS is described in the answer to the Evaluation Question #35.
3.3. Zone file access
Zone file access is provided according to the requirements listed in gTLD Registry Agreement, Specification 4 (sections 2.1 and 2.2). File format standard is a sub-format of the Master File format as described in section 2.1.4 of the Specification 4. Technical credentials will be implemented according to the requirements of the Specification 4.
3.4. Operations of the registry zone servers
Registry DNS servers, including Hidden Primary and secondary servers operate under FreeBSD with BIND including with the following settings appropriate for TLD zone operator: RECURSION is off, ADDITIONAL-FROM-CACHE off, NOTIFY is off for secondary DNS servers.
To ensure highly redundant DNS service the fifteen (15) geographically distributed DNS nodes with uniformed equipment and software configuration are installed, as described in the answer to Evaluation Question #35. Each DNS node carries two DNS servers (master and stand-by). In addition to BIND the NSD package is installed on stand-by DNS servers.
4. WHOIS SERVICE
TLD .TATAR will use “thick registry” model implying storage of all the information of registered in the registry database objects. The WHOIS service will contain data submitted by Registrars during the registration process. Any changes made to the data by a registrant will be submitted to the registry by the Registrar and will be reflected in the WHOIS, thus providing all interested parties with up-to-date information for every domain name. This WHOIS will be authoritative, consistent and accurate, people do not have to query different Registrars for WHOIS information, as there is one central WHOIS system.
WHOIS will be used to look up records in the registry database. Information about domain, host, contact and registrar objects can be searched using this WHOIS service.
The following WHOIS services are provided:
4.1. WHOIS service available via port 43 in compliance with RFC 3912. Access granted to all Internet users for free.
4.2. Web-based WHOIS service. Service is free and available for all Internet users.
4.3. The extended WHOIS search service is a search of objects by a fuzzy match of individual fields (e.g., domain name, registrant information, nameserver). Access to the service is granted to Registrars under RRA and to other authorized customers under service agreement. Service requires authorization.
4.4. Unlimited access to WHOIS service. Within the frame of RRA the Registrars are granted an unlimited access to WHOIS service via port 43 in order to check the availability of a name for registration. Access is controlled by IP access list, only Registrarʹs IP addresses allowed. Service will be provided for free.
To ensure a stable functioning of the system, technical measures are employed to limit the number of WHOIS queries from a given IP address over a time interval.
Information provided in the frame of the WHOIS service complies with Specification 4 To the Registry Agreement.
More information about WHOIS services is given in the answer to Evaluation Question #26.
5. DNS SECURITY EXTENSIONS
The .TATAR registry will support DNS Security Extensions (DNSSEC) to the extent provided for by RFC 4033-4035, 5155 (NSEC3).
The DNS servers of the registry will correctly handle queries for the sake of validation of accepted data on the queried zone.
The registry will deliver DS records for proper DNSSEC delegation in the root.
The Public key portions of DNSSEC will be announced to the public by Registry Operator, and, at a minimum, will be made available on its website. The DS records necessary for proper DNSSEC delegation will be delivered to the root.
End user applications that are DNSSEC-aware will ask queries of the DNS with a flag set for a signed response. The registry name servers will then respond with the correct response, including the signatures for the requested records. It is up to the end user to validate the signatures returned.
The sponsoring Registrar manages DS records for the domains as per RFC 5910.
The information on signed domains under the Registrar’s management is available to the Registrar among other reports (see the ‘Registrar services’ section).
More details about DNSSEC are in the answer to Evaluation Question # 43.
6. REGISTRAR SERVICES
The enumerated under this section services are delivered to Registrars.
6.1. Registrar accounts management
This service constitutes creation and modification of Registrar accounts. The service includes following operations:
- Creation of the account for the Registrar who has entered into RRA;
- Deletion of the account upon termination of RRA;
- Updating information about Registrars which is not modified other way;
- Updating the operational status of the Registrar’s accounts;
- Provision of a credit to the Registrar and entry of respective modifications into the Registrar’s balance.
6.2. Billing services
The billing subsystem handles all billing events from the registry that are created as part of normal registry operations. This mechanism also handles requests from the Web based Administration Interface. The billing mechanism interfaces with the Registry Operator’s financial system by way of a database interface.
The billing events require an immediate response enabling the registration process to take place. The billing implementation reflects a pre-paid billing model where a balance is debited for each billed event presented.
A negative response is returned by the billing subsystem if there are not sufficient funds available to complete the requested event. An EPP operation that receives a negative response from the billing subsystem will return an error response to the Registrar that initiated the operation.
Each billing system event has a dependency on the registry having done the following:
- Ensured that the Registrar is valid within the described Registrars;
- Ensured that the billing event is fully described with sufficient price information;
- Ensured that there is a balance for any Registrars who require processing for billable events.
The billing events must contain the ʺTransaction IDʺ as outlined in the EPP specification. This enables registry events to be traced in terms of their billing consequences.
The Registry Operator will implement an automatic Threshold Notification process for the Registrars to inform them about their low account balance. As soon as the Registrars balance falls below a pre determined threshold an out-of-band communication (e-mail) would be sent to the Registrars informing them. The Registrars are thus always aware of their low account balance and can make arrangements to transfer additional funds. This prevents the Registrars from losing business due to lack of funds.
The Registry Operator reserves the right to introduce additional fee-based services for Registrars and other users, which are rendered on the basis of an agreement concluded with them. In this regard, if there is a need for the Registry Operator to change the architecture or operation of an existing TLD registry service or introduce a new TLD registry service, there will be notification to ICANN and necessary negotiations in place in accordance with the ICANNʹs Registry Services Evaluation Policy.
6.3. Web-based Administration Interface for Registrar
Each Registrar will be provided with a username⁄password to access a secured website (HTTPS) where it can perform certain functions:
- Change of the password to access the Web-interface;
- Review of information on details of the access to the registry services;
- Receipt of SSL-certificates used to check the access to SRS system;
- Review of reports over a given period, including financial ones;
- Check the account balance;
- Review of the list of domain names registered as of the beginning of the current day;
- The interface will be bi-lingual (Russian and English).
6.4. Operation Test and Evaluation Certification Services
Before a Registrar is allowed to join the live Shared Registry System it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation of a Registrarʹs client system.
6.4.1. Preparations for OT&E Certification
The OT&E certification process begins when a Registrar becomes accredited by ICANN to register names in the .TATAR TLD, at which point an OT&E welcome package will be provided to the Registrar. This package will include information that will assist the Registrar in developing its client application for the Shared Registry System. This package will include the following:
- Username and password to access the Registrar only area of the Registry Operator website.
-OT&E server information and username⁄password for two accounts to access OT&E environment for Registrar client testing. Two accounts due to necessity to test domain transfer functions.
- Instructions on where to download the Registrar Tool Kit.
- Instructions on where to download the documentation for the Registrar Tool Kit.
- Instructions on where to download the EPP specifications.
- Instructions on how to proceed with the OT&E certification process.
- Instructions on how to obtain an SSL certificate from an approved Certificate Authority.
- Instructions on how to provide Registry Operator with the list of subnets that will be used to access the live Shared Registry System.
- Documentation that will explain the tests to be performed during OT&E verification.
The Registrar is responsible for developing the client application that will interface to the registry using the EPP protocol, however the Registry Operator will offer assistance in application development for additional fee. The Registrar Tool Kit will be available to any interested party that would like to develop registrar client applications. A Registrar may opt to develop its application to conform to the EPP specification without the use of the Registrar Tool Kit. This is acceptable as long as the client is able to pass the OT&E certification process.
The registry-registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish this encrypted channel. The username⁄password and subnet list provides additional security as only a valid combination of SSL certificate; username⁄password and subnet will be allowed to access the live SRS.
During development of the client-side, the Registrar has access to .TATAR registry OT&E environment. In the OT&E environment, the Registrar may test the operation of its software to verify the correct handling of EPP commands and their responses. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live SRS. Registrars will continue to have access to the OT&E environment after certification, so that they may continue to test their software systems.
When a Registrar has completed the testing of its client systems and would like to proceed with OT&E certification, it will contact Registry Operator to schedule a time slot for certification tests.
6.4.2. Post OT&E Certification
All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those Registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.
Upon successful OT&E certification, the Registrar becomes eligible for operation in the live SRS. A new username⁄password is assigned and the Registry Operator will configure the live system to recognize the SSL certificate, username and subnet blocks for the registrar. The Registrar may start operation when it has satisfied the financial requirements for going live.
The responsibilities of OT&E team include granting of welcome package, responding to Registrars’ questions, verification of test results and providing with report on test conduct. The procedure for issuing welcome package and for results estimation shall be automatized, while responding to questions shall be obligatory for Customer and Technical Support Services Group (see 7.6, ‘Customer and Technical Support Services’). In this way OT&E should not require additional staff units.
6.5. The Registrar Tool Kit
The Registrar Tool Kit (RTK) is a software development kit that will support the development of a registrar software system to perform registration of domain names in the registry using the EPP Protocol. The RTK will consist of software and documentation as described below.
The RTK can be used by the Registrar as a basis for connecting to the testbed environment during OT&E, and can also be used to develop a system for interfacing with the live registry once the Registrar has been certified.
The software will consist of a working Java API and samples that can be used to implement the EPP protocol that is used to communicate between the registry and Registrar.
The documentation will explain to the Registrar the details of the protocol specification. It will describe the commands that need to be sent to the registry in order to support domain registration events, as well as the possible responses that may be returned by the registry. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the registry, will be defined for each possible registration event.
The documentation will also describe the software (mentioned above) that implements the EPP Registry-Registrar protocol. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).
The RTK will remain under development for the term of the Registry Agreement and will provide support for additional features as they become available.
6.6. Customer and Technical Support Services
The Registry Operator will provide complete package of Customer and Technical Support Services for general inquiries and billing related issues as well as operational and technical issues. These services will be dedicated primarily to operational Registrars, although inquiries from potential Registrars, or those in evaluation stages will be supported. Registrars will receive equal levels of support regardless of their location of operations. There will be a sufficient conduit for support escalation to a higher level when necessary. For the unlikely case of service failure, the responsibility matrix and escalation procedures are in place and procedures will be supported by Trouble Ticket Management System, able to act within complete off-line environment as described in the answer to Evaluation Question #39.
6.7. Report Generation
Registry Reports for each Registrar will be generated on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the Registrar is the sponsoring Registrar. The reports are generated as static colon-delimited files and available for download from the registrar Web administration Interface secure website.
6.7.1. Report Types
Two types of reports will be created for each Registrar: Daily Reports and Weekly Reports. These are described below.
6.7.1.1. Daily Reports
(i) Daily Transaction Report: This report includes Addition, Modification, Delete and domain Transfer activity by the Registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated IP address. A transaction ID is included in column 1 to allow unique identification of transactions. Column 2 contains the transaction operation. The content of column 3 and 4 is dependent on the operation according to the following rules:
Operation || Column 3 || Column 4
==================================================================
ADD_DOMAIN || Domain Name || Server Name
MOD_DOMAIN || Domain Name || Server Name
DEL_DOMAIN || Domain Name || Server Name
ADD_NAMESERVER || IP Address || Server Name
MOD_NAMESERVER || IP Address || Server Name
DEL_NAMESERVER || IP Address || Server Name
TRANSFER_DOMAIN || Domain Name || Null
==================================================================
Column 5 contains the transaction date (as illustrated in the example below).
For example,
1234567:ADD_DOMAIN:EXAMPLE1.TATAR:NS1.EXAMPLE1.TATAR:2001.07.01.11.12.54
1234568:ADD_DOMAIN:EXAMPLE1.TATAR:NS2.EXAMPLE1.TATAR:2001.07.01.11.12.54
1235789:ADD_DOMAIN:EXAMPLE2.TATAR:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.30
1235790:ADD_DOMAIN:EXAMPLE2.TATAR:NS2.EXAMPLE1.TATAR:2001.07.01.11.13.30
1245734:ADD_NAMESERVER:111.222.123.211:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.50
1245735:ADD_NAMESERVER:111.222.123.212:NS1.EXAMPLE1.TATAR:2001.07.01.11.13.50
2341413:TRANSFER_DOMAIN:TEST.TATAR::2001.07.01.11.14.31
(ii) Daily Transfer Reports: This report includes gaining and losing transfer activity. There are two separate reports for transfers:
- Gaining Transfer Report: indicates domains transferred to the Registrar (ʺGaining Registrarʺ).
- Losing Transfer Report: indicates domains transferred away from the Registrar (ʺLosing Registrarʺ).
- The Transfer Reports will have the following fields: Gaining Registrar name, Domain name, Losing Registrar name, Date⁄time of transfer request, Status (one of ACK, NACK or PENDING), Date⁄time of ACK⁄NACK. The value of Date⁄time of ACK⁄NACK will be NULL if the status is PENDING. For example:
Registrar A, Inc.:EXAMPLE1.TATAR:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
Registrar A, Inc.:TEST.TATAR:Registrar B Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
Registrar A, Inc.:TEST2.TATAR:Registrar B Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39
6.7.1.2. Weekly Reports
Weekly Domain Report: Lists all domain names currently sponsored by the Registrar. The domain is listed once with each current status and associated name server. For example:
EXAMPLE1.TATAR:ACTIVE:NS1.EXAMPLE1.TATAR
EXAMPLE1.TATAR:ACTIVE:NS2.EXAMPLE1.TATAR
EXAMPLE2.TATAR:ACTIVE:NS1.EXAMPLE1.TATAR
EXAMPLE2.TATAR:ACTIVE:NS2.EXAMPLE1.TATAR
TEST.TATAR:HOLD:NS1.TEST.TATAR
TEST.TATAR:HOLD:NS2.TEST.TATAR
HAPPY.TATAR:ACTIVE:
Weekly Nameserver Report: Lists all nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated IP address. For example:
NS1.EXAMPLE1.TATAR:111.222.123.211
NS1.EXAMPLE1.TATAR:111.222.123.212
NS1.TEST.TATAR:123.14.2.4
Signed Domain names that enumerates which domain names are signed, along with their expiration time stamp.
DOMAIN1.TATAR: 2013.07.03.04.23.12
DOMAIN2.TATAR: 2013.05.04.05.27.43
Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated domain name.
NS1.EXAMPLE1.TATAR:EXAMPLE1.TATAR
NS1.EXAMPLE1.TATAR:EXAMPLE2.TATAR
NS2.EXAMPLE1.TATAR:EXAMPLE1.TATAR
NS2.EXAMPLE1.TATAR:EXAMPLE2.TATAR
NS1.TEST.TATAR:TEST.TATAR
NS2.TEST.TATAR:TEST.TATAR
6.7.2. Report Frequency
Daily reports will be generated every day at 00:00 UTC and contain Registrar activity for the previous day.
Weekly reports will be generated on Sunday at 00:00 UTC and contain Registrar activity for the previous week.
6.7.3. Storage
Daily reports are maintained for each Registrar for seven days. Daily reports older than seven days will be removed.
Weekly reports are maintained for each Registrar for four weeks. Weekly reports older than four weeks will be removed.
6.7.4. Report Distribution
Registrar reports shall be available for download via a Reports section in the registrar Web administrative interface. Each Registrar will have secure, password-protected access to the Registrar administrative interface. A given Registrar will only have access to his own reports.
6.8. Registrar-Registry Synchronization
There are two methods available for the Registrar to synchronize data with the authoritative-source registry.
6.8.1. Bulk Synchronization
A Registrar may request a data file containing all domains registered by that Registrar, within a certain time interval. The data file will be generated and made available for download using a secure Web server. The data file will be a comma delimited file that contains all domains the Registrar has registered in the time period requested - including all associated host (nameserver) and contact information.
6.8.2. Single object synchronization via EPP
A Registrar can, at any time, use the EPP «info» command to obtain definitive data from the registry, for a known object: including domains, hosts (nameservers) and contacts. There is no need to contact registry support for this synchronization method.
6.8.3 Registry Notifications
In case of any changes in object state is provided by the Registry Operator, the notification describing changes is sent to the Registrar sponsoring changed object. The notification can be retrieved using EPP «poll» command.
6.9. Bulk Transfers
According to Inter-Registrar Transfer Policy ICANN may request Registry Operator to perform a bulk transfer of all registered objects from one Registrar to another Registrar. The bulk transfer will not be performed with the use of EPP commands. Instead it will be performed as a bulk database operation of the necessary fields for all objects currently sponsored by the losing Registrar. A complete log will be kept of this transaction for auditing purposes.
6.10. NTP service
The registry grants Registrars with access to clock synchronisation service used in operation of the registry. Thereat each Registrar specifies a list of IP addresses whence the access will be performed. The following NTP servers are used as a trusted clock source: ntp.ix.ru and ntp-spb.tcinet.ru.
7. END-USER SERVICES
The Registry Operator will operate a Name Watch Service available for legitimate subscribers thereto. The service will provide an indispensable tool to receive update notifications of new registrations containing a certain combination of characters which may raise the subscriber’s concern. The service is for information purposes only.
| gTLD | Full Legal Name | E-mail suffix | Detail | | .skolkovo | Fund for Development of the Center for Elaboration and Commercialization of New Technologies | cctld.ru | View |
1. INTRODUCTION
The Applicant plans to provide the following services:
a) Domain Name Registration Services.
b) Dissemination of TLD zone files
c) Dissemination of contact or other information concerning domain name registrations (WHOIS).
d) DNS Security Extensions (DNSSEC)
e) Registrar services.
f) End-user services.
The registry services will be implemented with regard for stability and safety requirements set forth in ICANN policies.
To maintain the stable environment, registry services will be provided in accordance with applicable standards and recommendations of IETF and best practices whose value was proven by international Internet community and ICANN.
For safety reasons the access to services for registrars and other users is limited by using technical means, such as access list management, number of requests limit assignment, usage of cryptography and management of login names and passwords. Detailed security policies are described in the answer to Evaluation Question #30 (b).
The second-level domain name registration, as well as receipt or update of registry data are implemented in compliance with RFC 5730-5734, 3915 and do not affect the bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.
DNS services comply with the officially applied standards (RFC 1035 and Specification 4 to the Registry Agreement (hereinafter – Specification 4)) and, due to employment of a distributed system, they do not create conditions which negatively impact bandwidth, response time, data consistency or coherence of answers transferred to Internet servers or end-user systems.
WHOIS service is implemented in compliance with Specification 4 and RFC 3912.
DNSSEC service is implemented in compliance with RFC 4033-4035, 5155, 5910
2. DOMAIN NAME REGISTRATION SERVICES
A full range of standard domain registration services will be provided. All this services are made available for any ICANN-accredited registrar who has entered into Registry-Registrar Agreement (RRA) with Registry Operator (hereinafter – Registrar).
The services enumerated in this section cannot be provided for an object that has EPP status prohibiting the operation. The Registrar sponsoring object cannot override the restriction set by the Registry. The complete description of statuses is provided in RFC 5730-5733.
2.1. Domain name registration
Domain name registration service consists of the insertion of the domain name, registration period, registrant and registrant’s contacts, NS records into the registry database. The record is entered on the basis of an application submitted by the registrant to the Registrar.
Registrars process the registrantʹs domain name registration orders through SRS using EPP. The domain can be registered for a period from 1 to 10 years at the Registrar’s discretion, but no more than 10-year period, provided that:
- All necessary contact objects were created in the registry;
- The registered domain name meets the requirements set forth in the second-level domain registration policy in .SKOLKOVO gTLD ( The registration policy overview is given in the answer to Evaluation Question #18);
- The domain name has not been registered and is not retained in the Reserved Names List;
- The Registrar fulfils all the terms set forth in the agreement with the Registry Operator including, but not limited to, compliance with the technical and administrative policies.
Having met these conditions, the domain name registration shall be carried out by SRS. Information on registered domain names shall be available via WHOIS public server.
Upon a successful domain name registration, the Registrar is charged a fee in the amount defined in RRA.
To manage domain name registration process EPP protocol is in use, as described in the answer to Evaluation Question #25. The service uses the EPP Domain Mapping «create» query command.
2.2. Domain name renewal
Domain name may be renewed for the period of 1 to 10 years, but no more than 10 years Renewal may be carried out only by the Registrar sponsoring the domain name.
Renewal is permitted from the moment of domain name registration in the registry database and through the beginning of the redemption grace period. Where the request for a domain renewal beyond the permitted period has been submitted or where after the renewal for the number of years defined by the Registrar the registration expiration timeline is in excess of 10 years, the request is rejected.
Upon successful completion of the domain renewal the sponsoring Registrar is charged a fee per RRA terms.
The service uses the EPP Domain Mapping «renew» query command.
2.3. Domain Auto-Renewal
When a domain reaches its expiration date the registry will automatically renew the domain for one additional year and charge the sponsoring Registrar. The Registrar has the Auto Renew grace period (0-45 days, depending on the Registrar policy) to delete the domain and receive a refund for the automatic renewal.
2.4. Domain recovery within Redemption Grace period (RGP)
The domain name can be recovered during the Redemption Grace Period in compliance with policies and procedures established in .SKOLKOVO gTLD and RFC 3915.
The service uses the EPP Domain Mapping «update» query command with the EPP Extension Redemption Grace Period Mapping «restore»; provided, however, that in the case of (i) Bulk Transfers under Part B of the ICANN Policy on Transfer of Registrations between Registrars and (ii) Large Incidents, Restore may be accomplished by e-mail or fax using a Restore Request Form as specified by Registry Operator .SKOLKOVO.
Upon successful recovery of the domain from RGP the sponsoring Registrar of the domain name is charged a domain name recovery fee per RRA terms.
2.5. Domain transfer
Domain transfer is performed by Registrars in compliance with ICANN Inter-Registrar Transfer Policy (IRTP), RRA agreement and .SKOLKOVO regulations.
For domain transfer the Registrars use the EPP Domain Mapping «transfer» request or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part.
The financial details of domain transfers are completely described in the answer to Evaluation Question #27.
The detailed restrictions of domain transfers are described in the answer to Evaluation Question #25 and #27.
2.6. Domain deletion
The domain can be deleted by the sponsoring Registrar prior to expiration of the domain registration term or during the Auto-Renew Grace period.
The service uses the EPP Domain Mapping «delete» query command.
The details of domain deletion including financial ones are described in the answer to Evaluation Question #27.
When a domain is deleted, all Host objects for which this domain is the parent domain will also be deleted. The orphan glue record policy is described in the answer to Evaluation Question #28.
2.7. Transform functions
All services enumerated in this section are non-billable.
The following features allow data within the registry to be manipulated by Registrars:
2.7.1. Update Domain
A Registrar uses the Update Domain service to change attributes of a domain for which it is the sponsoring Registrar. Attributes that can be changed include: the corresponding contacts, nameservers, EPP Domain-related extensions, including DNSSEC, and domain status. The domain name cannot be delegated if less than 2 nameservers are associated with it. The sponsoring Registrar can set EPP-statuses for the domain, which preclude some operations: clientUpdateProhibited disables the domain information update, clientRenewProhibited disables the domain renewal, clientTransferProhibited disables the domain transfer, clientDeleteProhibited disables the domain deletion. Update Domain uses the EPP Domain Mapping «update» command.
2.7.2. Add Nameserver
Registrars use the Add Nameserver service to create a new host object in the registry. Nameservers can only be created by the sponsoring Registrar of the parent domain object. A nameserver can be created with up to 13 IP addresses. Add Nameserver uses the EPP Host Mapping «create» command.
2.7.3. Modify Nameserver
Registrars use the Modify Nameserver service to change the IP addresses associated with a nameserver or change the name or statuses. The modification of a nameserver can only be performed by the sponsoring Registrar of the nameserver. Modify Nameserver uses the EPP Host Mapping «update» command.
2.7.4. Delete Nameserver
Registrars use the Delete Nameserver service to remove a host object from the registry. A Registrar can only delete a nameserver for which it is the sponsoring Registrar. A nameserver can only be deleted if is not associated with any domains in the registry. Delete Nameserver uses the EPP Host Mapping «delete» command.
2.7.5. Add Contact
Registrars use the Add Contact service to create a new contact object in the registry. Add Contact uses the EPP Contact Mapping «create» command.
2.7.6. Modify Contact
Registrars use the Modify Contact service to change the attributes including statuses of a contact object. The modification of a contact can only be performed by the sponsoring Registrar of the contact. Modify Contact uses the EPP Contact Mapping «update» command.
2.7.7. Delete Contact
Registrars use the Delete Contact service to remove a contact object from the registry. A Registrar can only delete a contact for which it is the sponsoring Registrar. A contact can only be deleted if is not associated with any domains in the registry. Delete Contact uses the EPP Contact Mapping «delete» command.
2.7.8. Transfer Contact
Registrars use the Transfer Contact service to change a domainʹs sponsoring Registrar. Transfer Contact uses the EPP Contact Mapping «transfer» transform command. A contact can only be transferred if is not associated with any domains in the registry. The different operations that can be performed using the «transfer» command are: Request, Query, Cancel, Approve, Reject.
2.8. Querying functions
The following query types will be available to Registrars so they can examine information within the registry. All services enumerated in this section are non-billable.
2.8.1. Check Domain
Registrars use the Check Domain service to find out if a domain exists as a valid object in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ to the Check Domain request. Check Domain uses the EPP Domain Mapping «check» command.
2.8.2. Query Domain
Registrars use the Query Domain service to retrieve the domain information of a domain object in the registry. Only the sponsoring Registrar of a domain can retrieve its domain information. Query Domain uses the EPP Domain Mapping «info» command.
2.8.3. Query Domain Transfer Status
Registrars use the Query Domain Transfer Status service to find out the status of a domain transfer. Query Domain Transfer Status uses the EPP Domain Mapping «transfer» query command (while actually initiating a transfer is billable). Please note that this is different from the EPP «transfer» transform command.
2.8.4. Check Nameserver
Registrars use the Check Nameserver service to check to see if a nameserver object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the nameserver requested. Check Nameserver uses the EPP Host Mapping «check» command.
2.8.5. Query Nameserver
Registrars use the Query Nameserver service to retrieve the host objectʹs information for a nameserver. Only the sponsoring Registrar of the nameserver can query for a nameserverʹs information. Query Nameserver uses the EPP Host Mapping «info» command.
2.8.6. Check Contact
Registrars use the Check Contact service to check to see if a contact object exists in the registry. The registry will return a result of ʺknownʺ or ʺunknownʺ for the contact requested. Checking contact existence is a non-billable operation. Check Contact uses the EPP Contact Mapping «check» command.
2.8.7. Query Contact
Registrars use the Query Contact service to retrieve the contact objectʹs information for a contact. Query Contact uses the EPP Contact Mapping «info» command.
2.8.8. Query Contact Transfer Status
Registrars use the Query Contact Transfer Status service to find out the status of a contact transfer. The query for contact transfer status information is a non-billable operation (while actually initiating a transfer is billable). Query Contact Transfer Status uses the EPP Contact Mapping «transfer» query command.
3. DISSEMINATION OF TLD ZONE FILES
All services enumerated in this section are non-billable.
3.1. Zone file generation and publication
Zone file generation constitutes the process of creation of a zone file using the SRS database as an authoritative source of information about registered domains and nameservers associated with them. The zone file is formed on the Primary Database server from the registry database records on schedule.
The zone file is transmitted onto both Hidden Primary DNS Servers through a special procedure which uses checksum verification. Should the checksums of the Primary Database and the Hidden Primary DNS match, the file handling continues, otherwise a zone file backup error message would be formed. Zone file is transmitted via RSYNC over SSH.
In the zone file updates all modifications, additions and deletions of objects made by Registrars in a given 30-minute period are recorded. Incomplete modifications are not recorded into the zone file during its generation, thus ensuring compliance with Specification 10 to Registry Agreement.
Serial numbers are assigned to every generated zone file using methods described in RFC 1982.
For the sake of an extra control during zone file generation special mechanisms are enabled. The number of delegated domains is calculated upon generation. Should the number of delegated domains be down by more than 10% vis-a-vis the value reported under the previous generation, a subsequent zone file processing is not performed and the error message to the operator is generated.
Where a suspicious decrease in number of records is not detected, both Hidden Primary DNS servers are pulled for the latest (=largest) Serial number from the SOA record. One (1) is added to this number and a new Serial number is entered into the formed zone file.
The state of the Hidden Primary DNS servers is monitored constantly to ensure the presence of pivotal sources, such as hard disc space, processor load rate, etc. Where resources have exhausted, a message is formed to notify the operator thereof. For example, where the available hard disc space is down to value under 4 GB an alerting message of approaching the minimum allowable threshold is formed, while where the available disk space is down to less than 2 GB, a message of disc space critical level is formed.
The zone file is generated in the RFC 1035 format in compliance with requirements set forth in Specification 4.
3.2. Zone file distribution
Zone distribution occurs immediately following zone publication on Hidden Primary DNS servers. Zone file being distributed to secondary DNS servers in a secure manner, using data encryption and secure channels. The zone is distributed onto secondary servers with the use of AXFR (RFC 5936) for entire zone file updates. IXFR (RFC 1995) incremental update method is supported and tested but will not be used due to the moderate zone files size for .SKOLKOVO TLD. The safeguard from modifications is ensured by using TSIG (RFC 2845). The keys for TSIG are subject to rollover every six months. The secondary servers are configured to accept updates only from Hidden Primary DNS servers.
For the time being the zone update is planned to be carried out by the generation and full zone file unload method. The dynamic updates use has been tested, and, where appropriate (for example, if during a new file generation time becomes unacceptably long), it is possible to switch over to them.
The roll-out of the zone file in DNS system will take 10 minutes or less than that.
Detailed architecture of the Hidden Primary and secondary DNS is described in the answer to the Evaluation Question #35.
3.3. Zone file access
Zone file access is provided according to the requirements listed in gTLD Registry Agreement, Specification 4 (sections 2.1 and 2.2). File format standard is a sub-format of the Master File format as described in section 2.1.4 of the Specification 4. Technical credentials will be implemented according to the requirements of the Specification 4.
3.4. Operations of the registry zone servers
Registry DNS servers, including Hidden Primary and secondary servers operate under FreeBSD with BIND including with the following settings appropriate for TLD zone operator: RECURSION is off, ADDITIONAL-FROM-CACHE off, NOTIFY is off for secondary DNS servers.
To ensure highly redundant DNS service the fifteen (15) geographically distributed DNS nodes with uniformed equipment and software configuration are installed, as described in the answer to Evaluation Question #35. Each DNS node carries two DNS servers (master and stand-by). In addition to BIND the NSD package is installed on stand-by servers.
4. WHOIS SERVICE
TLD .SKOLKOVO will use “thick registry” model implying storage of all the information of registered in the registry database objects. The WHOIS service will contain data submitted by Registrars during the registration process. Any changes made to the data by a registrant will be submitted to the registry by the Registrar and will be reflected in the WHOIS, thus providing all interested parties with up-to-date information for every domain name. This WHOIS will be authoritative, consistent and accurate, people do not have to query different Registrars for WHOIS information, as there is one central WHOIS system.
WHOIS will be used to look up records in the registry database. Information about domain, host, contact and registrar objects can be searched using this WHOIS service.
The following WHOIS services are provided:
4.1. WHOIS service available via port 43 in compliance with RFC 3912. Access granted to all Internet users for free.
4.2. Web-based WHOIS service. Service is free and available for all Internet users.
4.3. The extended WHOIS search service is a search of objects by a fuzzy match of individual fields (e.g., domain name, registrant information, nameserver). Access to the service is granted to Registrars under RRA and to other authorized customers under service agreement. Service requires authorization.
4.4. Unlimited access to WHOIS service. Within the frame of RRA the Registrars are granted an unlimited access to WHOIS service via port 43 in order to check the availability of a name for registration. Access is controlled by IP access list, only Registrarʹs IP addresses allowed. Service will be provided for free.
To ensure a stable functioning of the system, technical measures are employed to limit the number of WHOIS queries from a given IP address over a time interval.
Information provided in the frame of the WHOIS service complies with Specification 4 to the Registry Agreement.
More information about WHOIS services is given in the answer to Evaluation Question #26.
5. DNS SECURITY EXTENSIONS
The .SKOLKOVO registry will support DNS Security Extensions (DNSSEC) to the extent provided for by RFC 4033-4035, 5155 (NSEC3).
The DNS servers of the registry will correctly handle queries for the sake of validation of accepted data on the queried zone.
The registry will deliver DS records for proper DNSSEC delegation in the root.
The Public key portions of DNSSEC will be announced to the public by Registry Operator, and, at a minimum, will be made available on its website. The DS records necessary for proper DNSSEC delegation will be delivered to the root.
End user applications that are DNSSEC-aware will ask queries of the DNS with a flag set for a signed response. The registry name servers will then respond with the correct response, including the signatures for the requested records. It is up to the end user to validate the signatures returned.
The sponsoring Registrar manages DS records for the domains as per RFC 5910.
The information on signed domains under the Registrar’s management is available to the Registrar among other reports (see the ‘Registrar services’ section).
More details about DNSSEC are in the answer to Evaluation Question # 43.
6. REGISTRAR SERVICES
The enumerated under this section services are delivered to Registrars.
6.1. Registrar accounts management
This service constitutes creation and modification of Registrar accounts. The service includes following operations:
- Creation of the account for the Registrar who has entered into RRA;
- Deletion of the account upon termination of RRA;
- Updating information about Registrars which is not modified other way;
- Updating the operational status of the Registrar’s accounts;
- Provision of a credit to the Registrar and entry of respective modifications into the Registrar’s balance.
6.2. Billing services
The billing subsystem handles all billing events from the registry that are created as part of normal registry operations. This mechanism also handles requests from the Web based Administration Interface. The billing mechanism interfaces with the Registry Operator’s financial system by way of a database interface.
The billing events require an immediate response enabling the registration process to take place. The billing implementation reflects a pre-paid billing model where a balance is debited for each billed event presented.
A negative response is returned by the billing subsystem if there are not sufficient funds available to complete the requested event. An EPP operation that receives a negative response from the billing subsystem will return an error response to the Registrar that initiated the operation.
Each billing system event has a dependency on the registry having done the following:
- Ensured that the Registrar is valid within the described Registrars;
- Ensured that the billing event is fully described with sufficient price information;
- Ensured that there is a balance for any Registrars who require processing for billable events.
The billing events must contain the ʺTransaction IDʺ as outlined in the EPP specification. This enables registry events to be traced in terms of their billing consequences.
The Registry Operator will implement an automatic Threshold Notification process for the Registrars to inform them about their low account balance. As soon as the Registrars balance falls below a pre determined threshold an out-of-band communication (e-mail) would be sent to the Registrars informing them. The Registrars are thus always aware of their low account balance and can make arrangements to transfer additional funds. This prevents the Registrars from losing business due to lack of funds.
The Registry Operator reserves the right to introduce additional fee-based services for Registrars and other users, which are rendered on the basis of an agreement concluded with them. In this regard, if there is a need for the Registry Operator to change the architecture or operation of an existing TLD registry service or introduce a new TLD registry service, there will be notification to ICANN and necessary negotiations in place in accordance with the ICANNʹs Registry Services Evaluation Policy.
6.3. Web-based Administration Interface for Registrar
Each Registrar will be provided with a username⁄password to access a secured web-site (HTTPS) where it can perform certain functions:
- Change of the password to access the Web-interface;
- Review of information on details of the access to the registry services;
- Receipt of SSL-certificates used to check the access to SRS system;
- Review of reports over a given period, including financial ones;
- Check the account balance;
- Review of the list of domain names registered as of the beginning of the current day
- The interface will be bi-lingual (Russian and English).
6.4. Operation Test and Evaluation Certification Services
Before a Registrar is allowed to join the live Shared Registry System it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification is to verify the correct operation of a Registrarʹs client system.
6.4.1. Preparations for OT&E Certification
The OT&E certification process begins when a Registrar becomes accredited by ICANN to register names in the .SKOLKOVO TLD, at which point an OT&E welcome package will be provided to the Registrar. This package will include information that will assist the Registrar in developing its client application for the Shared Registry System. This package will include the following:
- Username and password to access the Registrar only area of the Registry Operator web site.
- OT&E server information and username⁄password for two accounts to access OT&E environment for Registrar client testing. Two accounts due to necessity to test domain transfer functions.
- Instructions on where to download the Registrar Tool Kit.
- Instructions on where to download the documentation for the Registrar Tool Kit.
- Instructions on where to download the EPP specifications.
- Instructions on how to proceed with the OT&E certification process.
- Instructions on how to obtain an SSL certificate from an approved Certificate Authority.
- Instructions on how to provide Registry Operator with the list of subnets that will be used to access the live Shared Registry System.
- Documentation that will explain the tests to be performed during OT&E verification.
The Registrar is responsible for developing the client application that will interface to the registry using the EPP protocol, however the Registry Operator will offer assistance in application development for additional fee. The Registrar Tool Kit will be available to any interested party that would like to develop registrar client applications. A Registrar may opt to develop its application to conform to the EPP specification without the use of the Registrar Tool Kit. This is acceptable as long as the client is able to pass the OT&E certification process.
The registry-registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish this encrypted channel. The username⁄password and subnet list provides additional security as only a valid combination of SSL certificate; username⁄password and subnet will be allowed to access the live SRS.
During development of the client-side, the Registrar has access to .SKOLKOVO registry OT&E environment. In the OT&E environment, the Registrar may test the operation of its software to verify the correct handling of EPP commands and their responses. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live SRS. Registrars will continue to have access to the OT&E environment after certification, so that they may continue to test their software systems.
When a Registrar has completed the testing of its client systems and would like to proceed with OT&E certification, it will contact Registry Operator to schedule a time slot for certification tests.
6.4.2. Post OT&E Certification
All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those Registrars that failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.
Upon successful OT&E certification, the Registrar becomes eligible for operation in the live SRS. A new username⁄password is assigned and the Registry Operator will configure the live system to recognize the SSL certificate, username and subnet blocks for the registrar. The Registrar may start operation when it has satisfied the financial requirements for going live.
The responsibilities of OT&E team include granting of welcome package, responding to Registrars’ questions, verification of test results and providing with report on test conduct. The procedure for issuing welcome package and for results estimation shall be automatized, while responding to questions shall be obligatory for Customer and Technical Support Services Group (see 7.6, ‘Customer and Technical Support Services’). In this way OT&E should not require additional staff units.
6.5. The Registrar Tool Kit
The Registrar Tool Kit (RTK) is a software development kit that will support the development of a registrar software system to perform registration of domain names in the registry using the EPP Protocol. The RTK will consist of software and documentation as described below.
The RTK can be used by the Registrar as a basis for connecting to the Test bed environment during OT&E, and can also be used to develop a system for interfacing with the live registry once the Registrar has been certified.
The software will consist of a working Java API and samples that can be used to implement the EPP protocol that is used to communicate between the registry and Registrar.
The documentation will explain to the Registrar the details of the protocol specification. It will describe the commands that need to be sent to the registry in order to support domain registration events, as well as the possible responses that may be returned by the registry. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the registry, will be defined for each possible registration event.
The documentation will also describe the software (mentioned above) that implements the EPP Registry-Registrar protocol. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).
The RTK will remain under development for the term of the Registry Agreement and will provide support for additional features as they become available.
6.6. Customer and Technical Support Services
The Registry Operator will provide complete package of Customer and Technical Support Services for general inquiries and billing related issues as well as operational and technical issues. These services will be dedicated primarily to operational Registrars, although inquiries from potential Registrars, or those in evaluation stages will be supported. Registrars will receive equal levels of support regardless of their location of operations. There will be a sufficient conduit for support escalation to a higher level when necessary. For the unlikely case of service failure, the responsibility matrix and escalation procedures are in place and procedures will be supported by Trouble Ticket Management System, able to act within complete off-line environment as described in the answer to Evaluation Question #39.
6.7. Report Generation
Registry Reports for each Registrar will be generated on a daily and weekly basis. These reports will contain domains, nameservers and contacts for which the Registrar is the sponsoring Registrar. The reports are generated as static colon-delimited files and available for download from the registrar Web administration Interface secure web site.
6.7.1. Report Types
Two types of reports will be created for each Registrar: Daily Reports and Weekly Reports. These are described below.
6.7.1.1. Daily Reports
(i) Daily Transaction Report: This report includes Addition, Modification, Delete and domain Transfer activity by the Registrar. Domain operations produce one row for each associated nameserver. Nameserver operations produce one row for each associated IP address. A transaction ID is included in column 1 to allow unique identification of transactions. Column 2 contains the transaction operation. The content of column 3 and 4 is dependent on the operation according to the following rules:
Operation || Column 3 || Column 4
==================================================================
ADD_DOMAIN || Domain Name || Server Name
MOD_DOMAIN || Domain Name || Server Name
DEL_DOMAIN || Domain Name || Server Name
ADD_NAMESERVER || IP Address || Server Name
MOD_NAMESERVER || IP Address || Server Name
DEL_NAMESERVER || IP Address || Server Name
TRANSFER_DOMAIN || Domain Name || Null
==================================================================
Column 5 contains the transaction date (as illustrated in the example below).
For example,
1234567:ADD_DOMAIN:EXAMPLE1.SKOLKOVO:NS1.EXAMPLE1.SKOLKOVO:2001.07.01.11.12.54
1234568:ADD_DOMAIN:EXAMPLE1.SKOLKOVO:NS2.EXAMPLE1.SKOLKOVO:2001.07.01.11.12.54
1235789:ADD_DOMAIN:EXAMPLE2.SKOLKOVO:NS1.EXAMPLE1.SKOLKOVO:2001.07.01.11.13.30
1235790:ADD_DOMAIN:EXAMPLE2.SKOLKOVO:NS2.EXAMPLE1.SKOLKOVO:2001.07.01.11.13.30
1245734:ADD_NAMESERVER:111.222.123.211:NS1.EXAMPLE1.SKOLKOVO:2001.07.01.11.13.50
1245735:ADD_NAMESERVER:111.222.123.212:NS1.EXAMPLE1.SKOLKOVO:2001.07.01.11.13.50
2341413:TRANSFER_DOMAIN:TEST.SKOLKOVO::2001.07.01.11.14.31
(ii) Daily Transfer Reports: This report includes gaining and losing transfer activity. There are two separate reports for transfers:
- Gaining Transfer Report: indicates domains transferred to the Registrar (ʺGaining Registrarʺ).
- Losing Transfer Report: indicates domains transferred away from the Registrar (ʺLosing Registrarʺ).
- The Transfer Reports will have the following fields: Gaining Registrar name, Domain name, Losing Registrar name, Date⁄time of transfer request, Status (one of ACK, NACK or PENDING), Date⁄time of ACK⁄NACK. The value of Date⁄time of ACK⁄NACK will be NULL if the status is PENDING. For example:
Registrar A, Inc.:EXAMPLE1.SKOLKOVO:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
Registrar A, Inc.:TEST.SKOLKOVO:Registrar B Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
Registrar A, Inc.:TEST2.SKOLKOVO:Registrar B Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39
6.7.1.2. Weekly Reports
Weekly Domain Report: Lists all domain names currently sponsored by the Registrar. The domain is listed once with each current status and associated name server. For example:
EXAMPLE1.SKOLKOVO:ACTIVE:NS1.EXAMPLE1.SKOLKOVO
EXAMPLE1.SKOLKOVO:ACTIVE:NS2.EXAMPLE1.SKOLKOVO
EXAMPLE2.SKOLKOVO:ACTIVE:NS1.EXAMPLE1.SKOLKOVO
EXAMPLE2.SKOLKOVO:ACTIVE:NS2.EXAMPLE1.SKOLKOVO
TEST.SKOLKOVO:HOLD:NS1.TEST.SKOLKOVO
TEST.SKOLKOVO:HOLD:NS2.TEST.SKOLKOVO
HAPPY.SKOLKOVO:ACTIVE:
Weekly Nameserver Report: Lists all nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated IP address. For example:
NS1.EXAMPLE1.SKOLKOVO:111.222.123.211
NS1.EXAMPLE1.SKOLKOVO:111.222.123.212
NS1.TEST.SKOLKOVO:123.14.2.4
Signed Domain names that enumerates which domain names are signed, along with their expiration time stamp.
DOMAIN1.SKOLKOVO: 2013.07.03.04.23.12
DOMAIN2.SKOLKOVO: 2013.05.04.05.27.43
Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on nameservers currently sponsored by the Registrar. The nameserver is listed once with each associated domain name.
NS1.EXAMPLE1.SKOLKOVO:EXAMPLE1.SKOLKOVO
NS1.EXAMPLE1.SKOLKOVO:EXAMPLE2.SKOLKOVO
NS2.EXAMPLE1.SKOLKOVO:EXAMPLE1.SKOLKOVO
NS2.EXAMPLE1.SKOLKOVO:EXAMPLE2.SKOLKOVO
NS1.TEST.SKOLKOVO:TEST.SKOLKOVO
NS2.TEST.SKOLKOVO:TEST.SKOLKOVO
6.7.2. Report Frequency
Daily reports will be generated every day at 00:00 UTC and contain Registrar activity for the previous day.
Weekly reports will be generated on Sunday at 00:00 UTC and contain Registrar activity for the previous week.
6.7.3. Storage
Daily reports are maintained for each Registrar for seven days. Daily reports older than seven days will be removed.
Weekly reports are maintained for each Registrar for four weeks. Weekly reports older than four weeks will be removed.
6.7.4. Report Distribution
Registrar reports shall be available for download via a Reports section in the registrar Web administrative interface. Each Registrar will have secure, password-protected access to the Registrar administrative interface. A given Registrar will only have access to his own reports.
6.8. Registrar-Registry Synchronization
There are two methods available for the Registrar to synchronize data with the authoritative-source registry.
6.8.1. Bulk Synchronization
A Registrar may request a data file containing all domains registered by that Registrar, within a certain time interval. The data file will be generated and made available for download using a secure Web server. The data file will be a comma delimited file that contains all domains the Registrar has registered in the time period requested - including all associated host (nameserver) and contact information.
6.8.2. Single object synchronization via EPP
A Registrar can, at any time, use the EPP «info» command to obtain definitive data from the registry, for a known object: including domains, hosts (nameservers) and contacts. There is no need to contact registry support for this synchronization method.
6.8.3 Registry Notifications
In case of any changes in object state is provided by the Registry Operator, the notification describing changes is sent to the Registrar sponsoring changed object. The notification can be retrieved using EPP «poll» command.
6.9. Bulk Transfers
According to Inter-Registrar Transfer Policy ICANN may request Registry Operator to perform a bulk transfer of all registered objects from one Registrar to another Registrar. The bulk transfer will not be performed with the use of EPP commands. Instead it will be performed as a bulk database operation of the necessary fields for all objects currently sponsored by the losing Registrar. A complete log will be kept of this transaction for auditing purposes.
6.10. NTP service
The registry grants Registrars with access to clock synchronisation service used in operation of the registry. Thereat each Registrar specifies a list of IP addresses whence the access will be performed. The following NTP servers are used as a trusted clock source: ntp.ix.ru and ntp-spb.tcinet.ru.
7. END-USER SERVICES
The Registry Operator will operate a Name Watch Service available for legitimate subscribers thereto. The service will provide an indispensable tool to receive update notifications of new registrations containing a certain combination of characters which may raise the subscriber’s concern. The service is for information purposes only.