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).
DNSSEC Policy and Practice Statement or short DPS.
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.
RIPE Network Coordination Centre (RIPE NCC)
Attn.: DNS Services
Stationsplein 11
1012 AB Amsterdam
The Netherlands
Email: [email protected]
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.
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.
The RIPE NCC will publish its Key Signing Keys in two formats.
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.
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.
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.
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
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.
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.
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.
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.
Any task performed on the signer systems requires a complete team, as described in Trusted Roles, to be present.
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.
No single team can perform regular key roll-overs more than twice in a row.
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.
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.
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.
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.
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.
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.
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.
Both KSK and Zone Signing Key (ZSK) are generated on the signer systems using a Trusted Platform Module (TPM) chip.
The public key is retrieved from the signer system via secure copy (SCP) and then published as detailed in the section Publication and Repositories.
A key must only be used for one zone and cannot be reused.
Systems used for signing the zones are FIPS 140-2 Level 2-certified.
No access to unencrypted keys is available in the entire system. Access to the signer system is specified in the Trusted Roles section.
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 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 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.
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.
KSKs will be rolled over annually and ZSKs will be rolled over once a month.
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.
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.
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.
We use a key length of 2048 bits with RSA as the generation algorithm.
We use a key length of 1024 bits with RSA as the generation algorithm.
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.
We will roll the ZSK with a pre-publishing scheme as described in RFC 4641, section 4.2.1.1.
We will roll the KSK with a double-signing scheme as described in RFC 4641, section 4.2.1.2.
We re-sign our zones daily with a signature lifetime of 30 days.
| Record type | TTL |
|---|---|
DNSKEY |
Equal to the TTL used for the SOA record |
NSEC |
Equal to the minimum field of the SOA record |
RRSIG |
Equal to the lowest TTL of the record set covered |
DS |
Equal to the TTL of the NS RRset |