DNSSEC Practice Statement for .LV zone


1. Overview

This document is the NIC.LV Registry Services DNSSEC Practice Statement (DPS). It defines the operational procedures for the management of DNS Security Extensions (DNSSEC) in the Latvian top-level domain .LV

DNSSEC is an extension to the existing DNS-System that enables the authentication of DNS data and makes it possible to verify that the content of a DNS response has not been modified.

Resource record sets secured with DNSSEC are cryptographically signed and use asymmetric cryptography to establish a so-called “chain of trust” that traverses the public DNS tree. This trust originates at the root zone and follows the same delegation process as that of domain name registrations.

1.1 Document name and identification

Document title:    DNSSEC Practice Statement for .LV zone
Version:    0.2.0
Created:    2012-01-16
Updated:    2012-08-31

1.2 Community and Applicability

The following roles and delegation of liability with regard to DNSSEC have been identified:

1.2.1 LV Registry

NIC.LV is responsible for the TLD .LV. This means that this organization is responsible for the management of all data related to registration, modification and deletion of (2nd level)-domain names under .LV. The Registry is also responsible for generating the relevant cryptographic keys, ensuring protection for those keys, signing the actual zone file and the registration and maintenance of DS records in the root zone.

1.2.2 Registrar

The Registrar is responsible for the administration and management of domain names on behalf of the Registrant. They are also responsible for the registration and maintenance of the corresponding DS Records within the Registry.

1.2.3 DNSSEC Service Provider

The DNSSEC Service Provider is a Registrar responsible for the administration and management of the DNSSEC keys of a domain name within the Registry on behalf of the Registrant but not necessarily responsible for the management of the domain name.

1.2.4 Registrant

The Registrant is a physical or legal entity that controls a domain name. They are responsible for the proper signing of child zones and the registration and maintenance of DS records through the Registrar or directly through the .LV Registry. If necessary, the process of zone signing can be delegated to the Registrar.

1.3 Specification Administration

This DPS is updated as appropriate to reflect modifications in systems or procedures.

1.4 Specification administration organization

Agency of the University of Latvia “Institute of Mathematics and Computer Science of University of Latvia” Network Solutions Department - NIC.LV

1.5 Contact Information

Address:    Raina bulvaris 29, Riga, LV-1459, Latvia
Telephone:    +371-67085858
E-mail:    dns@nic.lv

1.6 Specification change procedures

Amendments to this DPS are either made in the form of amendments to the existing document or the publication of a new version of the document. This DPS and amendments to it are published at: https://www.nic.lv/en/dnssec-en

2 Publication and Repositories

2.1 Publication Site

DNSSEC-relevant information will be published on the website of https://www.nic.lv/en/dnssec-en

2.2 Publication of key signing keys

The deployed KSKs are published in the form of DS Records directly in the root zone. No other trust anchors or repositories are used.

3 Operational Requirements

3.1 Activation of DNSSEC for child zone

DNSSEC is activated by at least one DS record for the zone being sent from the Registrar or the Registrant to the Registry and thus being published in the DNS, which established a chain of trust to the child zone. During the first DS submission the Registry will perform DS record and DNSKEY validation, this could be overridden by DS record submitter if necessary.

3.2 Identification and authentication of child zone manager

Responsibility for the identification and authentication of a child zone manager rests with the Registrar and the Registrant.

3.3 Registration of delegation signer (DS) resource records

The Registry accepts DS records through its EPP interface from any Registrar. The Registrar is identified and authenticated via EPP. Registrants can enter their DS Records via web interface. The DS record must be valid and sent in the format indicated in RFC 5910. Up to 4 DS records can be registered per domain name. The registrar and the registrant can also remove all or selected DS records for a domain name.

3.4 Method to prove possession of private key

The Registry does not perform any validation checks for authenticating the Registrant as the manager or holder of a specific private key.

3.5 Removal of DS record

DS records can be removed via the EPP interface by the respective registrar or via web interface by the registrant.

4 Facility, Management and Operational Controls

4.1 Physical Controls

NIC.LV has implemented the Security Policy, which supports the security requirements of this DPS.

4.1.1 Site location and construction

NIC.LV operates fully-operational data centre in Latvia. Data centre includes separated server-rooms, separated cabinets and additional off-site backup outside of the primary data centre.

4.1.2 Physical access

Physical access to operation centres is restricted to authorized personnel. Entry is logged and the environment is continuously monitored.

4.1.3 Power and air conditioning

Operation centres are equipped with multiple power sources, including battery and generator support to ensure an uninterrupted supply.

Operation centres are cooled with redundant air conditioning systems to ensure a consistent, stable operating environment.

4.1.4 Water exposures

The facilities located in “non-flood” areas therefore flood protection is not needed.

4.1.5 Fire prevention and protection

The facilities are equipped with fire detection and extinguishing systems.

4.1.6 Media storage

Sensitive media is stored in a fireproof safe which is only accessible to the NIC.LV Senior Management and specifically designated personnel.

4.1.7 Waste disposal

Sensitive documents and materials are shredded or destroyed before disposal.

