1.   INTRODUCTION

1.1.Terms and abbreviations

·      TLD – Top Level Domain.

·      Domain – area (string) of the domain name hierarchic space on the Internet which is denoted by a unique identifier in the form of domain name.

·      Domain name administration – establishment by the Registrant of the procedure of usage of a domain. The administration right exists due to a domain name registration agreement and remains effective from the moment of registration of the domain name and for the duration of the registration.

·      Domain name registration - procedure of entering a domain name information into the Registry database.

·      Registry Operator – an organization authorized to manage, service and maintain the TLD .ДЕТИ.

·      Registrant – a private individual or a legal entity who/which has entered into a domain name registration agreement with the Registrar and who/which administers this domain.

·      Registrar –a legal entity which has entered into agreement with the TLD Registry Operator to perform registration actions in the Registry on behalf of Registrant.

·      Domain delegation (delegation) — deployment and storage of information about DNS servers of the delegated domains at DNS servers of the top-level domain.

·      Domain name validity period– a time interval during which the domain can be administered by Registrant without an additional extension. The duration of registration is determined by Registrant in accordance with Domain Names Registration Procedure in TLD. ДЕТИ.

·      Domain name registration cancellation –deletion of information about domain name from the Registry database.

·      Subordinate domain (a synonym of the term Child zone) – a fraction of a domain name space in TLD .ДЕТИ for which administrative responsibility has been delegated.

·      Registry Service Provider – a legal entity which supports the functioning of the TLD Registry and the Registration System on the basis of an agreement with the Registry Operator.

·      Registry (a synonym of the term «Main Registry») – is a storage of information which performs regulated by the present document actions with the information stored.

·      Registration system – a hardware-software complex which implements the registrar’s interaction protocol with one or more registries and ensures deployment of main registries in the form of databases, and the functioning of the Internet’s addressing system (DNS).

·      Identifier – a unique sequence of symbols.

·      Object –a structured set of entries in registry database which has an identifier and falls under a certain type.

·      Object attribute – an object’s field wherein the name of the attribute and its value are stored.

·      Object type –a parameter that determinates the object’s designation and procedures which can be exercised with regard to it.

·      Procedure –an action which modifies values of the object’s attributes creates an object in the Registry or deletes an object from the Registry.

·      Object handling – conduct of permitted procedures with regard to an object.

·      Status – is a presentation of an object’s attribute in the form of a specific sequence of symbols, which determines the state of the object.

·      Lifetime Periods – specific periods of pre-set length of storing information about an object, during which the object has certain statuses and certain procedures can be exercised in its regard.

·      DNSSEC - a set of extensions to the DNS protocol, which adds support of origin authentication and examination of the data integrity for the domain names system.

·      KSK (Key Signing Key) – a key to sign the DNSKEY resource records.

·      ZSK (Zone Signing Key) – a key to sign resource records.

·      KSR (Key Signed Request) –a request to sign DNSSEC keys.

·      SKR (Signed Key Response) –a signed set of DNSSEC keys.

 

1.2.Overview

The present document describes main procedures and measures undertaken to implement DNSSEC in the TLD .XN--D1ACJ3B (.ДЕТИ)

1.3.Document name and identification

.XN--D1ACJ3B (.ДЕТИ) DNSSEC Policy and Practice Statement. The present document describes main procedures and measures undertaken to implement DNSSEC in .XN--D1ACJ3B (.ДЕТИ).

1.4.Community and applicability

1.4.1. Registry Operator

The TLD Registry Operator has full powers to develop domain names registration policy in the TLD, including the DNSSEC policy implementation procedures, to operate the KSK, and is responsible for accreditation of Registrars.

