Internet Engineering Task Force (IETF) O. Kolkman
Request for Comments: 6781 W. Mekking
Obsoletes: 4641 NLnet Labs
Category: Informational R. Gieben
ISSN: 2070-1721 SIDN Labs
December 2012 DNSSEC Operational Practices, Version 2
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 4641, as it covers more operational
ground and gives more up-to-date requirements with respect to key
sizes and the DNSSEC operations.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
Table of Contents
1. Introduction ....................................................41.1. The Use of the Term 'key' ..................................51.2. Time Definitions ...........................................62. Keeping the Chain of Trust Intact ...............................63. Key Generation and Storage ......................................73.1. Operational Motivation for Zone Signing Keys and
Key Signing Keys ...........................................83.2. Practical Consequences of KSK and ZSK Separation ..........103.2.1. Rolling a KSK That Is Not a Trust Anchor ...........103.2.2. Rolling a KSK That Is a Trust Anchor ...............113.2.3. The Use of the SEP Flag ............................123.3. Key Effectivity Period ....................................123.4. Cryptographic Considerations ..............................143.4.1. Signature Algorithm ................................143.4.2. Key Sizes ..........................................143.4.3. Private Key Storage ................................163.4.4. Key Generation .....................................173.4.5. Differentiation for 'High-Level' Zones? ............17
5. "Next Record" Types ............................................515.1. Differences between NSEC and NSEC3 ........................515.2. NSEC or NSEC3 .............................................525.3. NSEC3 Parameters ..........................................535.3.1. NSEC3 Algorithm ....................................535.3.2. NSEC3 Iterations ...................................535.3.3. NSEC3 Salt .........................................545.3.4. Opt-Out ............................................546. Security Considerations ........................................547. Acknowledgments ................................................558. Contributors ...................................................559. References .....................................................569.1. Normative References ......................................569.2. Informative References ....................................56Appendix A. Terminology ...........................................59Appendix B. Typographic Conventions ...............................61Appendix C. Transition Figures for Special Cases of Algorithm
Rollovers .............................................64Appendix D. Transition Figure for Changing DNS Operators ..........68Appendix E. Summary of Changes from RFC 4641 ......................701. 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 [RFC1034] and RFC 1035 [RFC1035]) and want to
deploy DNSSEC (RFC 4033 [RFC4033], RFC 4034 [RFC4034], RFC 4035
[RFC4035], and RFC 5155 [RFC5155]). The focus of the document is on
serving authoritative DNS information and is aimed at zone owners,
name server operators, registries, registrars, and registrants. It
assumes that there is no direct relationship between those entities
and the operators of validating recursive name servers (validators).
During workshops and early operational deployment, 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.
Although the DNS Root has been signed since July 15, 2010 and now
more than 80 secure delegations are provisioned in the root, at the
time of this writing there still exists relatively little experience
with DNSSEC in production environments below the Top-Level Domain
(TLD) level; this document should therefore explicitly not be seen as
representing 'Best Current Practices'. Instead, it describes the
decisions that should be made when deploying DNSSEC, gives the
choices available for each one, and provides some operational
guidelines. The document does not give strong recommendations. That
may be the subject for a future version of this document.
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.
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 keys are discussed in
Section 3; the focus in this section is mainly on the security of the
private part of the key(s). Section 4 describes considerations
concerning the public part of the keys. Sections 4.1 and 4.2 deal
with the rollover, or replacement, of keys. Section 4.3 discusses
considerations on how parents deal with their children's public keys
in order to maintain chains of trust. Section 4.4 covers all kinds
of timing issues around key publication. Section 5 covers the
considerations regarding selecting and using the NSEC or NSEC3
[RFC5155] Resource Record.
The typographic conventions used in this document are explained in
Since we describe operational suggestions and there are no protocol
specifications, the RFC 2119 [RFC2119] language does not apply to
this document, though we do use quotes from other documents that do
include the RFC 2119 language.
This document obsoletes RFC 4641 [RFC4641].
1.1. The Use of the Term 'key'
It is assumed that the reader is familiar with the concept of
asymmetric cryptography, or public-key cryptography, on which DNSSEC
is based (see the definition of 'asymmetric cryptography' in RFC 4949
[RFC4949]). 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 (DNSKEY RR) and that it is the public
part that is used in signature verification.
1.2. Time Definitions
In this document, we will be using a number of time-related terms.
The following definitions apply:
Signature validity period: The period that a signature is valid. It
starts at the (absolute) time specified in the signature inception
field of the RRSIG RR and ends at the (absolute) time specified in
the expiration field of the RRSIG RR. The document sometimes also
uses the term 'validity period', which means the same.
Signature publication period: The period that a signature is
published. It starts at the time the signature is introduced in
the zone for the first time and ends at the time when the
signature is removed or replaced with a new signature. 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.
Key effectivity period: The period during which a key pair is
expected to be effective. It is defined as the time between the
earliest 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.
Maximum/Minimum Zone Time to Live (TTL): The maximum or minimum
value of the TTLs from the complete set of RRs in a zone, that are
used by validators or resolvers. Note that the minimum TTL is not
the same as the MINIMUM field in the SOA RR. See RFC 2308
[RFC2308] 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
RFC 4033 [RFC4033] Section 5), which may cause entire (sub)domains to
become invisible to verifying clients. The administrators of secured
zones need to realize that, to verifying clients, their zone is 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
Administrators of secured zones will need 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 name servers and
clients may be fetching data from caching non-authoritative servers.
In this light, note that the time until the data is available on the
slave can be negligible when using NOTIFY [RFC1996] and Incremental
Zone Transfer (IXFR) [RFC1995]. It increases when Authoritative
(full) Zone Transfers (AXFRs) are used in combination with NOTIFY.
It increases even more if you rely on the full zone transfers being
based only on 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 name
server, 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 tradeoff must be
made between maintaining a valid chain of trust and replacing the
compromised keys as soon as possible. Then zone administrators will
have to decide 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.2).
3. Key Generation and Storage
This section describes a number of considerations with respect to the
use of keys. For the design of an operational procedure for key
generation and storage, a number of decisions need to be made:
o Does one differentiate between Zone Signing Keys and Key Signing
Keys or is the use of one type of key sufficient?
o Are Key Signing Keys (likely to be) in use as trust anchors
o What are the timing parameters that are allowed by the operational
o What are the cryptographic parameters that fit the operational
The following section discusses the considerations that need to be
taken into account when making those choices.
3.1. Operational Motivation for Zone Signing Keys and Key Signing Keys
The DNSSEC validation protocol does not distinguish between different
types of DNSKEYs. The motivations to differentiate between keys are
purely operational; validators will not make a distinction.
For operational reasons, described below, it is possible to designate
one or more keys to have the role of 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 other RRsets in a zone that require
signatures. They are referred to as Zone Signing Keys (ZSKs). In
cases where the differentiation between the KSK and ZSK is not made,
i.e., where keys have the role of both KSK and ZSK, we talk about a
Single-Type Signing Scheme.
If the two functions are separated, then for almost any method of key
management and zone signing, the KSK is used less frequently than the
ZSK. Once a DNSKEY RRset is signed with the KSK, all the keys in the
RRset can be used as ZSKs. If there has been an event that increases
the risk that a ZSK is compromised, it can be simply replaced with a
ZSK rollover. The new RRset is then re-signed with the KSK.
Changing a key that is a Secure Entry Point (SEP) [RFC4034] for a
zone can be relatively expensive, as it involves interaction with
third parties: When a key is only pointed to by a Delegation Signer
(DS) [RFC4034] record in the parent zone, one needs to complete the
interaction with the parent and wait for the updated DS record to
appear in the DNS. In the case where a key is configured as a trust
anchor, one has to wait until one has sufficient confidence that all
trust anchors have been replaced. In fact, it may be that one is not
able to reach the complete user-base with information about the key
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; otherwise, it is
There is also a risk that keys can be compromised through theft or
loss. For keys that are installed on file-systems of name servers
that are connected to the network (e.g., for dynamic updates), that
risk is relatively high. Where keys are stored on Hardware Security
Modules (HSMs) or stored off-line, such risk is relatively low.
However, storing keys off-line or with more limitations on access
control has a negative effect on the operational flexibility. By
separating the KSK and ZSK functionality, these risks can be managed
while making the tradeoff against the involved costs. For example, a
KSK can be stored off-line or with more limitations on access control
than ZSKs, which need to be readily available for operational
purposes such as the addition or deletion of zone data. A KSK stored
on a smartcard that is kept in a safe, combined with a ZSK stored on
a file-system accessible by operators for daily routine use, may
provide better protection against key compromise without losing much
operational flexibility. It must be said that some HSMs give the
option to have your keys online, giving more protection and hardly
affecting the operational flexibility. In those cases, a KSK-ZSK
split is not more beneficial than the Single-Type Signing Scheme.
It is worth mentioning that there's not much point in obsessively
protecting the key if you don't protect the zone files, which also
live on the file-systems.
Finally, there is a risk of cryptanalysis of the key material. The
costs of such analysis are correlated to the length of the key.
However, cryptanalysis arguments provide no strong motivation for a
KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK,
whereby the KSK effectivity period is X times the ZSK effectivity
period. Then, in order for the resistance to cryptanalysis to be the
same for the KSK and the ZSK, the KSK needs to be X times stronger
than the ZSK. Since for all practical purposes X will be somewhere
on the order of 10 to 100, the associated key sizes will vary only by
about a byte in size for symmetric keys. When translated to
asymmetric keys, the size difference is still too insignificant to
warrant a key-split; it only marginally affects the packet size and
The arguments for differentiation between the ZSK and KSK are weakest
o the exposure to risk is low (e.g., when keys are stored on HSMs);
o one can be certain that a key is not used as a trust anchor;
o maintenance of the various keys cannot be performed through tools
(is prone to human error); and
o the interaction through the child-parent provisioning chain -- in
particular, the timely appearance of a new DS record in the parent
zone in emergency situations -- is predictable.
If the above arguments hold, then the costs of the operational
complexity of a KSK-ZSK split may outweigh the costs of operational
flexibility, and choosing a Single-Type Signing Scheme is a
reasonable option. In other cases, we advise that the separation
between KSKs and ZSKs is made.
3.2. Practical Consequences of KSK and ZSK Separation
A key that acts only as a Zone Signing Key is used to sign all the
data except the DNSKEY RRset in a zone on a regular basis. When a
ZSK is to be rolled, no interaction with the parent is needed. This
allows for a relatively short key effectivity period.
A key with only the Key Signing Key role is to be used to sign the
DNSKEY RRs in a zone. If a KSK is to be rolled, there may be
interactions with other parties. These can include the
administrators of the parent zone or administrators of verifying
resolvers that have the particular key configured as secure entry
points. In the latter case, everyone relying on the trust anchor
needs to roll over to the new key, a process that may be subject to
stability costs if automated trust anchor rollover mechanisms (e.g.,
RFC 5011 [RFC5011]) are not in place. Hence, the key effectivity
period of these keys can and should be made much longer.
3.2.1. Rolling a KSK That Is Not a Trust Anchor
There are three schools of thought on rolling a KSK that is not a
1. It should be done frequently and regularly (possibly every few
months), so that a key rollover remains an operational routine.
2. It should be done frequently but irregularly. "Frequently" means
every few months, again based on the argument that a rollover is
a practiced and common operational routine; "irregular" means
with a large jitter, so that third parties do not start to rely
on the key and will not be tempted to configure it as a trust
3. It should only be done when it is known or strongly suspected
that the key can be or has been compromised, or in conjunction
with operator change policies and procedures, like when a new
algorithm or key storage is required.
There is no widespread agreement on which of these three schools of
thought is better for different deployments of DNSSEC. There is a
stability cost every time a non-anchor KSK is rolled over, but it is
possibly low if the communication between the child and the parent is
good. On the other hand, the only completely effective way to tell
if the communication is good is to test it periodically. Thus,
rolling a KSK with a parent is only done for two reasons: to test and
verify the rolling system to prepare for an emergency, and in the
case of (preventing) an actual emergency.
Finally, in most cases a zone administrator cannot be fully certain
that the zone's KSK is not in use as a trust anchor somewhere. While
the configuration of trust anchors is not the responsibility of the
zone administrator, there may be stability costs for the validator
administrator that (wrongfully) configured the trust anchor when the
zone administrator rolls a KSK.
3.2.2. Rolling a KSK That Is a Trust Anchor
The same operational concerns apply to the rollover of KSKs that are
used as trust anchors: If a trust anchor replacement is done
incorrectly, the entire domain that the trust anchor covers will
become Bogus until the trust anchor is corrected.
In a large number of cases, it will be safe to work from the
assumption that one's keys are not in use as trust anchors. If a
zone administrator publishes a DNSSEC signing policy and/or a DNSSEC
practice statement [DNSSEC-DPS], that policy or statement should be
explicit regarding whether or not the existence of trust anchors will
be taken into account. There may be cases where local policies
enforce the configuration of trust anchors on zones that are mission
critical (e.g., in enterprises where the trust anchor for the
enterprise domain is configured in the enterprise's validator). It
is expected that the zone administrators are aware of such
One can argue that because of the difficulty of getting all users of
a trust anchor to replace an old trust anchor with a new one, a KSK
that is a trust anchor should never be rolled unless it is known or
strongly suspected that the key has been compromised. In other
words, the costs of a KSK rollover are prohibitively high because
some users cannot be reached.
However, the "operational habit" argument also applies to trust
anchor reconfiguration at the clients' validators. 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 are smaller. In fact, the costs for those
users can be minimized by automating the rollover with RFC 5011
[RFC5011] and by rolling the key regularly (and advertising such) so
that the operators of validating resolvers will put the appropriate
mechanism in place to deal with these stability costs: In other
words, budget for these costs instead of incurring them unexpectedly.
It is therefore preferable to roll KSKs that are expected to be used
as trust anchors on a regular basis if and only if those rollovers
can be tracked using standardized (e.g., RFC 5011 [RFC5011])
3.2.3. The Use of the SEP Flag
The so-called SEP [RFC4035] flag can be used to distinguish between
keys that are intended to be used as the secure entry point into the
zone when building chains of trust, i.e., they are (to be) pointed to
by parental DS RRs or configured as a trust anchor.
While the SEP flag does not play any role in validation, it is used
in practice for operational purposes such as for the rollover
mechanism described in RFC 5011 [RFC5011]. The common convention is
to set the SEP flag on any key that is used for key exchanges with
the parent and/or potentially used for configuration as a trust
anchor. Therefore, it is suggested that the SEP flag be set on keys
that are used as KSKs and not on keys that are used as ZSKs, while in
those cases where a distinction between a KSK and ZSK is not made
(i.e., for a Single-Type Signing Scheme), it is suggested that the
SEP flag be set on all keys.
Note: Some signing tools may assume a KSK/ZSK split and use the
(non-)presence of the SEP flag to determine which key is to be used
for signing zone data; these tools may get confused when a Single-
Type Signing Scheme is used.
3.3. Key Effectivity Period
In general, the available key length sets an upper limit on the key
effectivity period. For all practical purposes, it is sufficient to
define the key effectivity period based on purely operational
requirements and match the key length to that value. Ignoring the
operational perspective, a reasonable effectivity period for KSKs
that have corresponding DS records in the parent zone is on the order
of two decades or longer. That is, if one does not plan to test the
rollover procedure, the key should be effective essentially forever
and only rolled over in case of emergency.
When one opts for a regular key rollover, a reasonable key
effectivity period for KSKs that have a parent zone is one year,
meaning you have the intent to replace them after 12 months. The key
effectivity period is merely a policy parameter and should not be
considered a constant value. For example, the real key effectivity
period may be a little bit longer than 12 months, because not all
actions needed to complete the rollover could be finished in time.
As argued above, this annual rollover gives an operational practice
of rollovers for both the zone and validator administrators.
Besides, in most environments a year is a time span that is easily
planned and communicated.
Where keys are stored online and the exposure to various threats of
compromise is fairly high, an intended key effectivity period of a
month is reasonable for Zone Signing Keys.
Although very short key effectivity periods are theoretically
possible, when replacing keys one has to take into account the
rollover considerations discussed in Sections 4.1 and 4.4. Key
replacement endures for a couple of Maximum Zone TTLs, depending on
the rollover scenario. Therefore, a multiple of Maximum Zone TTL
durations is a reasonable lower limit on the key effectivity period.
Forcing a shorter key effectivity period will result in an
unnecessary and inconveniently large DNSKEY RRset published in the
The motivation for having the ZSK's effectivity period shorter than
the KSK's effectivity period is rooted in the operational
consideration that it is more likely that operators have more
frequent read access to the ZSK than to the KSK. Thus, in cases
where the ZSK cannot be afforded the same level of protection as the
KSK (such as when zone keys are kept online), and where the risk of
unauthorized disclosure of the ZSK's private key is not negligible
(e.g., when HSMs are not in use), the ZSK's effectivity period should
be kept shorter than the KSK's effectivity period.
In fact, if the risk of loss, theft, or other compromise is the same
for a ZSK and a KSK, there is little reason to choose different
effectivity periods for ZSKs and KSKs. And when the split between
ZSKs and KSKs is not made, the argument is redundant.
There are certainly cases in which the use of a Single-Type Signing
Scheme with a long key effectivity period is a good choice, for
example, where the costs and risks of compromise, and the costs and
risks involved with having to perform an emergency roll, are low.
3.4. Cryptographic Considerations
3.4.1. Signature Algorithm
At the time of this writing, there are three types of signature
algorithms that can be used in DNSSEC: RSA, Digital Signature
Algorithm (DSA), and GOST. Proposals for other algorithms are in the
making. All three are fully specified in many freely available
documents and are widely considered to be patent-free. The creation
of signatures with RSA and DSA takes roughly the same time, but DSA
is about ten times slower for signature verification. Also note
that, in the context of DNSSEC, DSA is limited to a maximum of
We suggest the use of RSA/SHA-256 as the preferred signature
algorithm and RSA/SHA-1 as an alternative. Both have advantages and
disadvantages. RSA/SHA-1 has been deployed for many years, while
RSA/SHA-256 has only begun to be deployed. On the other hand, it is
expected that if effective attacks on either algorithm appear, they
will appear for RSA/SHA-1 first. RSA/MD5 should not be considered
for use because RSA/MD5 will very likely be the first common-use
signature algorithm to be targeted for an effective attack.
At the time of publication, it is known that the SHA-1 hash has
cryptanalysis issues, and work is in progress to address them. The
use of public-key algorithms based on hashes stronger than SHA-1
(e.g., SHA-256) is recommended, if these algorithms are available in
implementations (see RFC 5702 [RFC5702] and RFC 4509 [RFC4509]).
Also, at the time of publication, digital signature algorithms based
on Elliptic Curve (EC) Cryptography with DNSSEC (GOST [RFC5933],
Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6605]) are
being standardized and implemented. The use of EC has benefits in
terms of size. On the other hand, one has to balance that against
the amount of validating resolver implementations that will not
recognize EC signatures and thus treat the zone as insecure. Beyond
the observation of this tradeoff, we will not discuss this further.
3.4.2. Key Sizes
This section assumes RSA keys, as suggested in the previous section.
DNSSEC signing keys should be large enough to avoid all known
cryptographic attacks during the effectivity period of the key. To
date, despite huge efforts, no one has broken a regular 1024-bit key;
in fact, the best completed attack is estimated to be the equivalent
of a 700-bit key. An attacker breaking a 1024-bit signing key would
need to expend phenomenal amounts of networked computing power in a
way that would not be detected in order to break a single key.
Because of this, it is estimated that most zones can safely use
1024-bit keys for at least the next ten years. (A 1024-bit
asymmetric key has an approximate equivalent strength of a symmetric
Depending on local policy (e.g., owners of keys that are used as
extremely high value trust anchors, or non-anchor keys that may be
difficult to roll over), it may be advisable to use lengths longer
than 1024 bits. Typically, the next larger key size used is
2048 bits, which has the approximate equivalent strength of a
symmetric 112-bit key (RFC 3766 [RFC3766]). Signing and verifying
with a 2048-bit key takes longer than with a 1024-bit key. The
increase depends on software and hardware implementations, but public
operations (such as verification) are about four times slower, while
private operations (such as signing) are about eight times slower.
Another way to decide on the size of a key to use is to remember that
the effort it takes for an attacker to break a 1024-bit key is the
same, regardless of how the key is used. If an attacker has the
capability of breaking a 1024-bit DNSSEC key, he also has the
capability of breaking one of the many 1024-bit Transport Layer
Security (TLS) [RFC5246] trust anchor keys that are currently
installed in web browsers. If the value of a DNSSEC key is lower to
the attacker than the value of a TLS trust anchor, the attacker will
use the resources to attack the latter.
It is possible that there will be an unexpected improvement in the
ability for attackers to break keys and that such an attack would
make it feasible to break 1024-bit keys but not 2048-bit keys. If
such an improvement happens, it is likely that there will be a huge
amount of publicity, particularly because of the large number of
1024-bit TLS trust anchors built into popular web browsers. At that
time, all 1024-bit keys (both ones with parent zones and ones that
are trust anchors) can be rolled over and replaced with larger keys.
Earlier documents (including the previous version of this document)
urged the use of longer keys in situations where a particular key was
"heavily used". That advice may have been true 15 years ago, but it
is not true today when using RSA algorithms and keys of 1024 bits or
3.4.3. Private Key Storage
It is preferred that, where possible, zone private keys and the zone
file master copy that is to be signed be kept and used in off-line,
non-network-connected, physically secure machines only.
Periodically, an application can be run to add authentication to a
zone by adding RRSIG and NSEC/NSEC3 RRs. Then the augmented file can
be transferred to the master.
When relying on dynamic update [RFC3007] or any other update
mechanism that runs at a regular interval to manage a signed zone, be
aware that at least one private key of the zone will have to reside
on the master server or reside on an HSM to which the server has
access. This key is only as secure as the amount of exposure the
server receives to unknown clients and on the level of security of
the host. Although not mandatory, one could administer a zone using
a "hidden master" scheme to minimize the risk. In this arrangement,
the master name server that processes the updates is unavailable to
general hosts on the Internet; it is not listed in the NS RRset. The
name servers in the NS RRset are able to receive zone updates through
IXFR, AXFR, or an out-of-band distribution mechanism, possibly in
combination with NOTIFY or another mechanism to trigger zone
The ideal situation is to have a one-way information flow to the
network to avoid the possibility of tampering from the network.
Keeping the zone master on-line on the network and simply cycling it
through an off-line signer does not do this. The on-line version
could still be tampered with if the host it resides on is
compromised. For maximum security, the master copy of the zone file
should be off-net and should not be updated based on an unsecured
The ideal situation may not be achievable because of economic
tradeoffs between risks and costs. For instance, keeping a zone file
off-line is not practical and will increase the costs of operating a
DNS zone. So, in practice, the machines on which zone files are
maintained will be connected to a network. Operators are advised to
take security measures to shield the master copy against unauthorized
access in order to prevent modification of DNS data before it is
Similarly, the choice for storing a private key in an HSM will be
influenced by a tradeoff between various concerns:
o The risks that an unauthorized person has unnoticed read access to
the private key.
o The remaining window of opportunity for the attacker.
o The economic impact of the possible attacks (for a TLD, that
impact will typically be higher than for an individual user).
o The costs of rolling the (compromised) keys. (The cost of rolling
a ZSK is lowest, and the cost of rolling a KSK that is in wide use
as a trust anchor is highest.)
o The costs of buying and maintaining an HSM.
For dynamically updated secured zones [RFC3007], both the master copy
and the private key that is used to update signatures on updated RRs
will need to be on-line.
3.4.4. 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 [RFC4086] and NIST SP 800-90A [NIST-SP-800-90A]. In
particular, one should carefully assess whether the random number
generator used during key generation adheres to these suggestions.
Typically, HSMs tend to provide a good facility for key generation.
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 preferred 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.4.5. Differentiation for 'High-Level' Zones?
An earlier version of this document (RFC 4641 [RFC4641]) made a
differentiation between key lengths for KSKs used for zones that are
high in the DNS hierarchy and those for KSKs used lower down in the
This distinction is now considered irrelevant. Longer key lengths
for keys higher in the hierarchy are not useful because the
cryptographic guidance is that everyone should use keys that no one
can break. Also, it is impossible to judge which zones are more or
less valuable to an attacker. An attack can only take place if the
key compromise goes unnoticed and the attacker can act as a man-in-
the-middle (MITM). For example, if example.com is compromised, and
the attacker forges answers for somebank.example.com. and sends them
out during an MITM, when the attack is discovered it will be simple
to prove that example.com has been compromised, and the KSK will be