4.1.8 Off-site backup

NIC.LV performs regular backups of critical data. The storage facility is separated from other operational facilities of NIC.LV.

4.2 Procedural Controls

4.2.1 Trusted roles

Trusted Persons include all employees, contractors, and consultants who have access to or control cryptographic operations that may materially affect:

Generation and protection of the private component of the .LV Zone Signing Key (ZSK) and Key Signing Key (KSK).
Secure export and import of any public components.
Generation and signing zone file data.

Trusted Persons include:

System Administrator, SA
Security Officer, SO
Trusted witness

4.2.2 Task Requiring Separation of Duties

Any non-automated procedure performed on the zone signer system requires at least one System Administrator and one Security Officer to be present.

4.3 Personnel Controls

4.3.1 Qualifications, experience, and clearance requirements

Engineers taking part in the Trusted Roles have to have been working for the NIC.LV registry for no less than one year and must have the qualifications necessary for the DNS engineer job role.

4.3.2 Background check procedures

Background checks are performed as part of the hiring process for all personnel.

4.3.3 Training requirements

Every person with a trusted role in the Key Generation procedure must be trained in the Key Generation procedure. The Registry periodically examines the necessity of re-training the personnel in charge of DNSSEC operations.

4.3.4 Documentation supplied to personnel

NIC.LV supplies the necessary documentation to each employee to perform their work task in a secure and satisfactory manner.

4.4 Audit Logging Procedures

Logging is automatically carried out and involves the continuous collection of information regarding the activities that take place in the DNSSEC system. Logging information also includes the journals, checklists and other paper documents that are vital to security and that are required for auditing.

4.4.1 Types of events recorded

Entry to the facility
Remote access
Any type of DNSSEC operation

4.4.2 Frequency of processing log

Logs are systematically analysed through automated and manual processes.

4.4.3 Retention period for audit log information

Log information is stored in log systems for not less than 1 year. Thereafter, the log information is archived for not less than 2 years.

4.4.4 Protection of audit log

The Registry limits access to the Audit Logs to only necessary personnel in order to protect the Audit Logs from browse, modification or deletion by unauthorized parties.

4.4.5 Audit log backup procedures

The Registry backups the Audit Logs on external media storage periodically.

4.4.6 Vulnerability assessments

All anomalies in logging information are investigated to analyse potential vulnerabilities.

4.5 Compromise and Disaster Recovery

4.5.1 Incident and compromise handling procedures

If an event leads to, or could lead to, a detected security compromise, NIC.LV will perform an investigation to determine the nature of the incident. If NIC.LV suspect the incident has compromised the private component of an active key, an emergency key roll-over procedure will be performed.

4.5.2 Corrupted computing resources, software, and/or data

In the event of a hardware fault System Administrator will manually activate secondary DNSSEC signing system. The faulty elements for the primary system will be replaced as soon as possible.

4.5.3 Entity private key compromise procedures

A suspected or actual ZSK compromise will be addressed by immediately removing the compromised ZSK from service, replacing it with a newly-generated or pre-generated replacement key. A suspected or actual KSK compromise will be addressed by an immediate key rollover.

4.5.4 Business Continuity and IT Disaster Recovery Capabilities

In the event of a disruption to DNSSEC services due, for example, to a disaster at a data centre facility, the registry will recover the service(s) as soon as possible at the backup data centre.

4.5.5 Entity termination

If it becomes necessary to discontinue DNSSEC services, the Registry will invoke a pre-defined set of procedures. The general public will also be informed in such an event.

5 Technical Security Controls

5.1 Key Pair Generation and Installation

5.1.1 Key pair generation

KSK generation takes place when necessary and must be performed by at least two Trusted Persons working in unison. These Trusted Persons are present during the entire operation. KSK of the .LV zone is generated on a dedicated and duplicate server system. ZSK of the .LV zone is generated automatically based on a ZSK key lifetime schedule.

5.1.2 Public key delivery

The public part of the KSKs are exported and verified by the System Administrator and Security Officer. The Security Officer is responsible for publishing the DS record in the root zone. Newly generated keys will be synced automatically with the duplicate DNSSEC system. The System Administrator and the Security Officer are responsible for verifying synchronization.

5.1.3 Public key parameters generation and quality checking

The Registry periodically confirms that generation of signing key is conducted with appropriate parameters in the context of technological trends.

5.1.4 Key usage purposes

A key generated for DNSSEC purposes must only be used for DNSSEC activities and should never be used outside of the signing systems. A key must only be used for one zone and cannot be reused.

5.2 Private key protection and Cryptographic Module Engineering Controls

No private keys are ever found unprotected outside the DNSSEC infrastructure.

5.2.1 Private Key (m-of-n) Multi-person Control

The Registry applies multi-person controls administratively.

5.2.2 Private key escrow

The Registry does not apply a key escrow.

5.2.3 Private key backup

A backup copy of the protected private keys will be kept in a portable storage media which will be kept inside a tamper proof sealed bag and inside a fireproof safe.

5.2.4 Private key archival