The Registry Operator outsources the Registry Service Provider to technically operate the Registry. The Registry Service Provider is responsible for: maintenance of the registry database and SRS in the TLD; validation and processing of DNSSEC data received from a Registrar; formation and signing of resource records in the TLD file; management and operation of the ZSK; and distribution of the TLD signed zone across appropriate DNS servers. The Registry Service Provider is a JSC “The Technical Center of Internet” (TCI) (http://www.tcinet.ru).

1.4.2. Registrar

Registrar is a legal entity accredited by the TLD Registry Operator.  Registrar performs registration activities in the Registry on behalf of Registrant.

1.4.3. Registrant

Registrant is a private individual or a legal entity who/which has entered into a domain name registration agreement with a Registrar and who/which administers that domain name. Registrants of domain names in the TLD introduce necessary changes with the help of Registrars and bear responsibility for the accuracy of their domain zone signing, as well as for the actuality of public keys deployed in the Registry system in the form of DS records according to their needs.

1.4.4. Relying party

The interested parties are participants in the Internet who rely on DNSSEC operation, such as, for instance, validating DNS servers. The interested parties are responsible for configuring and updating relevant public keys with their equipment.

1.4.5. Applicability

The present DNSSEC policy is applied to the .ДЕТИ TLD zone. Applying DNSSEC in child domains does not fall under the scope of the present document and shall be described by Registrants of those domains.

1.5.Specification Administration

This document is subject to revision and updating periodically, if necessary.

1.5.1. Specification administration organization

The Foundation for Network Initiatives "The Smart Internet"

1.5.2. Contact Information

The Foundation for Network Initiatives “The Smart Internet”

Postal address: 8, Zoologicheskaya Str., Moscow, 123242 Russia;

Tel:  +7 (499) 766-74-20.

Web-site: http://www.dotdeti.ru/

E-mail: info@dotdeti.ru

1.5.3. Specification change procedures

Any change to this document shall be prepared by the Registry Service Provider’s authorized staff, cleared by the head of the IT security unit of the Registry Service Provider and approved by the Registry Operator.

 

2.   PUBLICATION AND REPOSITORIES

2.1. Repositories

The Registry Service Provider publishes information pertaining to DNSSEC in the TLD in the respective section of its official website at: http://dotdeti.ru/docs/dnssec/.

The electronic version of the DNSSEC Policy of TLD .ДЕТИ posted at the aforementioned URL is the official version of the document.

2.2.Publication of key signing keys

The Registry Service Provider compiles a DNSSEC chain of trust by publishing public KSKs in the form of a DS record directly in the DNS root zone.

 

3.   OPERATIONAL REQUIREMENTS

3.1.Meaning of domain names

Domain name is a unique identifier, which is assigned to an area (branch) of the hierarchical domain name space on the Internet.

Second level domains in IDN TLD .ДЕТИ shall be registered in compliance with the TLD .ДЕТИ Domain Names Registration Policy (http://dotdeti.ru/docs/rules/).

3.2.Activation of DNSSEC for child zone

To activate DNSSEC in the subordinate domain it is necessary to place at least one DNSKEY record and a corresponding DS record in the TLD Registry. The Registry Service Provider examines the data for accuracy by performing the following checkups: digest algorithm checkup, digest checkup and a key tag checkup.

If the subordinate domain has been delegated and the DS record checkups have been passed successfully, the DS record is published in the DNS, thereby establishing a chain of trust to the child zone.

3.3.Identification and authentication of child zone manager

A reliable identification and authentication of Registrant of the subordinate domain using adequate means or procedures falls under the Registrar’s duties.

3.4. Registration of delegation signer (DS) resource records

The Registry Service Provider accepts DNSKEY records and corresponding DS records from Registrars using the EPP interface. The DS and DNSKEY records must be valid and they should be sent in a format described in RFC 4310. The Registry Database supports DS records generated in accordance with RFC 4034 and RFC 5933.

3.5. Method to prove possession of private key

The Registry Service Provider does not conduct any additional checkups to verify whether the Registrant has a private key. The task of running appropriate checkups is assigned to Registrars.

3.6. Removal of DS resource record

3.6.1.  Who can request removal

It is only Registrant in the subordinate domain or a party officially authorized to represent interests of the Registrant in the subordinate domain who/which may, with the Registrar’s help, to send a request to delete a DS record for that domain.

3.6.2.  Procedure for removal request

Having received a respective request through the EPP interface, the Registry Service Provider deletes a DNSKEY record and a corresponding DS record from the Registry . Deletion of all the DNSKEY records and DS records corresponding to them for the subordinate domain deactivate DNSSEC for that domain.

3.6.3.  Emergency removal request

No stipulation.

 

4.   FACILITY MANAGEMENT AND OPERATIONAL CONTROLS

4.1.Physical Controls

4.1.1. Site location and construction

The Registry Service Provider is in possession of several facilities in Russia’s territory. They include: protected from an unauthorized access cabinets in datacenters, a specially arranged space to conduct procedures at the Registry Service Provider’s HQ and a backup facility in one of datacenters. 

4.1.2. Physical access

There has been arranged restricted access, granted to authorized personnel only, to the Registry Service Provider’s facilities.

4.1.3. Power and air conditioning

All the Registry Service Provider’s facilities are equipped with UPS capabilities and air conditioning systems. The Registry Service Provider’s equipment installed in data processing centers has back-up power supply, if a power failure occurs.

4.1.4. Flooding

The Registry Service Provider has taken reasonable precautions to minimize the impact of water exposure for the equipment.

4.1.5. Fire prevention and protection

All the Registry Service Provider’s facilities have fire detectors and a centralized fire extinguisher system.

4.1.6. Media storage

Critical media are stored in safe boxes, access to which is granted to authorized personnel only.

4.1.7. Waste disposal

Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information are rendered unreadable before disposal.

4.1.8. Off-site backup

The Registry Service Provider performs routine backups of critical system data. Off-site backup media are stored protected from unauthorized access in a physically secure manner at remote location.

4.2. Procedural Controls

4.2.1.  Trusted roles

To operate the private KSK there were created two trusted roles: crypto-officer and crypto-operator

To operate ZSK a trusted role of the Domain Zone Administrator was created

To control progress in exercise of the key procedure the role of Supervisor was created

4.2.2.  Number of persons required per task

The trusted roles of crypto-officer and crypto-operator, each providing for a minimum two authorized persons. Operating the private KSK requires a minimum of two crypto-officers and one crypto-operator.

The trusted role of the domain zone administrator provides for a minimum of two authorized persons. Control and management of ZSKs in a semi-automated mode require at least one authorized person.

The trusted role of Observer provides for a minimum of two authorized persons. Observers ensure transparency of the process and a meticulous observance of procedures in the course of exercise of critical operations with the private KSK.

4.2.3.  Identification and authentication for each role

The trusted roles of crypto-officer and crypto-operator provide for each authorized person having an individual identifier and a password to operate the private KSK.

The trusted role of the domain zone administrator provides for each authorized person having an individual login and password to the DNSSEC control interface.

4.2.4.  Tasks requiring separation of duties

An employee assigned the duty to operate the private KSK may not concurrently hold the functions of crypto-officer and crypto-operator.

4.3.Personnel Controls

4.3.1. Qualifications, experience, and clearance requirements

The aforementioned staff are employed with the Registry Service Provider or individuals specifically approved by the Registry Operator to exercise the role of crypto-officer. The staff that take part in procedures is bound to have expertise in the DNSSEC technology application area.

4.3.2. Background check procedures

All the staff members engaged in operations on maintaining the TLD .ДЕТИ should be familiarized with the security requirements. The security requirements should also be included in staff’s job descriptions. Employees should sign a confidentiality (nondisclosure) agreement.

 

Prospective employees should become subject to background checks. Background checks of prospective full-timers should be conducted once they apply for a job. The following matters should become subject to examination:

1.             positive recommendations in particular in respect to the applicant’s business and personal qualities;

2.             examination of the applicant’s résumé for completeness and accuracy, with a proven educational background and professional qualifications;

3.             an independent check of the authenticity of the identity documents (passport or its equivalent).

4.3.3. Training requirements

Prior to taking the aforementioned roles, newly hired staff should study the internal policy documentation describing the DNSSEC implementation. As well, prior to taking the aforementioned roles, they should participate in key procedures as observers.

4.3.4. Employee rotation frequency and sequence

No stipulation

4.3.5. Sanctions for unauthorized actions

NDA is designated to make the staff aware of the fact that information is confidential or classified. The staff member’s responsibility with regard to information security is established by terms and conditions of his employment agreement .

The Registry Service provider periodically tests the staff’s preparedness for the exercise of the procedures and conduct retraining as and when needed

4.3.6. Contracting personnel requirements

No stipulation

4.3.7. Documentation

Documentation, that describes the mode of implementation of procedures is available to all the staff concerned

4.4.Audit Logging Procedures

4.4.1. Types of events recorded

The following events should be made subject to automatic logging:

·      Successful and unsuccessful user login attempts, execution of privileged operations.

·      Events associated with HSM access, startup, system integrity, key generation, key activation, signing and exporting of keys.

·      Events related to keys lifecycle, keys rotation, zone signing, and malfunction signaling.

·      Personnel’s access to dedicated secured facilities.

4.4.2. Frequency of processing log

Logs are to be examined during each key rotation procedure for existence of the events associated with security and operation.

4.4.3. Retention period for audit log information

All logs should be retained in the Registry Service Provider’s information system and the document turnover system for at least one month. Upon the end of the period, the log information is archived for three years.

4.4.4. Protection of audit log

The logging system should ensure protection against an unauthorized viewing, manipulation and destruction of log data.

4.4.5. Audit log backup procedures

Electronic and hard copies should be at least once a month dispatched to an off-site facility.

4.4.6. Audit collection system

Each fact of the access to an area specially assigned for operating the DNSSEC cryptographic information is subject to recording in the automated registration system. In facilities where it is impossible to ensure automated registration, facts of the access thereto are documented in special journals.

Systems, that support the online part of the DNSSEC signing infrastructure, have components which enable one to collect data for logging.

During each procedure wherein a KSK is engaged, the crypto-operator should perform export of offline signing system logs prior to the shutdown of the system. Such journals should be stored in a safe box access to which is granted to authorized personnel only.

4.4.7. Vulnerability assessments

All events subject to logging in the journal undergo examination and evaluation for potential vulnerabilities.

4.5. Compromise and Disaster Recovery

4.5.1. Incident and compromise handling procedures

Where a specific event has resulted or may result in a security system breach, an internal investigation should be conducted to detect causes behind the incident and to remedy them.

4.5.2. Corrupted computing resources, software, and/or data

The backup recording of data in the Registry Database is performed by standard means of the Oracle database. The Registry Database’s architecture should provide for all the data critical to its functioning being stored in a separate database. A complete copy of the database should be saved regularly, per the established regulation, while in the interim archive redo logs should be saved. The set of the database copies, together with a complete set of archived redo logs allows recovery of the Registry Database’s status at a random point of time, starting from the moment of completion of the full backup. A copy of the private KSK is kept in an encrypted form at the offsite backup server.

4.5.3. Entity private key compromise procedures

Where the Registry Service Provider has a suspicion that a Private Key has been compromised or lost, then he shall operate according to established Incident Response Plan. The Registry Service Provider immediately assesses the situation, determines the degree and scope of the incident, and undertakes appropriate actions. Where the private key has been compromised, an emergency key rollover is performed, with the Crypto Operator initiating the emergency key rollover procedure.

Where an emergency key roll-over procedure occurs, the Registry Service Provider will continue to operate this key over a minimum time required to complete the emergency roll-over.

4.5.4. Business continuity and IT disaster recovery capabilities

The Registry Service Provider has implemented data backup and recovery procedures according to the Disaster Recovery Plan (DRP) and the Business Continuity Plan (BCP). The DRP provides for a geographically scattered pattern of locations of redundant storage systems. The BCP provides for a possibility for delivery of services at a remote backup site.

The Registry Service Provider’s equipment undergoes a regular examinations, testing and upgrade as and when needed.. Should a failure disaster occur, the Registry Service Provider should re-start his operational capabilities as quickly as possible.

4.6.Entity termination

If the Registry Service Provider’s operations are terminated at some point of time, he should let the interested parties know thereof and transfer his responsibilities and records to a successor entities in a secure and transparent manner and in compliance with the Registry Transition Plan for TLD .ДЕТИ

 

5.   TECHNICAL SECURITY CONTROLS

5.1.Key Pair Generation and Installation

5.1.1. Key pair generation

New KSKs are generated and stored in a specialized device, the Hardware Secure Module (HSM), which has no connection to the network infrastructure. All operations with the use of cryptographic transformations which require private KSK are performed on this device or on an equivalent one, which is used as a back-up one. For the sake of backup, the private KSK may leave the device only in an encrypted form.

New ZSKs are generated and stored on a DNSSEC signer server, which is connected to the TLD Registry Database’s internal network infrastructure. All operations with the use of cryptographic transformations which require the private ZSK are performed on this device or on an equivalent one, which is used as a backup one. The private ZSK can leave this device only in an encrypted form for the sake of backup.

5.1.2. Public key delivery

Public KSK is distributed to relying parties by means of DNS protocol.

5.1.3. Public key parameters generation and quality checking

The Registry Service Provider regulates key parameters and quality control.

5.1.4. Key usage purposes

The Registry Service Provider uses signing keys only for generating signatures for the TLD zone.

5.2.Private key protection and Cryptographic Module Engineering Controls

5.2.1. Cryptographic module standards and controls

Hardware security module (HSM) is a general-purpose computer using FSTEC-certified OS software, a true random-number generator as a source of entropy and a FSTEC -certified electronic lock capable of monitoring the integrity of the software environment.

5.2.2. Private key (m-of-n) multi-person control

Operations requiring private KSK are performed by Crypto Officers and Crypto Operator as per the procedure established in para 4.2. “Procedural Controls”. The Crypto Officer’s identification token contains a part of a password phrase required for obtaining access to the protected HSM storage. To restore the password it is sufficient to ensure participation of the number of crypto officers equivalent of m<n, where n is the aggregate number of parts of the password phrase (crypto officers).

5.2.3. Private key escrow

The Registry Service Provider does not escrow private parts of the keys.

5.2.4. Private key backup

Periodically, backups of the private keys are performed. Private key leaves the HSM only in the encrypted form. A backup copy of the private KSK is kept in the encrypted form in a storage separate from the HSM, which can only be accessed by Crypto Operator, and that copy may be decrypted by Crypto Officers. A backup copy of the private ZSK is stored at the hot-standby DNSSEC signer server which is located at a backup site and it is included in each backup copy of the registry database

5.2.5. Private key storage on cryptographic module

Private KSKs are stored in the encrypted form at the described above HSM.

5.2.6. Private key archival

Deactivated private keys are kept only as in the form of backup copy.

5.2.7. Private key transfer into or from a cryptographic Module

Private keys may be extracted out of the signer systems in the encrypted form and restored on the backup systems by authorized personnel following the procedure established in para 4.2 “Procedural Controls”.

5.2.8. Method of activating private key

Access to the private KSK is granted only upon unlocking the HSM and decrypting the private KSK storage. The Crypto Operator provides the Crypto Officers with access to the HSM console. The Crypto Officers use authentication tokens to decrypt the private KSK storage media. Access to the private ZSK is provided by the Domain Zone Administrator from the DNSSEC control interface.

5.2.9. Method of deactivating private key

Access to private KSK is automatically terminated immediately after completion of the signing procedure.

The Private ZSK is stored in the online part of the DNSSEC system. It is in the active state as long as it is keeps the status “Active”. Change of the ZSK status can be performed  by the Domain Zone Administrator from the DNSSEC management interface.

5.2.10.              Method of destroying private key

Private keys are not supposed to be destroyed. They can be removed from the system in order to prevent their use in the future.

5.3.Other Aspects of Key Pair Management

5.3.1. Public key archival

Public keys are subject to backup in the course of conduct of routine backup procedures.

5.3.2. Key usage periods

The KSKs’ lifetime is established for 13 (thirteen) months and the one for ZSKs - 3 (three) months. The Registry Service Provider may change these periods, as and when necessary. Deactivated keys may not be reused.

5.4.Activation data

5.4.1. Activation data generation and installation

Activation data to obtain access to KSK constitutes a set of passwords to Crypto Officers and Crypto Operators’ authentication tokens.

5.4.2. Activation data protection

Crypto Operators and Crypto Officers protect safety of the access data in accordance with security recommendations.

5.4.3. Other aspects of activation data

As a part of an emergency operation pattern, the Crypto Officers and the Crypto Operators may hold a copy of the password in individual sealed boxes stored in a secure location.

5.5.Computer Security Controls

All critical to Registry Service Provider’s operations components are located on protected from unauthorized access sites. Security policies mark among authorized personnel in conjunction to their functional duties, with facts of access granted being recorded.

5.6.Network Security Controls

The online part of the signing infrastructure is connected to the Registry Service Provider’s internal network infrastructure which is logically separated from the external network.   Logging in the said online part is possible only via a firewall, which provides minimum necessary possibilities to exercise the control .

A part of the signing system that holds the private KSK has no network connection. Transmission of a KSR is performed using removable media.

5.7.Timestamping

The online signer system securely synchronizes its clocks with a trusted time source inside the network. The time setting in the offline part of the DNSSEC system is performed manually with every activation of HSM.

5.8.Life Cycle Technical Controls

5.8.1. System development controls

Applications developed by the Registry Service Provider employ version control repositories. Prior to their deployment onto the Registry, a third-party’s developments undergo laboratory testing for compatibility with the Registry Service Provider’s applications.

5.8.2. Security management controls

The Registry Service Provider conducts periodical security audits.

5.8.3. Life cycle security controls

The signer systems are designed to require minimum maintenance. Their updates, that are critical security- and operation-wise, are applied after laboratory testing.

6.   ZONE SIGNING

6.1.Key lengths and algorithms

The signing system employs an algorithm and a key length necessary from the security perspective throughout the period of usage.

The current algorithm for both KSK and ZSK is RSA-SHA256, with key lengths of 2048 bits and 1024bits, respectively.

6.2.Authenticated denial of existence

For authentication of denial of existence the NSEC3 OPT-OUT mechanism is used [RFC 5155].

6.3.Signature format

Signatures are generated by the RSA algorithm with the SHA256 hash [RFC 5702].

6.4.Zone signing key roll-over

Pre-publication scheme will be applied for a ZSK roll-over [RFC 4641].

6.5.Key signing key roll-over

Double-signature scheme will be applied for a KSK roll-over [RFC 4641].

6.6.Signature life-time and re-signing frequency

The signature lifetime for DNSKEY RR is 20 days, while for records of other types the signature lifetime is set for 45 days. The re-signing frequency rate is a half hourly one.

These parameters can be modified, as and when necessary.

6.7.Verification of zone signing key set

While generating a key set (KSR), which consists of public ZSKs and KSKs, the former is signed using the Registry PGP key which is located in the online DNSSEC signer system. Before accepting the KSR for signing the offline DNSSEC signer system automatically validates the KSR signature with the use of pre-imported public PGP Registry key.

6.8.Verification of resource records

The Registry Service Provider verifies all the resource records for conformity to the protocol standards.

6.9.Resource records time-to-live (TTL)

The TTL of entries of DNSKEY-, DS- and corresponding to them RRSIG-type is established at 86,400 sec. (1 day). The TTL of entries of NSEC3- and corresponding RRSIG-type is established at 3,600 sec. (1 hour), which matches the time of the negative cache for the zone.

These parameters can be modified, as and when necessary.

 

7.   COMPLIANCE AUDIT

7.1.Frequency of entity compliance audit

The Registry Service Provider is bound to engage, at least once a year, independent auditor to evaluate the Registry Service Provider’s meeting requirements of the present document.

7.2.Identity/qualifications of auditor

An individual or a group to conduct audit should be in possession of training and skills in the area of information systems security audit, and expertise with regard to Domain Names infrastructure, DNS and DNSSEC technologies, and Internet security issues.

7.3.Auditor's relationship to audited party

The Registry Service Provider is bound to resort to services of an independent auditor that does not have any financial interest, business relationships, effective business operations which could create an imputed prejudice in favor or against the Registry Service Provider.

7.4.Topics covered by audit

Audit must conform to industry standards and cover examination of the Registry Service Provider's compliance with its declared business practices and requirements set forth by the present document

7.5.Actions taken as a result of deficiency

Where an audit presents findings about any material failure to comply to requirements of the present document or other contractual obligations with respect to provided by the Registry Service Provider, then (1) the auditor shall document an inconsistency, (2) the auditor shall immediately notify thereof the Registry Operator and the Registry Service Provider, and (3) the Registry Service Provider shall develop a plan to rectify the inconsistency. The Registry Service Provider shall submit the plan to the Registry Operator for approval. The Registry Operator may require additional action, as and when necessary, to rectify any material problems engendered by the revealed inconsistency.

7.6.Communication of results

The audit findings shall be submitted in writing to the Registry Service Provider within 30 days upon completion of the audit. The auditor’s reports are not subject to publication.