SaudiNIC DNSSEC Practice Statement 

The Domain Name System Security Extension (DNSSEC) Practice Statement (DPS) is a statement of security practices and provisions made by the Saudi Network Information Center (SaudiNIC). This DPS is intended to document the policy practices and procedures that are followed in conjunction with DNSSEC for the Saudi Top Level Domains (TLD) that are managed by SaudiNIC (.SA and .السعودية).

1. INTRODUCTION

The Domain Name System Security Extension (DNSSEC) Practice Statement (DPS) is a statement of security practices and provisions made by the Saudi Network Information Center (SaudiNIC). This DPS is intended to document the policy practices and procedures that are followed in conjunction with DNSSEC for the Saudi Top Level Domains (TLD) that are managed by SaudiNIC (.SA and .السعودية ). It is based on the RFC 6841: A Framework for DNSSEC Policies and DNSSEC Practice Statements.

1.1 Overview

DNSSEC is an extension of the existing Domain Name System (DNS) that provides the capabilities to validate that the DNS data has not been tampered with or modified during Internet transit and it came for the actual source. This is accomplished by incorporating public key cryptography into the DNS hierarchy to form a chain of trust originating from the root zone.

1.2 Document Name and Identification

  • Document Title: SaudiNIC DNSSEC Practice Statement
  • Version: 1.0
  • Created: Jun 7, 2017

1.3 Community and Applicability

This DPS applies exclusively to the Saudi TLD zones (namely, the ASCII TLD .SA and the IDN TLD .السعودية ). It describes the procedures and security controls applicable when managing and employing keys and signatures for the signing of the Saudi TLD zones.

1.3.1 Registry

SaudiNIC is the registry for the Saudi TLDs (.SA and.السعودية ). This means that SaudiNIC is responsible for the management of all data related to registration, modification and deletion of (2nd-level)-domain names under (.SA and .السعودية ), and (3rd-level)-domain names under (com.sa, net.sa, gov.sa, org.sa, edu.sa, med.sa, sch.sa, pub.sa). SaudiNIC is responsible for generating key pairs (Public and Private) and protecting the confidentiality of the private component of the Key Signing Keys (KSK) and Zone Signing Keys (ZSK) used to sign DNS resource records in the Saudi TLDs zones. Additionally, SaudiNIC is responsible for providing and maintaining the Delegation Signer (DS) records in the root zone.

1.3.2 Registrar

An entity that is authorized by SaudiNIC to provide registration services to registrants. The Registrar, when available, is responsible for the administration and management of domain names on behalf of the Registrant. The Registrar, when available, is also responsible for the registration and maintenance of the corresponding DS-Records within SaudiNIC.

1.3.3 Registrant

A natural person or a legal entity that requested or will request registration services from SaudiNIC, either directly or through a third party. A registrant may be a current holder of a Saudi domain name.

The registrant is responsible for the proper signing of child zones and the registration and maintenance of DS records. If necessary, the process of zone signing and key management can be delegated to a third party (e.g., a Registrar or an ISP).

1.3.4 Dependent entities

Dependent entities are entities that make use of DNSSEC data, for example, ISPs, using validating resolvers or other applications. The dependent entities are responsible for maintaining the appropriate DNSSEC trust anchors and configurations.

1.3.5 Applicability

Each Registrant is responsible for determining an appropriate level of security for their domain. This DPS applies exclusively to the Saudi TLDs (.SA and .السعودية ), and describes the procedures, security controls and practices employed in the management of DNSSEC in these zones.

With the support of this DPS, the relying party can determine the level of trust they may assign to DNSSEC, and assess their own risk.

1.4 Specification Administration

This DPS will be periodically reviewed and updated as appropriate.

1.4.1 Specification Administration Organization

The Saudi Network Information Center (SaudiNIC), of the Communications, Space & Technology Commission (CST).

1.4.2 Contact

Saudi Network Information Centre, Communication and Information Technology Commission. P. O. Box 75606, Riyadh 11588, Saudi Arabia.

Phone : +966-11-4619488

Fax: +966-11-4619480

Website: www.nic.sa

1.4.3 Specification Change Procedures

