Request for Comments: 4641 R. Gieben
Obsoletes: 2541 NLnet Labs
Category: Informational September 2006
DNSSEC Operational Practices
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a set of practices for operating the DNS with
security extensions (DNSSEC). The target audience is zone
administrators deploying DNSSEC.
The document discusses operational aspects of using keys and
signatures in the DNS. It discusses issues of key generation, key
storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 2541, as it covers more operational
ground and gives more up-to-date requirements with respect to key
sizes and the new DNSSEC specification.
Table of Contents
1. Introduction ....................................................3
1.1. The Use of the Term ’key’ ..................................4
1.2. Time Definitions ...........................................4
2. Keeping the Chain of Trust Intact ...............................5
3. Keys Generation and Storage .....................................6
3.1. Zone and Key Signing Keys ..................................6
3.1.1. Motivations for the KSK and ZSK Separation ..........6
3.1.2. KSKs for High-Level Zones ...........................7
3.2. Key Generation .............................................8
3.3. Key Effectivity Period .....................................8
3.4. Key Algorithm ..............................................9
3.5. Key Sizes ..................................................9
3.6. Private Key Storage .......................................11
4. Signature Generation, Key Rollover, and Related Policies .......12
4.1. Time in DNSSEC ............................................12
4.1.1. Time Considerations ................................12
4.2. Key Rollovers .............................................14
4.2.1. Zone Signing Key Rollovers .........................14
4.2.1.1. Pre-Publish Key Rollover ..................15
4.2.1.2. Double Signature Zone Signing Key
Rollover ..................................17
4.2.1.3. Pros and Cons of the Schemes ..............18
4.2.2. Key Signing Key Rollovers ..........................18
4.2.3. Difference Between ZSK and KSK Rollovers ...........20
4.2.4. Automated Key Rollovers ............................21
4.3. Planning for Emergency Key Rollover .......................21
4.3.1. KSK Compromise .....................................22
4.3.1.1. Keeping the Chain of Trust Intact .........22
4.3.1.2. Breaking the Chain of Trust ...............23
4.3.2. ZSK Compromise .....................................23
4.3.3. Compromises of Keys Anchored in Resolvers ..........24
4.4. Parental Policies .........................................24
4.4.1. Initial Key Exchanges and Parental Policies
Considerations .....................................24
4.4.2. Storing Keys or Hashes? ............................25
4.4.3. Security Lameness ..................................25
4.4.4. DS Signature Validity Period .......................26
5. Security Considerations ........................................26
6. Acknowledgments ................................................26
7. References .....................................................27
7.1. Normative References ......................................27
7.2. Informative References ....................................28
Appendix A. Terminology ...........................................30
Appendix B. Zone Signing Key Rollover How-To ......................31
Appendix C. Typographic Conventions ...............................32
1. Introduction
This document describes how to run a DNS Security (DNSSEC)-enabled
environment. It is intended for operators who have knowledge of the
DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
newly introduced Resource Records (RRs), and RFC 4035 [6] for the
protocol changes.
During workshops and early operational deployment tests, operators
and system administrators have gained experience about operating the
DNS with security extensions (DNSSEC). This document translates
these experiences into a set of practices for zone administrators.
At the time of writing, there exists very little experience with
DNSSEC in production environments; this document should therefore
explicitly not be seen as representing ’Best Current Practices’.
The procedures herein are focused on the maintenance of signed zones
(i.e., signing and publishing zones on authoritative servers). It is
intended that maintenance of zones such as re-signing or key
rollovers be transparent to any verifying clients on the Internet.
The structure of this document is as follows. In Section 2, we
discuss the importance of keeping the "chain of trust" intact.
Aspects of key generation and storage of private keys are discussed
in Section 3; the focus in this section is mainly on the private part
of the key(s). Section 4 describes considerations concerning the
public part of the keys. Since these public keys appear in the DNS
one has to take into account all kinds of timing issues, which are
discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
rollover, or supercession, of keys. Finally, Section 4.4 discusses
considerations on how parents deal with their children’s public keys
in order to maintain chains of trust.
The typographic conventions used in this document are explained in
Appendix C.
Since this is a document with operational suggestions and there are
no protocol specifications, the RFC 2119 [7] language does not apply.
This document obsoletes RFC 2541 [12] to reflect the evolution of the
underlying DNSSEC protocol since then. Changes in the choice of
cryptographic algorithms, DNS record types and type names, and the
parent-child key and signature exchange demanded a major rewrite and
additional information and explanation.
1.1. The Use of the Term ’key’
It is assumed that the reader is familiar with the concept of
asymmetric keys on which DNSSEC is based (public key cryptography
[17]). Therefore, this document will use the term ’key’ rather
loosely. Where it is written that ’a key is used to sign data’ it is
assumed that the reader understands that it is the private part of
the key pair that is used for signing. It is also assumed that the
reader understands that the public part of the key pair is published
in the DNSKEY Resource Record and that it is the public part that is
used in key exchanges.
1.2. Time Definitions
In this document, we will be using a number of time-related terms.
The following definitions apply:
o "Signature validity period" The period that a signature is valid.
It starts at the time specified in the signature inception field
of the RRSIG RR and ends at the time specified in the expiration
field of the RRSIG RR.
o "Signature publication period" Time after which a signature (made
with a specific key) is replaced with a new signature (made with
the same key). This replacement takes place by publishing the
relevant RRSIG in the master zone file. After one stops
publishing an RRSIG in a zone, it may take a while before the
RRSIG has expired from caches and has actually been removed from
the DNS.
o "Key effectivity period" The period during which a key pair is
expected to be effective. This period is defined as the time
between the first inception time stamp and the last expiration
date of any signature made with this key, regardless of any
discontinuity in the use of the key. The key effectivity period
can span multiple signature validity periods.
o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
value of the TTLs from the complete set of RRs in a zone. Note
that the minimum TTL is not the same as the MINIMUM field in the
SOA RR. See [11] for more information.
2. Keeping the Chain of Trust Intact
Maintaining a valid chain of trust is important because broken chains
of trust will result in data being marked as Bogus (as defined in [4]
Section 5), which may cause entire (sub)domains to become invisible
to verifying clients. The administrators of secured zones have to
realize that their zone is, to verifying clients, part of a chain of
trust.
As mentioned in the introduction, the procedures herein are intended
to ensure that maintenance of zones, such as re-signing or key
rollovers, will be transparent to the verifying clients on the
Internet.
Administrators of secured zones will have to keep in mind that data
published on an authoritative primary server will not be immediately
seen by verifying clients; it may take some time for the data to be
transferred to other secondary authoritative nameservers and clients
may be fetching data from caching non-authoritative servers. In this
light, note that the time for a zone transfer from master to slave is
negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
It increases when full zone transfers (AXFR) are used in combination
with NOTIFY. It increases even more if you rely on full zone
transfers based on only the SOA timing parameters for refresh.
For the verifying clients, it is important that data from secured
zones can be used to build chains of trust regardless of whether the
data came directly from an authoritative server, a caching
nameserver, or some middle box. Only by carefully using the
available timing parameters can a zone administrator ensure that the
data necessary for verification can be obtained.
The responsibility for maintaining the chain of trust is shared by
administrators of secured zones in the chain of trust. This is most
obvious in the case of a ’key compromise’ when a trade-off between
maintaining a valid chain of trust and replacing the compromised keys
as soon as possible must be made. Then zone administrators will have
to make a trade-off, between keeping the chain of trust intact --
thereby allowing for attacks with the compromised key -- or
deliberately breaking the chain of trust and making secured
subdomains invisible to security-aware resolvers. Also see Section
4.3.
3. Keys Generation and Storage
This section describes a number of considerations with respect to the
security of keys. It deals with the generation, effectivity period,
size, and storage of private keys.
3.1. Zone and Key Signing Keys
The DNSSEC validation protocol does not distinguish between different
types of DNSKEYs. All DNSKEYs can be used during the validation. In
practice, operators use Key Signing and Zone Signing Keys and use the
so-called Secure Entry Point (SEP) [3] flag to distinguish between
them during operations. The dynamics and considerations are
discussed below.
To make zone re-signing and key rollover procedures easier to
implement, it is possible to use one or more keys as Key Signing Keys
(KSKs). These keys will only sign the apex DNSKEY RRSet in a zone.
Other keys can be used to sign all the RRSets in a zone and are
referred to as Zone Signing Keys (ZSKs). In this document, we assume
that KSKs are the subset of keys that are used for key exchanges with
the parent and potentially for configuration as trusted anchors --
the SEP keys. In this document, we assume a one-to-one mapping
between KSK and SEP keys and we assume the SEP flag to be set on all
KSKs.
3.1.1. Motivations for the KSK and ZSK Separation
Differentiating between the KSK and ZSK functions has several
advantages:
o No parent/child interaction is required when ZSKs are updated.
o The KSK can be made stronger (i.e., using more bits in the key
material). This has little operational impact since it is only
used to sign a small fraction of the zone data. Also, the KSK is
only used to verify the zone’s key set, not for other RRSets in
the zone.
o As the KSK is only used to sign a key set, which is most probably
updated less frequently than other data in the zone, it can be
stored separately from and in a safer location than the ZSK.
o A KSK can have a longer key effectivity period.
For almost any method of key management and zone signing, the KSK is
used less frequently than the ZSK. Once a key set is signed with the
KSK, all the keys in the key set can be used as ZSKs. If a ZSK is
compromised, it can be simply dropped from the key set. The new key
set is then re-signed with the KSK.
Given the assumption that for KSKs the SEP flag is set, the KSK can
be distinguished from a ZSK by examining the flag field in the DNSKEY
RR. If the flag field is an odd number it is a KSK. If it is an
even number it is a ZSK.
The Zone Signing Key can be used to sign all the data in a zone on a
regular basis. When a Zone Signing Key is to be rolled, no
interaction with the parent is needed. This allows for signature
validity periods on the order of days.
The Key Signing Key is only to be used to sign the DNSKEY RRs in a
zone. If a Key Signing Key is to be rolled over, there will be
interactions with parties other than the zone administrator. These
can include the registry of the parent zone or administrators of
verifying resolvers that have the particular key configured as secure
entry points. Hence, the key effectivity period of these keys can
and should be made much longer. Although, given a long enough key,
the key effectivity period can be on the order of years, we suggest
planning for a key effectivity on the order of a few months so that a
key rollover remains an operational routine.
3.1.2. KSKs for High-Level Zones
Higher-level zones are generally more sensitive than lower-level
zones. Anyone controlling or breaking the security of a zone thereby
obtains authority over all of its subdomains (except in the case of
resolvers that have locally configured the public key of a subdomain,
in which case this, and only this, subdomain wouldn’t be affected by
the compromise of the parent zone). Therefore, extra care should be
taken with high-level zones, and strong keys should be used.
The root zone is the most critical of all zones. Someone controlling
or compromising the security of the root zone would control the
entire DNS namespace of all resolvers using that root zone (except in
the case of resolvers that have locally configured the public key of
a subdomain). Therefore, the utmost care must be taken in the
securing of the root zone. The strongest and most carefully handled
keys should be used. The root zone private key should always be kept
off-line.
Many resolvers will start at a root server for their access to and
authentication of DNS data. Securely updating the trust anchors in
an enormous population of resolvers around the world will be
extremely difficult.
3.2. Key Generation
Careful generation of all keys is a sometimes overlooked but
absolutely essential element in any cryptographically secure system.
The strongest algorithms used with the longest keys are still of no
use if an adversary can guess enough to lower the size of the likely
key space so that it can be exhaustively searched. Technical
suggestions for the generation of random keys will be found in RFC
4086 [14]. One should carefully assess if the random number
generator used during key generation adheres to these suggestions.
Keys with a long effectivity period are particularly sensitive as
they will represent a more valuable target and be subject to attack
for a longer time than short-period keys. It is strongly recommended
that long-term key generation occur off-line in a manner isolated
from the network via an air gap or, at a minimum, high-level secure
hardware.
3.3. Key Effectivity Period
For various reasons, keys in DNSSEC need to be changed once in a
while. The longer a key is in use, the greater the probability that
it will have been compromised through carelessness, accident,
espionage, or cryptanalysis. Furthermore, when key rollovers are too
rare an event, they will not become part of the operational habit and
there is risk that nobody on-site will remember the procedure for
rollover when the need is there.
From a purely operational perspective, a reasonable key effectivity
period for Key Signing Keys is 13 months, with the intent to replace
them after 12 months. An intended key effectivity period of a month
is reasonable for Zone Signing Keys.
For key sizes that match these effectivity periods, see Section 3.5.
As argued in Section 3.1.2, securely updating trust anchors will be
extremely difficult. On the other hand, the "operational habit"
argument does also apply to trust anchor reconfiguration. If a short
key effectivity period is used and the trust anchor configuration has
to be revisited on a regular basis, the odds that the configuration
tends to be forgotten is smaller. The trade-off is against a system
that is so dynamic that administrators of the validating clients will
not be able to follow the modifications.
Key effectivity periods can be made very short, as in a few minutes.
But when replacing keys one has to take the considerations from
Section 4.1 and Section 4.2 into account.
3.4. Key Algorithm
There are currently three different types of algorithms that can be
used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The
latter is fairly new and has yet to be standardized for usage in
DNSSEC.
RSA has been developed in an open and transparent manner. As the
patent on RSA expired in 2000, its use is now also free.
DSA has been developed by the National Institute of Standards and
Technology (NIST). The creation of signatures takes roughly the same
time as with RSA, but is 10 to 40 times as slow for verification
[17].
We suggest the use of RSA/SHA-1 as the preferred algorithm for the
key. The current known attacks on RSA can be defeated by making your
key longer. As the MD5 hashing algorithm is showing cracks, we
recommend the usage of SHA-1.
At the time of publication, it is known that the SHA-1 hash has
cryptanalysis issues. There is work in progress on addressing these
issues. We recommend the use of public key algorithms based on
hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
algorithms are available in protocol specifications (see [19] and
[20]) and implementations.
3.5. Key Sizes
When choosing key sizes, zone administrators will need to take into
account how long a key will be used, how much data will be signed
during the key publication period (see Section 8.10 of [17]), and,
optionally, how large the key size of the parent is. As the chain of
trust really is "a chain", there is not much sense in making one of
the keys in the chain several times larger then the others. As
always, it’s the weakest link that defines the strength of the entire
chain. Also see Section 3.1.1 for a discussion of how keys serving
different roles (ZSK vs. KSK) may need different key sizes.
Generating a key of the correct size is a difficult problem; RFC 3766
[13] tries to deal with that problem. The first part of the
selection procedure in Section 1 of the RFC states:
1. Determine the attack resistance necessary to satisfy the
security requirements of the application. Do this by
estimating the minimum number of computer operations that the
attacker will be forced to do in order to compromise the
security of the system and then take the logarithm base two of
that number. Call that logarithm value "n".
A 1996 report recommended 90 bits as a good all-around choice
for system security. The 90 bit number should be increased by
about 2/3 bit/year, or about 96 bits in 2005.
[13] goes on to explain how this number "n" can be used to calculate
the key sizes in public key cryptography. This culminated in the
table given below (slightly modified for our purpose):
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
| for attack | key size | modulus size |
| resistance | (bits) | (bits) |
| (bits) | | |
+-------------+-----------+--------------+
| 70 | 70 | 947 |
| 80 | 80 | 1228 |
| 90 | 90 | 1553 |
| 100 | 100 | 1926 |
| 150 | 150 | 4575 |
| 200 | 200 | 8719 |
| 250 | 250 | 14596 |
+-------------+-----------+--------------+
The key sizes given are rather large. This is because these keys are
resilient against a trillionaire attacker. Assuming this rich
attacker will not attack your key and that the key is rolled over
once a year, we come to the following recommendations about KSK
sizes: 1024 bits for low-value domains, 1300 bits for medium-value
domains, and 2048 bits for high-value domains.
Whether a domain is of low, medium, or high value depends solely on
the views of the zone owner. One could, for instance, view leaf
nodes in the DNS as of low value, and top-level domains (TLDs) or the
root zone of high value. The suggested key sizes should be safe for
the next 5 years.
As ZSKs can be rolled over more easily (and thus more often), the key
sizes can be made smaller. But as said in the introduction of this
paragraph, making the ZSKs’ key sizes too small (in relation to the
KSKs’ sizes) doesn’t make much sense. Try to limit the difference in
size to about 100 bits.
Note that nobody can see into the future and that these key sizes are
only provided here as a guide. Further information can be found in
[16] and Section 7.5 of [17]. It should be noted though that [16] is
already considered overly optimistic about what key sizes are
considered safe.
One final note concerning key sizes. Larger keys will increase the
sizes of the RRSIG and DNSKEY records and will therefore increase the
chance of DNS UDP packet overflow. Also, the time it takes to
validate and create RRSIGs increases with larger keys, so don’t