Skip to main content

DNSSEC Key Maintenance Procedure

Olaf Kolkman

Document ID: TBD
Date: September 2005

Abstract

This draft document describes RIPE NCC policy key distribution and maintenance during the deployment of DNSSEC in its service region.

Contents

1.0 Introduction
2.0 Proposed DNSSEC Key Procedure
3.0 References

1.0 Introduction

One of the main issues for early deployment of DNSSEC is key distribution and maintenance. For each zone that is signed, a key pair is created. The private part of that key pair is used to sign the zone, while the public key needs to be distributed to the DNS client. This means validating recursive nameservers to validate the data. DNSSEC allows public key distribution through the DNS, but this will only work if it is possible to build a chain of authority from a 'trust-anchor' through delegation from parents to child in each zone.

This 'trust-anchor' should ideally be the root. If there is no signed root, then all DNS clients that want to verify zone data will have to manually configure the zone keys. Maintenance of these keys is a process that does not scale well. We are working to come up with a solution to this issue.

The lack of key maintenance protocols is no reason to delay deployment of signed zones. Operators that configure 'trust-anchors' into their validating DNS clients will need to carefully maintain them. The 'trust-anchor' and the key signing key used to sign the zone remain must stay synchronised. If operators do not update their keys, then their zones might become invisible to DNS clients performing DNSSEC validation.

To avoid possible possible failures, the RIPE NCC will sign its zones using the policy proposed below.

2.0 Proposed DNSSEC Key Procedure

This procedure applies to each zone that the RIPE NCC will sign.

  • 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 a SEP flag set so that they can be distinguished from the ZSKs in the DNSKEY RR set.
  • The ZSK may be rolled without making any announcement. We will follow the 'pre-publish rollover scheme' as published in [1]. This will avoid breaks in the chain of trust.
  • During the first two years of deployment, the KSK of each signed zone will be rolled twice each year. The rollover scheme that we will follow is the 'double signature scheme' published in [1]. There will be an overlap of three months to allow zone administrators to configure their new key.
    o At t=0 KSK1 signs the keyset. At t=3months KSK1 and KSK2 sign the keyset. DNS clients are expected to configure KSK2 during the three months that follow. At t=6months only KSK2 signs the keyset until (at t=9 months) KSK3 is introduced and a new rollover starts.
    o All zones at the RIPE NCC will roll their KSK simultaneously.
  • The RIPE NCC will start generating signatures that are valid for one month. However, after announcing the change, it might decrease the signing validity period to the shortest operationally possible period. Also see [1] section 4.4.4.

The ZSK will be an RSA/SHA1 key of 1200 bits ([1] section 3.5)
The KSK will be an RSA/SHA1 key of 2048 bits.

The RIPE NCC will publish the KSKs to be used as 'trust-anchors' for our zones on a secure website. It will follow the format used in the 'trusted-keys' statement in BIND9 named configuration files.

The RIPE NCC would consider publishing its KSKs in appropriate registries that may emerge to facilitate the establishment of DNSSEC trust anchors.

Any changes to this procedure and other announcements will be signed with the RIPE NCC PGP key and published on a secure website and a dedicated mailing list.

3.0 References

[1] draft-ietf-dnsop-dnssec-operational-practices-04.txt (work in progress).