Changes to this DPS will result in a new version of the document being released. The most recent version of this DPS will be published on the website of SaudiNIC: www.nic.sa

2. PUBLICATION AND REPOSITORIES

2.1 Publication Site

DNSSEC-relevant information will be published on the website of SaudiNIC: www.nic.sa.

2.2 Publication of Key Signing Keys (KSK)

The deployed KSK public keys are published as a DNSKEY record within the related zone and as a Delegation Signer (DS) record in the corresponding parent zone (e.g. root zone) in the form of DS-Records.

2.3 Access Control

DNSSEC-relevant information published on the specific website is accessible by the general public.

3. OPERATIONAL REQUIREMENTS

3.1 Meaning of Domain Names

The purpose and meaning of domain names can be found in Saudi Domain Name Registration Regulation.

3.2 Activation of DNSSEC for Child Zone

DNSSEC for a child zone is activated when requested by the registrant and if its DS record was successfully submitted and published in the parent zone.

The registrant is responsible for the correctness and validity of his DS records. SaudiNIC may do the necessary technical checks periodically if needed.

3.3 Identification and Authentication of Child Zone Manager

Responsibility for the identification and authentication of a child zone manager rests within SaudiNIC or its Registrars.

3.4 Registration of Delegation Signer (DS) Records

SaudiNIC accepts DS records from the registrant directly or through Registrars. Up to six DS records can be registered per child domain.

Registrants can enter their DS records via SaudiNIC's Registration system and in this case the DS record must be valid and sent in the format indicated in RFC 4034.

However, if a registrar who adds DS records on behalf a registrant, the registrar should use the EPP interface to SaudiNIC systems to add the DS records. The registrar is identified and authenticated via EPP. The DS records must be valid and sent in the format indicated in RFC 5910.

3.5 Method to prove Possession of Private Key

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

3.6 Removal of DS Record

SaudiNIC accepts removal of DS records from the registrant directly or through Registrars.

Registrants can remove their DS records via SaudiNIC's Registration system. However, a registrar can remove DS records on behalf a registrant. The registrar should use the EPP interface to SaudiNIC systems to remove the DS records. The registrar is identified and authenticated via EPP.

If all DS records of a child zone are removed, DNSSEC for that zone is disabled. SaudiNIC may remove DS records if not configured correctly.

4. Facility, Management and Operational Controls

4.1 Physical Controls

4.1.1 Site Location and Construction

The SaudiNIC registry system is operated from at least two operational and geographically dispersed data centers.

4.1.2 Physical Access

Physical access to the data center is limited to authorized personnel.

4.1.3 Power and Air Conditioning

Power is supplied via separate and independent feeds. In case of power failure, power is provided by UPS and via backup power generator units. Both datacenters are equipped with air conditioning systems.

4.1.4 Flood protection

Data centers are located in “non-flood” areas so flood protection is not needed.

4.1.5 Fire Protection and Prevention

Data centers fulfill the local safety regulations. All facilities are equipped with fire detection devices as well as fire extinguishers.

4.1.6 Media Storage

Sensitive media is stored in a fireproof safe which is only accessible by authorized personnel.

4.1.7 Waste Disposal

All confidential documents and media are shredded or destroyed before disposal.

4.1.8 Off-site Backup

All systems are backed up to an external tape-library in a separate datacenter.

4.2 Procedural Controls

4.2.1 Trusted Roles

So-called “trusted roles” are staffed with highly trained and experienced personnel who have access to or control cryptographic operations and will perform all relevant DNSSEC tasks such as:

  • Generating Keys
  • Protecting Keys' private components
  • Publishing Keys' public components
  • Signing Zone files

None of these tasks can be performed in the presence of unauthorized people. The trusted roles are:

  • System Admin (SA)
  • DNSSEC Specialist (DSS)

Another role is a witness (WI) who is an attendant person with no ties to the operations. The witness does not have physical access or logical access to the operational facilities or keys. The witness has the ability to question the implementers at all stages of DNSSEC deployment. A Witness role can be fulfilled by anyone CST's staff member or outsider.

4.2.2 Task Requiring Separation of Duties

