DNSSEC Policy and Practice Statement
- Document name and identification
- Community and Applicability
- Specification Administration
- Publication and Repositories
- Publication of Key Signing Keys (KSK)
- Access Controls on Repositories
- Operational Requirements
- Registration, Modification and Removal of Delegation Signer (DS) Resource Records
- Method to Prove Possession of Private Key
- Facility, Management and Operational Controls
- Physical Controls
- Site location and construction
- Physical access
- Power and Air Conditioning
- Water Exposure
- Fire Prevention and Protection
- Media Storage
- Waste Disposal
- Off-site Back-up
- Procedural Controls
- Personnel Controls
- Qualifications, Experience and Clearance Requirements
- Training Requirements
- Job Rotation Frequency and Sequence
- Contracting Personnel Requirements
- Documentation Supplied to Personnel
- Audit Logging Procedures
- Compromise and Disaster Recovery
- Technical Security Controls
- Key Pair Generation and Installation
- Private Key Protection and Cryptographic Module Engineering Controls
- Cryptographic Module Standards and Controls
- Private Key (m-of-n) Multi-person Control
- Private Key Backup
- Private Key Archival
- Private Key Transfer Into or From a Cryptographic Module
- Other Aspects of Key Pair Management
- Computer Security Controls
- Network Security Controls
- Life Cycle Technical Controls
- Zone Signing
The purpose of this document is to enable stakeholders to determine the level of trust they wish to grant to the RIPE NCC DNSSEC management. It details the procedures and policies employed by the RIPE NCC in operating those zones for which it offers DNSSEC service.
This document conforms to the IETF Internet draft for a DNSSEC Practice Statement, or DPS (see: draft-ietf-dnsop-dnssec-dps-framework-01).
Document name and identification
DNSSEC Policy and Practice Statement or short DPS.
Community and Applicability
The zones maintained by the RIPE NCC follow a thin registry model. In this model, there is no intermediary between the owner of a zone (Registrant) and the operator of the parent zone (Registry).
All zones covered by this document have the RIPE NCC as a single registry. It is the responsibility of the registry to sign those zones and make their public keys available to the general public. The registry also enables its registrants to submit the public keys of their child zones in the form of Delegation Signer (DS) Resource Records. These are then included in the parent zone.
It is the responsibility of the registrant to ensure the proper signing of their child zones. The registrant is also responsible for keeping the public key material at the registry updated according to their needs.
Public key material published by the registry as a trust anchor can be used by anybody interested in using the zones as secure entry points for DNSSEC. The relying party needs to ensure that it is using the trust anchors according to the current Acceptable Use Policy (AUP) which is included at the top of each trust anchor file.
This DPS will be periodically reviewed and updated, as appropriate.
Specification administration organisation
RIPE Network Coordination Centre (RIPE NCC)
Attn.: DNS Services
1016 AB Amsterdam
Email: dns _at_ ripe _dot_ net
Specification Change Procedures
Any change to this document needs to be signed off by the manager of DNS services, a Senior Manager and the Information Security Officer of the RIPE NCC.
Publication and Repositories
Information on the DNSSEC keys used to sign the zones for which the RIPE NCC systems are authoritative is provided via a TLS secured website.
Publication of Key Signing Keys (KSK)
The RIPE NCC will publish its Key Signing Keys in two formats.
Trust Anchor Format
This format can be directly included into a BIND resolver as a trust-anchor. It is equal to the specification of the DNSKEY resource record except for the TTL and class parameters, which are intentionally left out.
Delegation Signer (DS) Format
In this format, the public key is presented in a hash representation according to the DS Resource Record specification. There is no TTL or class parameter provided in this format.
Access Controls on Repositories
All keys are available with PGP signatures generated with the current RIPE NCC key. It is highly recommended that you validate both the SSL certificate of the website and the PGP signature of trust-anchor files.
Registration, Modification and Removal of Delegation Signer (DS) Resource Records
A child zone can create a chain of trust by updating its
domain object in the RIPE Database and providing DS records provided in the
ds-rdata field. Similarly, during roll-over events, a child zone's DS records can be changed by updating its
domain object in the RIPE Database. If a child zone becomes unsigned, its DS record may be removed from its
domain object in the RIPE Database. The process is detailed in the Procedure for Requesting DNSSEC Delegations
Method to Prove Possession of Private Key
During our pre-delegation checks, we will ensure that the DS records provided are available as DNSKEY records at the apex of the child zone. We will also check if these DNSKEYs are signed and verified against at least one of the supplied DS records.
Facility, Management and Operational Controls
Site location and construction
RIPE NCC operates multiple sites in the Netherlands. These include server-rooms in the RIPE NCC offices, cabinets in data centres, and a backup site outside of Amsterdam.
All of our facilities have restricted access, limited to authorised personnel.
Power and Air Conditioning
All facilities have Uninterruptible Power Supply (UPS) capabilities and air conditioning. The external data centre sites have redundant systems in place in the event of a power failure (the RIPE NCC offices do not have this redundancy).
To avoid the risk of water exposure, all of our facilities are on elevated floors two to five metres above ground level. Additionally, we have a back-up site outside of Amsterdam at around 30 metres above sea level.
Fire Prevention and Protection
All facilities have fire detectors and gas extinguishers.
Sensitive media is stored in a safe which is only accessible by RIPE NCC Senior Management and specifically designated personal.
Sensitive documents and materials are shredded before disposal. Media used to collect or transmit sensitive information is rendered unreadable before disposal.
Signer backups are stored on our storage systems spread across all of our data centers.
There are at least two DNSSEC Operator teams. Each team is composed of two persons designated by Senior Management of the RIPE NCC. Each team member holds a part of a password, which when combined grants that team access to the signer systems.
Tasks Requiring Separation of Duties
Any task performed on the signer systems requires a complete team, as described in Trusted Roles, to be present.
Qualifications, Experience and Clearance Requirements
Engineers taking part in the Trusted Roles have to have been working for the company for no less than one year and must have the qualifications necessary for the DNS engineer job role.
Should a new team be formed, this team will have to observe at least one regular key roll-over with an existing team.
Job Rotation Frequency and Sequence
No single team can perform regular key roll-overs more than twice in a row.
Contracting Personnel Requirements
No person outside of the specified Trusted Roles can get access to the signer systems. If necessary, a team can perform certain tasks with the guidance of an external contractor. At no time is the contractor allowed to be the person performing the tasks on the system.
Documentation Supplied to Personnel
The regular procedures for backup and restore are available to all personnel involved. If major alterations to those procedures are made, the engineers of those teams will be informed accordingly.
Audit Logging Procedures
Types of Events Recorded
Physical access to the facilities used for our signing systems is logged automatically on enter and exit. The main operation site requires personnel to be specifically granted permission to enter the suite in which the equipment is located and they will have to sign-in using a valid identification (passport, drivers licence, etc.).
Log messages from the signer systems will be sent securely to a logging system and recorded for audit purposes.
Protection of Audit Log
Audit logs of our main operation site are kept by an external data center operator. These logs are not available to any of our employees and cannot be modified at the request of any of our employees. Access to the audit logs of our own facilities is only available to the operations department.
Compromise and Disaster Recovery
Any relevant events relating to the secure operation of our systems will be announced to the RIPE DNS Working Group and RIPE ENUM Working Group mailing lists, as well as other fora appropriate at the time.
Incident and Compromise Handling Procedures
If an event leads to, or could lead to, a detected security compromise, we will perform an investigation to determine the nature of the incident. If we suspect the incident has compromised the private component of an active key, an emergency key roll-over procedure will be performed.
Entity Private Key Compromise Procedures
Upon the suspected or known compromise of a key, we will assess the situation, develop an action plan and implement the action plan with approval from the Information Security Officer and Senior Management.
When we perform an emergency roll-over for a compromised KSK, we will continue to operate this key for at least the minimum time specified to retrieve our public key trust anchors in the AUP.
Technical Security Controls
Key Pair Generation and Installation
Key Pair Generation
Both KSK and Zone Signing Key (ZSK) are generated on the signer systems using a Trusted Platform Module (TPM) chip.
Public Key Delivery
The public key is retrieved from the signer system via secure copy (SCP) and then published as detailed in the section Publication and Repositories.
Key Usage Purposes
A key must only be used for one zone and cannot be reused.
Private Key Protection and Cryptographic Module Engineering Controls
Cryptographic Module Standards and Controls
Systems used for signing the zones are FIPS 140-2 Level 2-certified.
Private Key (m-of-n) Multi-person Control
No access to unencrypted keys is available in the entire system. Access to the signer system is specified in the Trusted Roles section.
Private Key Backup
The signer system pushes a back-up onto our storage system every time an operation changes the system status. This back-up is encrypted using the on-board TPM chip. Access to the back-up archives is limited to persons designated by Senior Management.
Private Key Archival
Private keys can be restored from the back-ups specified above. Private keys are not archived on the signer system once they have been revoked.
Private Key Transfer Into or From a Cryptographic Module
Private keys can only be transferred off the system in encrypted form and restored onto the back-up system by the teams described in the Trusted Roles section.
Other Aspects of Key Pair Management
Public Key Archival
We are only publishing the public keys currently relevant to the operation of our zones. No archive of public keys past their revocation is available.
Key Usage Periods
KSKs will be rolled over annually and ZSKs will be rolled over once a month.
Computer Security Controls
RIPE NCC ensures that the systems maintaining key software and data files are Trustworthy Systems secure from unauthorized access. In addition, RIPE NCC limits access to production servers to those individuals with a valid business reason for such access. General application users do not have accounts on production servers.
Network Security Controls
Systems holding the signing infrastructure are inside a dedicated VLAN inside our network infrastructure. The only communications channel to those systems is through our firewall, which is limited to the minimal capabilities necessary for the operation of the system.
The signer systems securely sychronise their system clocks with a trusted time source inside our network.
Life Cycle Technical Controls
System Development Controls
We are using a third-party solution on our signer systems. We test new releases of this software in a lab environment provided by our supplier. Once these tests are concluded successfully, we do a staged roll-out of the new release onto our inactive signer system first, and then onto our active signer system.
Key Lengths and Algorithms
Key Signing Key
We use a key length of 2048 bits with RSA as the generation algorithm.
Zone Signing Key
We use a key length of 1024 bits with RSA as the generation algorithm.
Authenticated Denial of Existence
Authenticated denial of existence will be provided through the use of NSEC records as specified in RFC 4034.
Our signatures are created with the SHA1 hash using RSA.
Zone Signing Key Roll-over
We will roll the ZSK with a pre-publishing scheme as described in RFC 4641, section 126.96.36.199.
Key Signing Key Roll-over
We will roll the KSK with a double-signing scheme as described in RFC 4641, section 188.8.131.52.
Signature Life-time and Re-signing Frequency
We re-sign our zones daily with a signature lifetime of 30 days.
Resource Records Time-to-live
Equal to the TTL used for the SOA record
Equal to the minimum field of the SOA record
Equal to the lowest TTL of the record set covered
Equal to the TTL of the NS RRset