DNSSEC Operations and Security Practice Statement

This content is only available for historical reference.

Introduction

This document is intended as a statement of the security practices (physical and network) employed by the RIPE NCC in relation to the operation and forward planning of DNSSEC.

The private keys used by DNSSEC are stored on a machine (known from here on as the "signer") which is physically separated from all machines providing public DNS services. The first section of this document discusses the physical security of that machine. The second section of the document provides details on the network security of the signer. The third section describes the policies in place for backup and recovery. Finally, the document looks at details regarding the keys and signing frequency, along with rollover policies and communication strategies.

Physical Security

The private keys used by DNSSEC are stored on the signer, a machine located separately from and using different power and network infrastructure from all machines providing public DNS services.

The signer is housed in a secure area open only to RIPE NCC technical staff, and is restricted to boot only from its internal disk. The BIOS on the machine is password protected to ensure it cannot be changed to boot from any other media. Logins on the console of the signer are restricted to two members of the RIPE NCC technical staff, and privileged or root login is not available on the physical console of signer.

Network Security

The signer is connected to the RIPE NCC network infrastructure via a standard switched VLAN. A single host (the DNS provisioning server) has connectivity to the signer via SSH; firewall filtering blocks access from all other hosts. Two members of RIPE NCC technical staff are permitted network access, which is via SSH using public/private keys only. Privileged access to the machine is available for the same two members of staff only and a privilege elevation method logs all usage.

Backup and Recovery

The signer's entire hard disk is backed up once a month (and immediately following a key incident) to CD-ROM. The part of the backup which contains the keystore is encrypted using the PGP keys of the two designated members of RIPE NCC technical staff. The CD-ROM backup is stored in a locked/secure location at a different site to the signer.

An internally published disaster recovery policy is available, covering the steps needed to recover from total loss of the signer. One of the previously mentioned members of the RIPE NCC technical staff must be present to recover the encrypted keystore.

Keys/Signing and Rollover Policy

To avoid possible failures, here at the RIPE NCC we will sign all zones using the procedure described below:

• RIPE NCC will sign all data in the zone with at least one Zone Signing Key (ZSK). A ZSK is zone specific.
• The ZSK will be published in the DNSKEY Resource Record (RR) set and signed with a Key Signing Key (KSK).
• The KSKs will have an SEP flag set so that they can be distinguished from the ZSKs in the DNSKEY RR set.

Rollover Policy

• The ZSK may be rolled without making any announcement. This will be done according to the 'pre-publish rollover scheme' detailed below, which will avoid breaks in the chain of trust.
• During the first two years of deployment, the KSK of the e164.arpa zone will be rolled twice each year. The rollovers will be carried out according to the 'double signature scheme', as follows:
  • At t=0 KSK1 signs the keyset.
  • At t=3 months KSK1 and KSK2 sign the keyset. DNS clients are expected to configure KSK2 during the three months that follow.
  • At t=6 months only KSK2 signs the keyset until.
  • At t=9 months KSK3 is introduced and a new rollover starts.

Secure delegations

The RIPE NCC provides a secure method for administrators of zones to upload secure delegations to the parent zones.