Any task performed on the Keys for the zone-signer system requires at least one System Admin (SA) and one DNSSEC Specialist (DSS) to be present. No two trusted roles may be held by a single individual. The attendance of the SaudiNIC manager or acting manager is compulsory.

4.3 Personnel Controls

4.3.1 Qualification, Experience and Clearance Requirements

Personnel taking part in trusted roles must have been working for SaudiNIC or CST for more than one year and must have all necessary qualifications.

4.3.2 Background Checks

Background checks are performed for trusted roles personnel.

4.3.3 Training Requirement

SaudiNIC will provide necessary DNS and DNSSEC training for the trusted roles personnel.

4.3.4 Contracting Personnel Requirements

Only personnel in specified trusted roles are permitted access to DNSSEC systems. If needed, an external personnel are always accompanied and observed by a minimum of two CST employees who hold one or more trusted roles.

4.3.5 Documents Supplied to Personnel

SaudiNIC supplies the necessary documentation to employees to support their work 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 SaudiNIC's systems. The logged information is used in the monitoring of operations, for statistical purposes and for investigation purposes, in suspected cases of violation of SaudiNIC's policies and regulations.

4.4.1 Types of Events Recorded

The following events are logged to detect illegal/incorrect operations:

  • Entry to all data center facilities
  • Remote access attempts (successful and unsuccessful) to all DNSSEC Systems
  • Any type of DNSSEC operation (such as key generation, key rollovers, & etc. .

4.4.2 Frequency of Log Processing

All logs are checked regularly and as needed by a number of automatic and manual methods.

4.4.3 Retention Period for Audit Log Information

Log files are stored for at least 30 days on the logging system. Thereafter, log files are archived on the backup system for at least 3 months.

4.4.4 Protection of Audit Log

Access to audit logs is permitted only for authorized personnel.

4.4.5 Audit Log Backup Procedures

Audit logs are backed up on external storage media periodically. This storage media is located in an external data center. Paper logs are backed up by scanning and storing them electronically.

4.4.6 Audit Collection System

Electronic log information is transferred in real-time to a collection system.

4.4.7 Notification to Event-causing Subject

Any persons that trigger an event to be logged are not notified of this action or that such logging is taking place.

4.4.8 Vulnerability Assessments

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

4.5 Compromise and Disaster Recovery

4.5.1 Incident and Compromise Handling Procedures

If the private part of an active key (KSK or ZSK) is (likely to be) compromised, an emergency key rollover procedure will be performed.

4.5.2 Corrupted Equipment, Software or Information

In the event of a hardware fault, the faulty element(s) will be replaced immediately (full service contracts are maintained with all hardware vendors). In the event of a software or data issue, SaudiNIC will perform recovery actions in accordance with predefined recovery plans.

4.5.3 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 center facility, SaudiNIC will recover the service(s) according to the SaudiNIC' s disaster recovery plan.

4.6 Entity Termination

If it becomes necessary to discontinue DNSSEC services for any reason, this will take place in an orderly manner, and the general public will be informed in such an event. If operations are to be transferred to another party, SaudiNIC will participate in the transition to ensure it is as seamless as possible.

5. Technical Security Controls

5.1 Key Pair Generation and Installation

5.1.1 Key Pair Generation

The generation of key pairs is performed by the cryptographic module which is managed by trained and specifically appointed personnel in trusted roles. Key generation actions take place when necessary (e.g. before a planned key rollover) and must be performed by a minimum of two trusted roles personnel. These personnel must be present during the entire operation and should be attended by a Witness role (in normal key rollover). The entire key-generation procedure is logged electronically and documented manually by the DNSSEC Specialist (DSS).

5.1.2 Public Key Distribution

The public component of each generated KSK is published as per Section 2.2. The DS is delivered to the parent zone. The public component of each generated ZSK is published in the corresponding zone as a DNSKEY record.

5.1.3 Public Key Parameters Generation and Quality Checking

Key parameters are defined in section 6. The quality control includes checking the key lengths.

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.

5.2 Private Key Protection and Cryptographic Modules Engineering Controls

All cryptographic operations are performed within the cryptographic module.

5.2.1 Cryptographic Module Standards and Controls

The system uses a cryptographic module, that conforms to the requirements in FIPS 140-2 level 2

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

A minimum of 3 out of 6 persons are required to activate a cryptographic module.

5.2.3 Key Escrow

Private keys are not escrowed.

5.2.4 Private Key Backup

Backup copies of private keys are created and stored on at least two cryptographic modules. Keys are stored in an encrypted format on the cryptographic module. The encrypted key archive is securely backed up and synchronized between the operations facilities shortly after key generation.

5.2.5 Private Key Storage on Cryptographic Module

Private keys are stored on cryptographic modules and they are stored in encrypted form.

5.2.6 Private Key Archival

Private keys which are no longer in use are not archived in any particular form except that of normal backup copies.

5.2.7 Private Key Transfer into or from a Cryptographic Module

The private keys are transferred between Cryptographic Modules in an encrypted form. Transfer occurs only during backup or restoration of private keys and is performed by personnel in trusted roles.

5.2.8 Method of Activating a Private Key

A new private key is activated by a team consisting of at least one System Admin (SA), and one DNSSEC Specialist (DSS).

5.2.9 Method of Destroying a Private Key

Private keys will not be destroyed. Once they have reached end of life, they are removed from the DNSSEC system.

5.3 Other Aspects of Key Pair Management

5.3.1 Public Key Archival

Obsolete public keys are not archived

5.3.2 Key Usage Period

Keys become invalid as they are taken out of production. Old keys are not reused.

5.4 Activation Data

5.4.1 Activation Data Generation and Installation

Each personnel in a trusted role is responsible for creating their own activation data.

5.4.2 Activation Data Protection

Each personnel in a trusted role is responsible for protecting their activation data. If a compromise of this activation data is suspected, the responsibility rests with the personnel to immediately change it.

5.4.3 Other Aspects of Activation Data

As part of emergency planning, a copy of all activation data is sealed in envelopes and stored in a secure location.

5.5 Computer Security Controls

Access to all computing components and registry systems is logged and traceable. All critical operations performed on these systems will also be logged. All personnel with access to these systems must use individual access credentials. The use of shared credentials is not permitted.

5.6 Network Security Controls

The registry systems are split into a number of different VLANs and security zones depending on security classification. All network traffic between these security zones is filtered by a number of firewall layers.

5.7 Time Stamping

Registry systems synchronize all system clocks with trusted time sources. All timestamps generated by the registry system are in UTC.

5.8 Life Cycle Technical Controls

5.8.1 System Development Controls

All applications used to implement DNSSEC are evaluated prior to being deployed in a lab environment and are subjected to a pre-defined testing framework. Only when all tests have been completed successfully can the software be rolled out to production environments and in accordance with pre-defined procedures.

5.8.2 System Management Controls

A security audit will be repeated at regular intervals.

6. Zone Signing

6.1 Lengths and Algorithms

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

6.2 Authenticated Denial of Existence

Authenticated denial of existence will be provided through the use of NSEC3 records as specified in RFC 5155.

6.3 Signature Format

The digital signature algorithm used to sign the TLD zone file is RSA/ SHA-2 as defined in RFC 5702.

6.4 Zone Signing Key Roll-over

ZSK rollover is carried out every 6 months

6.5 Key Signing Key Roll-over

KSKs will be rolled over when needed;.

6.6 Signature Life-time and Re-signing Frequency

RRsets are signed with the ZSKs with a validity period of 12 to 16 days. Automatic re-signing takes place daily and only signatures close to expiration will be regenerated.

6.7 Verification of Resource Records

SaudiNIC verifies that all resource records are conformant with the current standards before publishing the zone.

6.8 Resource Records Time-to-live (TTL)

The TTL for DS records will be set to 3600 seconds (1 hour) and the TTL for DNSKEY and NSEC3 records to 3600 seconds. RRSIG records inherit TTLs from the corresponding signed RRset.

7. COMPLIANCE AUDIT

A regular audit for DNSSEC systems and services will be performed. Audit reports are subsequently provided to SaudiNIC and any operational recommendations will be applied as necessary.

8. LEGAL MATTERS

This DPS shall be subject to SaudiNIC's regulations and to the laws of Saudi Arabia.