needlessly double your key sizes.
3.6. Private Key Storage
It is recommended 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 RRs. Then the augmented file can be
transferred.
When relying on dynamic update to manage a signed zone [10], be aware
that at least one private key of the zone will have to reside on the
master server. This key is only as secure as the amount of exposure
the server receives to unknown clients and the security of the host.
Although not mandatory, one could administer the DNS in the following
way. The master that processes the dynamic updates is unavailable
from generic hosts on the Internet, it is not listed in the NS RR
set, although its name appears in the SOA RRs MNAME field. The
nameservers in the NS RRSet are able to receive zone updates through
NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This
approach is known as the "hidden master" setup.
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 file 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
network mediated communication.
In general, keeping a zone file off-line will not be practical and
the machines on which zone files are maintained will be connected to
a network. Operators are advised to take security measures to shield
unauthorized access to the master copy.
For dynamically updated secured zones [10], both the master copy and
the private key that is used to update signatures on updated RRs will
need to be on-line.
4. Signature Generation, Key Rollover, and Related Policies
4.1. Time in DNSSEC
Without DNSSEC, all times in the DNS are relative. The SOA fields
REFRESH, RETRY, and EXPIRATION are timers used to determine the time
elapsed after a slave server synchronized with a master server. The
Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
are used to determine how long a forwarder should cache data after it
has been fetched from an authoritative server. By using a signature
validity period, DNSSEC introduces the notion of an absolute time in
the DNS. Signatures in DNSSEC have an expiration date after which
the signature is marked as invalid and the signed data is to be
considered Bogus.
4.1.1. Time Considerations
Because of the expiration of signatures, one should consider the
following:
o We suggest the Maximum Zone TTL of your zone data to be a fraction
of your signature validity period.
If the TTL would be of similar order as the signature validity
period, then all RRSets fetched during the validity period
would be cached until the signature expiration time. Section
7.1 of [4] suggests that "the resolver may use the time
remaining before expiration of the signature validity period of
a signed RRSet as an upper bound for the TTL". As a result,
query load on authoritative servers would peak at signature
expiration time, as this is also the time at which records
simultaneously expire from caches.
To avoid query load peaks, we suggest the TTL on all the RRs in
your zone to be at least a few times smaller than your
signature validity period.
o We suggest the signature publication period to end at least one
Maximum Zone TTL duration before the end of the signature validity
period.
Re-signing a zone shortly before the end of the signature
validity period may cause simultaneous expiration of data from
caches. This in turn may lead to peaks in the load on
authoritative servers.
o We suggest the Minimum Zone TTL to be long enough to both fetch
and verify all the RRs in the trust chain. In workshop
environments, it has been demonstrated [18] that a low TTL (under
5 to 10 minutes) caused disruptions because of the following two
problems:
1. During validation, some data may expire before the
validation is complete. The validator should be able to
keep all data until it is completed. This applies to all
RRs needed to complete the chain of trust: DSes, DNSKEYs,
RRSIGs, and the final answers, i.e., the RRSet that is
returned for the initial query.
2. Frequent verification causes load on recursive nameservers.
Data at delegation points, DSes, DNSKEYs, and RRSIGs
benefit from caching. The TTL on those should be
relatively long.
o Slave servers will need to be able to fetch newly signed zones
well before the RRSIGs in the zone served by the slave server pass
their signature expiration time.
When a slave server is out of sync with its master and data in
a zone is signed by expired signatures, it may be better for
the slave server not to give out any answer.
Normally, a slave server that is not able to contact a master
server for an extended period will expire a zone. When that
happens, the server will respond differently to queries for
that zone. Some servers issue SERVFAIL, whereas others turn
off the ’AA’ bit in the answers. The time of expiration is set
in the SOA record and is relative to the last successful
refresh between the master and the slave servers. There exists
no coupling between the signature expiration of RRSIGs in the
zone and the expire parameter in the SOA.
If the server serves a DNSSEC zone, then it may well happen
that the signatures expire well before the SOA expiration timer
counts down to zero. It is not possible to completely prevent
this from happening by tweaking the SOA parameters. However,
the effects can be minimized where the SOA expiration time is
equal to or shorter than the signature validity period. The
consequence of an authoritative server not being able to update
a zone, whilst that zone includes expired signatures, is that
non-secure resolvers will continue to be able to resolve data
served by the particular slave servers while security-aware
resolvers will experience problems because of answers being
marked as Bogus.
We suggest the SOA expiration timer being approximately one
third or one fourth of the signature validity period. It will
allow problems with transfers from the master server to be
noticed before the actual signature times out. We also suggest
that operators of nameservers that supply secondary services
develop ’watch dogs’ to spot upcoming signature expirations in
zones they slave, and take appropriate action.
When determining the value for the expiration parameter one has
to take the following into account: What are the chances that
all my secondaries expire the zone? How quickly can I reach an
administrator of secondary servers to load a valid zone? These
questions are not DNSSEC specific but may influence the choice
of your signature validity intervals.
4.2. Key Rollovers
A DNSSEC key cannot be used forever (see Section 3.3). So key
rollovers -- or supercessions, as they are sometimes called -- are a
fact of life when using DNSSEC. Zone administrators who are in the
process of rolling their keys have to take into account that data
published in previous versions of their zone still lives in caches.
When deploying DNSSEC, this becomes an important consideration;
ignoring data that may be in caches may lead to loss of service for
clients.
The most pressing example of this occurs when zone material signed
with an old key is being validated by a resolver that does not have
the old zone key cached. If the old key is no longer present in the
current zone, this validation fails, marking the data "Bogus".
Alternatively, an attempt could be made to validate data that is
signed with a new key against an old key that lives in a local cache,
also resulting in data being marked "Bogus".
4.2.1. Zone Signing Key Rollovers
For "Zone Signing Key rollovers", there are two ways to make sure
that during the rollover data still cached can be verified with the
new key sets or newly generated signatures can be verified with the
keys still in caches. One schema, described in Section 4.2.1.2, uses
double signatures; the other uses key pre-publication (Section
4.2.1.1). The pros, cons, and recommendations are described in
Section 4.2.1.3.
4.2.1.1. Pre-Publish Key Rollover
This section shows how to perform a ZSK rollover without the need to
sign all the data in a zone twice -- the "pre-publish key rollover".
This method has advantages in the case of a key compromise. If the
old key is compromised, the new key has already been distributed in
the DNS. The zone administrator is then able to quickly switch to
the new key and remove the compromised key from the zone. Another
major advantage is that the zone size does not double, as is the case
with the double signature ZSK rollover. A small "how-to" for this
kind of rollover can be found in Appendix B.
Pre-publish key rollover involves four stages as follows:
----------------------------------------------------------------
initial new DNSKEY new RRSIGs DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2 SOA3
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover
initial: Initial version of the zone: DNSKEY 1 is the Key Signing
Key. DNSKEY 10 is used to sign all the data of the zone, the Zone
Signing Key.
new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no
signatures are generated with this key yet, but this does not
secure against brute force attacks on the public key. The minimum
duration of this pre-roll phase is the time it takes for the data
to propagate to the authoritative servers plus TTL value of the
key set.
new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
used to sign the data in the zone exclusively (i.e., all the
signatures from DNSKEY 10 are removed from the zone). DNSKEY 10
remains published in the key set. This way data that was loaded
into caches from version 1 of the zone can still be verified with
key sets fetched from version 2 of the zone. The minimum time
that the key set including DNSKEY 10 is to be published is the
time that it takes for zone data from the previous version of the
zone to expire from old caches, i.e., the time it takes for this
zone to propagate to all authoritative servers plus the Maximum
Zone TTL value of any of the data in the previous version of the
zone.
DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now
only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
DNSKEY 1.
The above scheme can be simplified by always publishing the "future"
key immediately after the rollover. The scheme would look as follows
(we show two rollovers); the future key is introduced in "new DNSKEY"
as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
(II)":
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11 DNSKEY11 DNSKEY12
RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
----------------------------------------------------------------
----------------------------------------------------------------
new RRSIGs (II) new DNSKEY (II)
----------------------------------------------------------------
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
DNSKEY1 DNSKEY1
DNSKEY11 DNSKEY12
DNSKEY12 DNSKEY13
RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
----------------------------------------------------------------
Pre-Publish Key Rollover, Showing Two Rollovers
Note that the key introduced in the "new DNSKEY" phase is not used
for production yet; the private key can thus be stored in a
physically secure manner and does not need to be ’fetched’ every time
a zone needs to be signed.
4.2.1.2. Double Signature Zone Signing Key Rollover
This section shows how to perform a ZSK key rollover using the double
zone data signature scheme, aptly named "double signature rollover".
During the "new DNSKEY" stage the new version of the zone file will
need to propagate to all authoritative servers and the data that
exists in (distant) caches will need to expire, requiring at least
the Maximum Zone TTL.
Double signature ZSK rollover involves three stages as follows:
----------------------------------------------------------------
initial new DNSKEY DNSKEY removal
----------------------------------------------------------------
SOA0 SOA1 SOA2
RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
RRSIG11(SOA1)
DNSKEY1 DNSKEY1 DNSKEY1
DNSKEY10 DNSKEY10 DNSKEY11
DNSKEY11
RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
RRSIG11(DNSKEY)
----------------------------------------------------------------
Double Signature Zone Signing Key Rollover
initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
Key. DNSKEY 10 is used to sign all the data of the zone, the Zone
Signing Key.
new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
introduced into the key set and all the data in the zone is signed
with DNSKEY 10 and DNSKEY 11. The rollover period will need to
continue until all data from version 0 of the zone has expired
from remote caches. This will take at least the Maximum Zone TTL
of version 0 of the zone.
DNSKEY removal: DNSKEY 10 is removed from the zone. All the
signatures from DNSKEY 10 are removed from the zone. The key set,
now only containing DNSKEY 11, is re-signed with DNSKEY 1.
At every instance, RRSIGs from the previous version of the zone can
be verified with the DNSKEY RRSet from the current version and the
other way around. The data from the current version can be verified
with the data from the previous version of the zone. The duration of
the "new DNSKEY" phase and the period between rollovers should be at
least the Maximum Zone TTL.
Making sure that the "new DNSKEY" phase lasts until the signature
expiration time of the data in initial version of the zone is
recommended. This way all caches are cleared of the old signatures.
However, this duration could be considerably longer than the Maximum
Zone TTL, making the rollover a lengthy procedure.
Note that in this example we assumed that the zone was not modified
during the rollover. New data can be introduced in the zone as long
as it is signed with both keys.
4.2.1.3. Pros and Cons of the Schemes
Pre-publish key rollover: This rollover does not involve signing the
zone data twice. Instead, before the actual rollover, the new key
is published in the key set and thus is available for
cryptanalysis attacks. A small disadvantage is that this process
requires four steps. Also the pre-publish scheme involves more
parental work when used for KSK rollovers as explained in Section
4.2.3.
Double signature ZSK rollover: The drawback of this signing scheme is
that during the rollover the number of signatures in your zone
doubles; this may be prohibitive if you have very big zones. An
advantage is that it only requires three steps.
4.2.2. Key Signing Key Rollovers
For the rollover of a Key Signing Key, the same considerations as for
the rollover of a Zone Signing Key apply. However, we can use a
double signature scheme to guarantee that old data (only the apex key
set) in caches can be verified with a new key set and vice versa.
Since only the key set is signed with a KSK, zone size considerations
do not apply.
--------------------------------------------------------------------
initial new DNSKEY DS change DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 --------> SOA1 -------->
RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
DS1 --------> DS2 -------->
RRSIGpar(DS) --------> RRSIGpar(DS) -------->
Child:
SOA0 SOA1 --------> SOA2
RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
-------->
DNSKEY1 DNSKEY1 --------> DNSKEY2
DNSKEY2 -------->
DNSKEY10 DNSKEY10 --------> DNSKEY10
RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
--------------------------------------------------------------------
Stages of Deployment for a Double Signature Key Signing Key Rollover
initial: Initial version of the zone. The parental DS points to
DNSKEY1. Before the rollover starts, the child will have to
verify what the TTL is of the DS RR that points to DNSKEY1 -- it
is needed during the rollover and we refer to the value as TTL_DS.
new DNSKEY: During the "new DNSKEY" phase, the zone administrator
generates a second KSK, DNSKEY2. The key is provided to the
parent, and the child will have to wait until a new DS RR has been
generated that points to DNSKEY2. After that DS RR has been
published on all servers authoritative for the parent’s zone, the
zone administrator has to wait at least TTL_DS to make sure that
the old DS RR has expired from caches.
DS change: The parent replaces DS1 with DS2.
DNSKEY removal: DNSKEY1 has been removed.
The scenario above puts the responsibility for maintaining a valid
chain of trust with the child. It also is based on the premise that
the parent only has one DS RR (per algorithm) per zone. An
alternative mechanism has been considered. Using an established
trust relation, the interaction can be performed in-band, and the
removal of the keys by the child can possibly be signaled by the
parent. In this mechanism, there are periods where there are two DS
RRs at the parent. Since at the moment of writing the protocol for
this interaction has not been developed, further discussion is out of
scope for this document.
4.2.3. Difference Between ZSK and KSK Rollovers
Note that KSK rollovers and ZSK rollovers are different in the sense
that a KSK rollover requires interaction with the parent (and
possibly replacing of trust anchors) and the ensuing delay while
waiting for it.
A zone key rollover can be handled in two different ways: pre-publish
(Section 4.2.1.1) and double signature (Section 4.2.1.2).
As the KSK is used to validate the key set and because the KSK is not
changed during a ZSK rollover, a cache is able to validate the new
key set of the zone. The pre-publish method would also work for a
KSK rollover. The records that are to be pre-published are the
parental DS RRs. The pre-publish method has some drawbacks for KSKs.
We first describe the rollover scheme and then indicate these
drawbacks.
--------------------------------------------------------------------
initial new DS new DNSKEY DS/DNSKEY removal
--------------------------------------------------------------------
Parent:
SOA0 SOA1 --------> SOA2
RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
DS1 DS1 --------> DS2