All used keys are kept in an archive. Used keys are never reused.

5.2.5 Private key transfer into or from a cryptographic module

Private keys are generated directly inside DNSSEC system. They will be automatically and instantly synced to a duplicate DNSSEC system.

5.2.6 Method of activating private key

KSK - is generated and activated by a Security Officer together with a System Administrator/Trusted witness. ZSK - is generated and activated automatically by the DNSSEC system.

5.2.7 Method of deactivating private key

KSK - is deactivated by a Security Officer together with a System Administrator/Trusted witness once it reaches the limit of the usage period. ZSK - is deactivated automatically by the system if it reaches the limit of the usage period and if new ZSK is published and available.

5.2.8 Method of destroying private key

Private keys will not be destroyed and will be sent to archive.

5.3 Other Aspects of Key Pair Management

5.3.1 Public key archival

Public keys are archived in accordance with the archiving of other information relevant to traceability in the system, such as log data.

5.3.2 Key usage periods

The upper limit of usage period for KSK is three years plus appropriate period for transition. The upper limit of usage period for ZSK is 50 days. The Registry may change these periods as necessary. Old keys are never reused.

5.4 Network Security Controls

The registry has logically sectioned networks that are divided into various security zones with secured communications in-between. Logging is conducted in the firewalls. All sensitive information that is transferred over the communications network is always protected by strong encryption.

5.5 Timestamping

The DNSSEC systems securely synchronize their system clocks with a trusted time source inside the NIC.LV network.

5.6 Life Cycle Technical Controls

5.6.1 System development controls

The Registry controls each process at system development and evaluates the system prior to deploying it, in order to maintain the quality and security of the NIC.LV DNSSEC Service System. All source code is stored in a version control system. The source code archive is regularly backed up and copies are stored separately in a fireproof safe.

5.6.2 Security management controls

NIC.LV has technologies and policies in place to control and monitor the configurations of its systems. A security audit will be repeated at regular intervals.

5.6.3 Life cycle security controls

The DNSSEC system is designed to require a minimum of maintenance. Updates critical to the security and operations of the signer system will be applied after formal testing and approval.

6 Zone Signing

The signing of the .LV zone will use the following parameters. Any change to these parameters will be reflected in this document.

6.1 Key lengths and algorithms

The RSA algorithm with a key length of 2048 bits is used for generating KSKs and a key length of 1024 bits used for generating ZSKs.

6.2 Authenticated denial of existence

The Registry uses NSEC3 with OPT-OUT as defined in RFC 5155.

6.3 Signature format

Signatures are generated using RSA operation over a cryptographic hash function using SHA-256 (RSA/SHA-256, RFC 5702).

6.4 Zone signing key roll-over

The expected lifetime of the ZSK is 50 days with pre-publish method described in RFC 4641.

6.5 Key signing key roll-over

In the LV zone, roll-over of KSK is carried out once every three years or as needed with double signature method described in RFC 4641.

6.6 Signature lifetime and re-signing frequency

ZSK signatures will last from 5 to 60 days and will be resigned with each new zone.

6.7 Verification of zone signing key set

Before publishing a signed zone on the name server, the zone must pass a number of checks:

Verification of the chain of trust from the DS Record in the root zone to the signature of the SOA record in the .LV zone Verification that the validity period of the signature of the SOA-Record is at least 5 days in the future Pass a number of predefined queries (with DNSSEC enabled) for special records in the zone

6.8 Verification of resource records

NIC.LV verifies that all resource records are valid according to the current standards prior to distribution. The integrity of the unsigned zone contents is also validated prior to distribution.

6.9 Resource records time-to-live

DNSKEY - Equal to the TTL used for the SOA record.

NSEC3 - Equal to the minimum field of the SOA record.

DS - Equal to the TTL used for the NS record.

RRSIG - varies, depending on the RRset signed.

7 Compliance Audit

Audits are conducted using retained logs and other relevant information to ensure that the proper procedures have been executed accurately. The Registry applies operational improvements to the NIC.LV DNSSEC Service as necessary.

7.1 Frequency of entity compliance audit

Every two years NIC.LV engages external auditors to check on compliance with the security policy and procedures. Circumstances which might lead to additional audits being carried out include recurring anomalies, significant staff changes or changes in equipment.

7.2 Identity/qualifications of auditor

The auditor must be able to demonstrate proficiency with IT security tools, security auditing, DNS and DNSSEC.

The Registry has no legal responsibilities for the matters described in this DPS. NIC.LV accepts no financial responsibility for improper use of Trust anchors or signatures, or any other improper use under this DPS. NIC.LV reserves the right to disable DNSSEC at any moment if the stability of .LV is at risk.

8.1 Term

This DPS is valid until it is replaced by a new version.

8.2 Dispute Resolution Provisions

Disputes among DNSSEC participants shall be resolved pursuant to provisions in the applicable agreements among the parties.

8.3 Governing law

When operating the NIC.LV DNSSEC Service, the Registry follows the laws of the Republic of Latvia and the rules and procedures defined by the Registry.