+++ /dev/null
-
-
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: March 1, 2004 R. Gieben
- NLnet Labs
- September 2003
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 1, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document intends to describe a set of practices for operating a
- DNSSEC aware enviroment. Its target audience is zone administrators
- who are deploying DNSSEC and need a guide to help them chose sensible
- values for DNSSEC parameters. Is also discusses operational matters
- like key rollovers, KSK and ZSK considerations and more.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 1]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 The use of the term 'key' . . . . . . . . . . . . . . . . . 3
- 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.1 Time definitions . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 Time considerations . . . . . . . . . . . . . . . . . . . . 4
- 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1 Motivations for the KSK and ZSK functions . . . . . . . . . 6
- 3.2 Key security considerations . . . . . . . . . . . . . . . . 7
- 3.3 Key rollovers . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . . 9
- 3.3.2 Key-signing key rollovers . . . . . . . . . . . . . . . . . 12
- 4. Planning for emergency key rollover. . . . . . . . . . . . . 13
- 4.1 KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2 ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 14
- 4.3 Compromises of keys anchored in resolvers . . . . . . . . . 14
- 5. Parental policies. . . . . . . . . . . . . . . . . . . . . . 14
- 5.1 Initial key exchanges and parental policies
- considerations. . . . . . . . . . . . . . . . . . . . . . . 14
- 5.2 Storing keys so hashes can be regenerated . . . . . . . . . 15
- 5.3 Security lameness checks. . . . . . . . . . . . . . . . . . 15
- 5.4 SIG DS validity period. . . . . . . . . . . . . . . . . . . 15
- 6. Security considerations . . . . . . . . . . . . . . . . . . 16
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
- Normative References . . . . . . . . . . . . . . . . . . . . 16
- Informative References . . . . . . . . . . . . . . . . . . . 16
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 17
- B. Zone-signing key rollover howto . . . . . . . . . . . . . . 18
- C. Typographic conventions . . . . . . . . . . . . . . . . . . 19
- D. Document Details and Changes . . . . . . . . . . . . . . . . 20
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 2]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained knowledge about operating DNSSEC
- aware DNS services. This document describes these practices.
-
- The structure of the document is as follows. It starts with
- discussing some of the considerations with respect to timing
- parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
- management such as key rollover schemes are described in Section 3.
- Emergency rollover considerations are addressed in Section 4. The
- Typographic conventions used in this document are explained in
- Appendix C.
-
- Since this is a document with operational suggestions and there is no
- protocol specifications the RFC2119 [5] language does not apply.
-
-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. Therefore this document
- will use the term key rather loosely. Wherever we write that 'a key
- is used to sign data' it is assumed that the reader knows that it is
- the private part of the key-pair that is used for signing. It is also
- assumed that the reader will know that the public part of the
- key-pair is published in the DNSKEY resource record and that it is
- the public part of a key-pair that is used in key-exchanges.
-
-2. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA's refresh,
- retry and expiration timers are counters that are being used to
- determine the time elapsed after a slave server synced (or tried to
- sync) with a master server. The TTL value and the SOA minimum TTL
- parameter [6] are used to to determine how long a forwarder should
- cache data after it has been fetched from an authoritative server.
- DNSSEC introduces the notion of an absolute time in the DNS.
- Signatures in DNSSEC have an expiration date after which the
- signature is invalid and the signed data is to be considered BAD.
-
-2.1 Time definitions
-
- In this document we will be using a number of time related terms.
- Within the context of this document the following definitions apply:
-
- o "Signature validity period"
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 3]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 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 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.
- If a signature is published on time T0 and a new signature is
- published on time T1, the signature publication period is T1 -
- T0. If all signatures are refreshed at zone (re)signing then
- the signature publication period is equal to the period between
- two consecutive zone signing operations.
-
- o "Key publication period"
-
- The period for which the public part of the key is published in
- the DNS. The public part of the key can be published in the DNS
- while it has not yet been used to sign data. As soon as a
- public key is published a brute force attack can be attempted
- to recover the private key. Publishing the public key in
- advance (and not signing any data with it) does not guard
- against this attack.
-
- [Editor's Note: We don't use this term in the doc yet, is it
- needed elsewhere and handy to define here? No:1 Yes:0]
-
- o "Maximum/Minimum Zone TTL"
-
- The maximum or minimum value of all the TTLs in a zone.
-
-
-2.2 Time considerations
-
- Because of the expiration of signatures one should consider the
- following.
-
- o The Maximum zone TTL of your zone data should 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. As a result
- query behavior might become bursty.
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 4]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- We suggest the TTL on all the RRs in your zone to be at least
- an order of magnitude smaller than your signature validity
- period.
-
- o The signature publication period should at least be one maximum
- TTL smaller than the signature validity period.
-
- If a zone is resigned shortly before the end of the signature
- validity period this may cause simultaneous expiration of data
- from caches which leads to bursty query behavior and increase
- the load on authoritative servers.
-
- o The Minimum zone TTL should be long enough to fetch and verify all
- the RRs in the authentication chain.
-
- 1. During validation, some data may expire before validation
- is complete. The validator should be able to keep all the
- data, until validation is complete. This applies to all data
- in the chain of trust: DSs, DNSKEYs, RRSIGs, and the final
- answers i.e. the RR that is returned for the initial query.
-
- 2. Frequent verification causes load on recursive
- nameservers. Data at delegation points, DSs, DNSKEYs and
- RRSIGs benefit from caching. The TTL on those should be
- relatively long.
-
- We have seen events where data needed for verification of an
- authentication chain had expired from caches.
-
- We suggest the TTL on DNSKEY and DSs to be at least of the
- order 10 minutes to an hour and all the other RRs in your zone
- to be at least 30 seconds. These are absolute minimum, we
- recommend zone administrators to chose longer ones.
-
- [Editor's Note: this observation could be implementation
- specific. We are not sure if we should leave this item]
-
- o Slave servers will need to be able to fetch newly signed zones
- well before the data expires from your zone.
-
- If a properly implemented slave server is not able to contact a
- master server for an extended period the data will at some
- point expire and the slave server will not hand out any data.
- If the server serves a DNSSEC zone than it may well happen that
- the signatures expire well before the SOA expiration timer
- counted down to zero. It is not possible to fully prevent this
- from happening by tweaking the SOA parameters. But the effects
- can be minimized if the SOA expiration time is of the same of
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 5]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- order of magnitude as or smaller than the signature validity
- period.
-
- When a zone cannot be updated while signatures in that zone
- have expired non-secure resolvers will continue to be able to
- resolve the data served by the particular slave servers. Only
- security aware resolvers that receive data with expired
- signatures will experience problems.
-
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period.
-
- We also suggest that operators of nameservers with slave zones
- develop watchdogs to be able to spot these upcoming signature
- expirations in slave zones, so that appropriate action can be
- taken.
-
- o [Editor's Note: Need examples here]
-
-
-3. Keys
-
-3.1 Motivations for the KSK and ZSK functions
-
- Delegation Signer [7] introduced the concept of key-signing and
- zone-signing keys.The Key-signing-flag [4] introduced the concept of
- a key with the Secure Entry Point flag set; a key that is the first
- key from the zone when following an authentication chain. When using
- a key-signing key with the SEP flag set (the parent has a DS RR
- pointing to that DNSKEY) and when using zone-signing keys without the
- SEP flag set (a practice which we recommend ) one can use the
- following operational procedures.
-
- 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 over no
- interactions with the parent is needed. This allows for relatively
- short "Signature Validity Periods" (order of days).
-
- The key-signing key (with the SEP flag set) is only to be used to
- sign the Key RR set from the zone apex. If a key-signing key is to be
- rolled over, there will be interactions with parties other than the
- zone maintainer such as the registry of the parent zone or
- administrators of verifying resolvers that have the particular key
- configured as trusted entry points. Hence, the "Key Usage Time" of
- these keys can and should be made much longer. Although, given a long
- enough key, the "Key Usage Time" can be on the order of years we
- suggest to plan for a "Key Usage Time" of the order of a few months
- so that a key rollover remains an operational routine.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 6]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-3.2 Key security considerations
-
- In RFC2541 [2] a number of considerations with respect to the
- security of keys are described. That document deals with the
- generation, lifetime, size and storage of private keys.
-
- In Section 3 of RFC2541 [2], Eastlake does have some suggestions: 13
- months for long-lived keys and 36 days for transaction keys but
- suggestions for key sizes are not made.
-
- If we read the long-lived key being a key that is used as key-signing
- key and transaction keys being zone signing keys, then these
- recommendations are good starting points for an operational
- procedure. These recommendations will lead to rollovers occurring
- frequently enough so that they can become part of 'operational
- habits' and the procedure does not have to be reinvented every time a
- key is replaced.
-
- When choosing a key sizes, zone administrators will need to take into
- account how long a key will be used and how much data will be signed
- during the key publication period. It is hard to give precise
- recommendations but Lenstra and Verheul [9] supplied the following
- table with lower bound estimates for cryptographic key sizes. Their
- recommendations are based on a set of explicitly formulated parameter
- settings, combined with existing data points about cryptosystems. For
- details we refer to the original paper.
-
- Year RSA key sizes Elliptic Curve Key Size
- 2000 952 132
- 2001 990 135
- 2002 1028 139
- 2003 1068 140
- 2004 1108 143
-
- 2005 1149 147
- 2006 1191 148
- 2007 1235 152
- 2008 1279 155
- 2009 1323 157
-
-
- 2010 1369 160
- 2011 1416 163
- 2012 1464 165
- 2013 1513 168
- 2014 1562 172
-
- 2015 1613 173
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 7]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 2016 1664 177
- 2017 1717 180
- 2018 1771 181
- 2019 1825 185
-
-
- 2020 1881 188
- 2021 1937 190
- 2022 1995 193
- 2023 2054 197
- 2024 2113 198
-
- 2025 2174 202
- 2026 2236 205
- 2027 2299 207
- 2028 2362 210
- 2029 2427 213
-
- Suppose you want your key to last 3 years and the current year is
- 2003. Add 3 to 2003 equals 2006 and read of the sizes: 1191 for
- asymmetric keys and 148 bits for elliptic curve keys.
-
- Note that adding only a "handful of bits" to the key size will
- increase the key's resistance against brute force attacks.
-
-3.3 Key rollovers
-
- Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
- cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
- maintainers who are in the process of rolling their keys have to take
- into account that data they have 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 is when zone material which is
- signed with an old key is being validated by a resolver which 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 BAD.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked BAD.
-
- To appreciate the situation one could think of a number of
- authoritative servers that may not be instantaneously running the
- same version of a zone and a security aware non-recursive resolver
- that sits behind security aware caching forwarders.
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 8]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different way: pre-publish and
- [Editors note: ref please] double-sig. The pre-publish technique
- works because the key-signing key stays the same during this ZSK
- rollover. With this KSK a cache is able to validate the new keyset of
- a zone. With a KSK rollover a cache can not validate the new keyset,
- because it does not trust the new KSK.
-
- [Editors note: This needs more verbose explanation, nobody will
- appreciate the situation just yet. Help with text and examples is
- appreciated]
-
-3.3.1 Zone-signing key rollovers
-
- For zone-signing key rollovers there are two ways to make sure that
- during the rollover the data still in caches can be verified with the
- new keysets or the newly generated signatures can be verified with
- the keys still in caches. One schema uses double signatures, it is
- described in Section 3.3.1.1, the other uses key pre-publication
- (Section 3.3.1.2). The pros, cons and recommendations are described
- in Section 3.3.1.3.
-
-3.3.1.1 A double signature zone-signing key rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme.
-
- During the rollover 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, this will take at least the
- maximum Zone TTL .
-
- normal roll after
-
- 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)
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 9]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY
- 10 is used to sign all the data of the zone, it is the
- zone-signing key.
-
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the keyset and all the data in the zone is signed with DNSKEY
- 10 and DNSKEY 11. The rollover period will need to exist until all
- data from version 0 of the zone has expired from remote caches.
- This will take at least the Maximum Zone TTL of the version 0 of
- the zone.
-
- after: DNSKEY 10 is removed from the zone. All the signatures from
- DNSKEY 10 are removed from the zone. The keyset, now only
- containing DNSKEY 11 is resigned with the DNSKEY 1.
-
- At every instance the data from the previous version of the zone can
- be verified with the key from the current version. And vice verse,
- the data from the current version can be verified with the data from
- the previous version of the zone. The duration of the rollover phase
- and the period between rollovers should be at least the "Maximum Zone
- TTL".
-
- To be on the safe side one could make sure that the rollover phase
- lasts until the signature expiration time of the data in version 0 of
- the zone. But this date could be considerable longer than the Maximum
- Zone TTL, making the rollover a lengthly procedure.
-
- Note that in this example we assumed that the zone did not get
- modified during the rollover. New data can be introduced in the zone
- as long as it is signed with both keys.
-
-3.3.1.2 Pre-publish keyset rollover
-
- This section shows how to perform a ZSK rollover without the need to
- sign all the data in a zone twice. We recommend this method because
- it has advantages in the case of key compromises. If the old key gets
- compromised the new key is already 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 "HOWTO" for this kind of rollover can
- be found in Appendix B.
-
- normal pre-roll roll after
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 10]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 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)
-
-
- normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY
- 10 is used to sign all the data of the zone, its the zone-signing
- key.
-
- pre-roll: DNSKEY 11 is introduced in the keyset. Note that no
- signatures are generated with this key yet, but this will not
- prevent 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 on the
- keyset. This would boil down to two times the Maximum Zone TTL.
-
- roll:
-
- At the rollover stage (SOA serial 1) 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
- keyset. 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 keyset that includes 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.
-
- after: DNSKEY 10 is removed from the zone. The keyset, now only
- containing DNSKEY 11 is resigned with the DNSKEY 1.
-
- The above scheme can be simplified a bit by always publishing the
- "future" key immediately after the rollover. The scheme would look
- like this (we show 2 rollovers); the future key is introduced in
- "after" as DNSKEY 12 and again a newer one, numbered 13, in "2nd
- after":
-
-
- normal roll after 2nd roll 2nd after
-
- SOA0 SOA2 SOA3 SOA4 SOA5
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 11]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
- DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Note that the key introduced after the rollover 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.
-
- This scheme has the benefit that the key that is intended for future
- use, can immediately be used during an emergency rollover under the
- assumption that it was stored in a physically secure manner.
-
-3.3.1.3 Pros and cons of the schemes
-
- A double signature rollover: The drawback of this signing scheme is
- that during the rollover the number of signatures in your zone
- doubles, which may be prohibitive if you have very big zones. An
- advantage is that it only requires three steps.
-
- Prepublish-keyset rollover: This rollover does not involve signing
- the zone data twice. Instead, just before the actual rollover the
- new key is published in the keyset and thus available for
- cryptanalysis attacks. A small disavantage is that this process
- requires four steps. Also the prepublish scheme is useless for
- KSKs as explained in Section 3.3.
-
-
-3.3.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 keyset) in
- caches can be verified with a new keyset and vice versa. Since only
- the keyset is signed with a KSK, size considerations do not apply.
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY2
- DNSKEY2
- DNSKEY10 DNSKEY10 DNSKEY10
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 12]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
- RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-
-4. Planning for emergency key rollover.
-
- This section deals with preparation for a possible key compromise.
- Our advice is to have a documented procedure ready for when a key
- compromise is suspected or confirmed.
-
- [Editors note: We are much in favor of a rollover tactic that keeps
- the authentication chain intact as long as possible. This has as a
- result that one has to take all the regular rollover properties into
- account.]
-
- When the private material of one of your keys is compromised it can
- be used by 'blackhats' for as long as a valid authentication chain
- exists. A authentication chain remains intact for:
-
- as long as a signature over the compromised key in the
- authentication chain is valid,
-
- as long as a parental DS RR (and signature) points to the
- compromised key,
-
- as long as the key is anchored in a resolver and is used as a
- starting point for validation. (This is the hardest to update.)
-
- While an authentication chain to your compromised key exists your
- name-space is vulnerable to abuse by the "blackhat". Zone operators
- have to make a trade off if the abuse of the compromised key is worse
- than having data in caches that cannot be validated. If the zone
- operator chooses to break the authentication chain to the compromised
- key, data in caches signed with this key can not be validated. On the
- other hand if the zone administrator chooses to take the path of a
- regular roll-over the "blackhat" can spoof data so that it appears to
- be valid, note that this kind of attack will usually be localized in
- the Internet topology.
-
-
-4.1 KSK compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible and through secure means. The keyset of the zone should
- be resigned as soon as possible. Care must be taken to not break the
- authentication chain. The local zone can only be resigned with the
- new KSK after the parent's zone has been updated with the new KSK.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 13]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- Before this update takes place it would be best to drop the security
- status of a zone all together: the parent removes the DS of the child
- at the next zone update. After that the child can be made secure
- again. An additional danger of a key compromise is that the
- compromised key can be used to facilitate a legitemate DNSKEY/DS and/
- or nameserver rollover at the parent. When that happens the domain
- can be in dispute. An out of band and secure notify mechanism to
- contact a parent is needed in this case.
-
-4.2 ZSK compromise
-
- Mainly because there is no parental interaction required when a ZSK
- is compromised the situation is less severe than with with a KSK
- compromise. The zone must still be resigned with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. One has to take into account though that just as with
- a normal rollover the immediate disappearance from the old
- compromised key may lead to verification problems. The
- pre-publication scheme as discussed above minimizes that problem.
-
-4.3 Compromises of keys anchored in resolvers
-
- A key can also be pre-configured in resolvers. If DNSSEC is rolled
- out as planned the root key should be pre-configured in every secure
- aware resolver on the planet. [Editors Note: add more about
- authentication of a newly received resolver key]
-
- If that key is compromised all the resolvers should be notified of
- this fact. Zone administrators may consider setting up a mailing list
- to communicate the fact that a SEP key is about to be rolled over.
- This communication will of course need to be authenticated e.g. by
- using digital signatures.
-
-5. Parental policies.
-
-5.1 Initial key exchanges and parental policies considerations.
-
- The initial key exchange is always subject to the policies set by the
- parent (or its registry). When designing a key exchange policy one
- should take into account that the authentication and authorization
- mechanisms used during a key exchange should be as strong as the
- authentication and authorization mechanisms used for the exchange of
- delegation information between parent and child.
-
- Using the DNS itself as the source for the actual DNSKEY material
- with an off-band check on the validity of the DNSKEY has the benefit
- that it reduces the changes of operator error. A parental DNSKEY
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 14]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- download tool can make use of the SEP bit [4] to select the proper
- key from a DNSSEC keyset; thereby reducing the change that the wrong
- DNSKEY is sent. It can validate the self-signature over a key;
- thereby verifying the ownership of the private key material. Besides,
- by fetching the DNSKEY from the DNS one can be sure that the child
- will not become invisible once the parent indicates the child is
- secure by publishing the DS RR.
-
- Note: the off-band verification is still needed when the keymaterial
- is fetched by a tool. The parent can not be sure if the DNSKEY RRs
- where not spoofed.
-
-5.2 Storing keys so hashes can be regenerated
-
- When designing a registry system one should consider if the DNSKEYs
- or the corresponding DSs are stored. Storing DNSKEYs will help during
- troubleshooting while the overhead of calculating DS records from
- them is minimal.
-
- Having a out-of-band mechanism, such as a WHOIS database, to find out
- which keys are used to generate DS Resource Records for specific
- owners may also help with troubleshooting.
-
-5.3 Security lameness checks.
-
- Security lameness is defined as the event that a parent has a DS
- Resource Record that points to a non-existing DNSKEY RR. At key
- exchange a parent should make sure that the childs key is actually
- configured in the DNS before publishing a DS RR in its zone. Failure
- to do so would render the child's zone marked "BAD".
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exist.
-
- Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
- take time to propagate through the DNS.
-
-5.4 SIG DS validity period.
-
- Since the DS can be replayed as long as it has a valid signature a
- short signature validity period over the DS minimizes the time a
- child is vulnerable in the case of a compromise of the child's KSK.
- A signature validity period that is too short introduces the
- possibility that a zone is marked BAD in case of a configuration
- error in the signer; there may not be enough time to fix the problems
- before signatures expire. Something as mundane as weekends show the
- need for a DS signature lifetimes longer than 2 days. We recommend
- the minimum for a DS signature validity period to be about a few
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 15]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- days.
-
- The maximum signature lifetime of the DS record depends on how long
- child zones are willing to be vulnerable after a key compromise. We
- consider a signature validity period of the order of one week a good
- compromise between the operational constraints of the parent and
- minimizing damage for the child.
-
-6. Security considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- considerations to operate a stable and secure DNSSEC service.
-
-7. Acknowledgments
-
- We, the folk mentioned as authors, only acted as editors. Most of the
- ideas in this draft where the result of collective efforts during
- workshops and discussions and try outs.
-
- At the risk of forgetting individuals who where the original
- contributors of the ideas we like to acknowledge people who where
- actively involved in the compilation of this document. In
- alphabetical order: Olafur Gudmundsson, Wesley Griffin, Michael
- Richardson, Scott Rose, Rick van Rein, Tim McGinnis.
-
- Kolkman and Gieben take the blame for all mistakes.
-
-Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
- (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
- in progress), February 2003.
-
-Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 16]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 2308, March 1998.
-
- [7] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-13 (work in progress), March
- 2003.
-
- [8] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
- progress), March 2003.
-
- [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
- The Journal of Cryptology 14 (255-293), 2001.
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- NL
-
- EMail: miek@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but give a more elaborate explanation of
- the meaning. Note that these explanations should not be seen as
- authoritative.
-
- Private and Public Keys: DNSSEC secures the DNS through the use of
- public key cryptography. Public key cryptography is based on the
- existence of 2 keys, a public key and a private key. The public
- keys are published in the DNS by use of the DNSKEY Resource Record
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 17]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- (DNSKEY RR). Private keys are supposed to remain private i.e.
- should not be exposed to parties not-authorized to do the actual
- signing.
-
- Signer: The system that has access to the private key material and
- signs the Resource Record sets in a zone. A signer may be
- configured to sign only parts of the zone e.g. only those RRsets
- for which existing signatures are about to expire.
-
- KSK: A Key-Signing key (KSK) is a key that is used for exclusively
- signing the apex keyset. The fact that a key is a KSK is only
- relevant to the signing tool.
-
- ZSK: A Zone signing key (ZSK) is a key that is used for signing all
- data in a zone. The fact that a key is a ZSK is only relevant to
- the signing tool.
-
- BAD: [Editors Note: a reference here] A RRset in DNSSEC is marked
- "bad" when a signature of a RRset does not validate against the
- DNSKEY. Even is the key itself was not marked BAD. BAD data is not
- cached.
-
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
-
-
-Appendix B. Zone-signing key rollover howto
-
- Using the pre-published signature scheme and the most conservative
- method to assure oneself that data does not live in distant caches
- here follows the "HOWTO". [WES: has some comments about this]
-
- STEP 0, the preparation: Create two keys and publish them both in
- your keyset. Mark one of the keys as "active" and the other as
- "published". Use the "active" key for signing your zone data.
- Store the private part of the "published" key, preferably
- off-line.
-
- STEP 1, determine expiration: At the beginning of the rollover:
- make a note of the highest expiration time of signatures in your
- zonefile created with the current key currently marked as
- "active".
-
- Wait until the expiration time marked in STEP 1
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 18]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- STEP 2 Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
-
- STEP 3: It is safe to engage in a new rollover (STEP 1) after at
- least one "signature validity period".
-
-
-Appendix C. Typographic conventions
-
- The following typographic conventions are used in this document:
-
- Key notation: A key is denoted by KEYx, where x is a number, x could
- be thought of as the key id.
-
- RRset notations: RRs are only denoted by the type all other
- information, owner, class, rdata and TTL is left out. Thus:
- example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
- list of RRs. A example of this would be: A1,A2, specifying the
- RRset containing two A records. This could again be abreviated to
- just: A.
-
- Signature notation: Signatures are denoted as SIGx(RRset), which
- means that RRset is signed with KEYx.
-
- Zone representation: Using the above notation we have simplify the
- representation of a signed zone by leaving out all unneeded
- details such as the names and by just representing all data by
- "SOAx"
-
- SOA representation: Soa's are represented as SOA x, where x is the
- serial number.
-
- Using this notation the following zone :
-
-
- example.net. 600 IN SOA ns.example.net. ernie.example.net. (
- 10 ; serial
- 450 ; refresh (7 minutes 30 seconds)
- 600 ; retry (10 minutes)
- 345600 ; expire (4 days)
- 300 ; minimum (5 minutes)
- )
- 600 RRSIG SOA 5 2 600 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 600 NS a.iana-servers.net.
- 600 NS b.iana-servers.net.
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 19]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- 600 RRSIG NS 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 3600 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0...
- ) ; key id = 14
- 3600 DNSKEY 256 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU...
- ) ; key id = 15
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
- 600 RRSIG NSEC 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 600 IN TXT "A label"
- 600 RRSIG TXT 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 600 NSEC b.example.com. TXT RRSIG NSEC
- 600 RRSIG NSEC 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following represenation:
-
- SOA10
- RRSIG14(SOA10)
-
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
- i.e a RRSIG created with DNSKEY 14.
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 20]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- document is published.
-
- $Header: /var/cvs/dnssec-key/
- draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.5 2003/10/10
- 09:49:07 dnssec Exp $
-
-D.1 draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified and
- updated version of draft-kolkman-dnssec-operational-practices-00.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 21]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 22]
-\f
-Internet-Draft DNSSEC Operational Practices September 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires March 1, 2004 [Page 23]
-\f
--- /dev/null
+\r
+DNSOP O. Kolkman\r
+Internet-Draft RIPE NCC\r
+Expires: August 30, 2004 R. Gieben\r
+ NLnet Labs\r
+ March 2004\r
+\r
+\r
+ DNSSEC Operational Practices\r
+ draft-ietf-dnsop-dnssec-operational-practices-01.txt\r
+\r
+Status of this Memo\r
+\r
+ This document is an Internet-Draft and is in full conformance with\r
+ all provisions of Section 10 of RFC2026.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF), its areas, and its working groups. Note that other\r
+ groups may also distribute working documents as Internet-Drafts.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ The list of current Internet-Drafts can be accessed at http://\r
+ www.ietf.org/ietf/1id-abstracts.txt.\r
+\r
+ The list of Internet-Draft Shadow Directories can be accessed at\r
+ http://www.ietf.org/shadow.html.\r
+\r
+ This Internet-Draft will expire on August 30, 2004.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (C) The Internet Society (2004). All Rights Reserved.\r
+\r
+Abstract\r
+\r
+ This document describes a set of practices for operating a DNSSEC\r
+ aware environment. The target audience is zone administrators\r
+ deploying DNSSEC that need a guide to help them chose appropriate\r
+ values for DNSSEC parameters. It also discusses operational matters\r
+ such as key rollovers, KSK and ZSK considerations and related\r
+ matters.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 1]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3\r
+ 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3\r
+ 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4\r
+ 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5\r
+ 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6\r
+ 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7\r
+ 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8\r
+ 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8\r
+ 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8\r
+ 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8\r
+ 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9\r
+ 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10\r
+ 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13\r
+ 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14\r
+ 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15\r
+ 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15\r
+ 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16\r
+ 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16\r
+ 5.1 Initial Key Exchanges and Parental Policies\r
+ Considerations . . . . . . . . . . . . . . . . . . . . . . 16\r
+ 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16\r
+ 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17\r
+ 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17\r
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17\r
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17\r
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18\r
+ 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18\r
+ 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19\r
+ A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19\r
+ B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20\r
+ C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20\r
+ D. Document Details and Changes . . . . . . . . . . . . . . . . . 22\r
+ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22\r
+ D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22\r
+ Intellectual Property and Copyright Statements . . . . . . . . 23\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 2]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+1. Introduction\r
+\r
+ During workshops and early operational deployment tests, operators\r
+ and system administrators gained experience about operating DNSSEC\r
+ aware DNS services. This document translates these experiences into\r
+ a set of practices for zone administrators. At the time of writing,\r
+ there exists very little experience with DNSSEC in production\r
+ environments, this document should therefore explicitly not be seen\r
+ as represented 'Best Current Practices'.\r
+\r
+ The procedures herein are focused on the maintenance of signed zones\r
+ (i.e. signing and publishing zones on authoritative servers). It is\r
+ intended that maintenance of zones such as resigning or key rollovers\r
+ be transparent to any verifying clients on the Internet.\r
+\r
+ The structure of this document is as follows: It begins with\r
+ discussing some of the considerations with respect to timing\r
+ parameters of DNS in relation to DNSSEC (Section 2). Aspects of key\r
+ management such as key rollover schemes are described in Section 3.\r
+ Emergency rollover considerations are addressed in Section 4. The\r
+ typographic conventions used in this document are explained in\r
+ Appendix C.\r
+\r
+ Since this is a document with operational suggestions and there are\r
+ no protocol specifications, the RFC2119 [5] language does not apply.\r
+\r
+1.1 The Use of the Term 'key'\r
+\r
+ It is assumed that the reader is familiar with the concept of\r
+ asymmetric keys on which DNSSEC is based (Public Key Cryptography\r
+ [Ref to Schneider?]). Therefore, this document will use the term\r
+ 'key' rather loosely. Where it is written that 'a key is used to sign\r
+ data' it is assumed that the reader understands that it is the\r
+ private part of the key-pair that is used for signing. It is also\r
+ assumed that the reader understands that the public part of the\r
+ key-pair is published in the DNSKEY resource record and that it is\r
+ used in key-exchanges.\r
+\r
+1.2 Keeping the Chain of Trust Intact\r
+\r
+ Maintaining a valid chain of trust is important because broken chains\r
+ of trust will result in data being marked as bogus, which may cause\r
+ entire (sub)domains to become invisible to verifying clients. The\r
+ administrators of secured zones have to realise that their zone is,\r
+ to their clients, part of a chain of trust.\r
+\r
+ As mentioned in the introduction, the procedures herein are intended\r
+ to ensure maintenance of zones, such as resigning or key rollovers,\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 3]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ be transparent to the verifying clients on the Internet.\r
+ Administrators of secured zones will have to keep in mind that data\r
+ published on an authoritative primary server will not be immediately\r
+ seen by verifying clients; it may take some time for the data to be\r
+ transfered to other secondary authoritative nameservers, during which\r
+ period clients may be fetching data from caching non-authoritative\r
+ servers. For the verifying clients it is important that data from\r
+ secured zones can be used to build chains of trust regardless of\r
+ whether the data came directly from an authoritative server, a\r
+ caching nameserver or some middle box. Only by carefully using the\r
+ available timing parameters can a zone administrator assure that the\r
+ data necessary for verification can be obtained.\r
+\r
+ The responsibility for maintaining the chain of trust is shared by\r
+ administrators of secured zones in the chain of trust. This is most\r
+ obvious in the case of a 'key compromise' when a trade off between\r
+ maintaining a valid chain of trust and the fact that the key has been\r
+ stolen, must be made.\r
+\r
+ The zone administrator will have to make a tradeoff between keeping\r
+ the chain of trust intact -thereby allowing for attacks with the\r
+ compromised key- or to deliberately break the chain of trust thereby\r
+ making secured subdomains invisible to security aware resolvers. Also\r
+ see Section 4.\r
+\r
+2. Time in DNSSEC\r
+\r
+ Without DNSSEC all times in DNS are relative. The SOA's refresh,\r
+ retry and expiration timers are counters that are used to determine\r
+ the time elapsed after a slave server syncronised (or tried to\r
+ syncronise) with a master server. The Time to Live (TTL) value and\r
+ the SOA minimum TTL parameter [6] are used to determine how long a\r
+ forwarder should cache data after it has been fetched from an\r
+ authoritative server. DNSSEC introduces the notion of an absolute\r
+ time in the DNS. Signatures in DNSSEC have an expiration date after\r
+ which the signature is marked as invalid and the signed data is to be\r
+ considered bogus.\r
+\r
+2.1 Time Definitions\r
+\r
+ In this document we will be using a number of time related terms.\r
+ Within the context of this document the following definitions apply:\r
+ o "Signature validity period"\r
+ The period that a signature is valid. It starts at the time\r
+ specified in the signature inception field of the RRSIG RR and\r
+ ends at the time specified in the expiration field of the RRSIG\r
+ RR.\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 4]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ o "Signature publication period"\r
+ Time after which a signature (made with a specific key) is\r
+ replaced with a new signature (made with the same key). This\r
+ replacement takes place by publishing the relevant RRSIG in the\r
+ master zone file. If a signature is published at time T0 and a\r
+ new signature is published at time T1, the signature\r
+ publication period is T1 - T0.\r
+ If all signatures are refreshed at zone (re)signing then the\r
+ signature publication period is equal signature validity\r
+ period.\r
+ o "Maximum/Minimum Zone TTL"\r
+ The maximum or minimum value of all the TTLs in a zone.\r
+\r
+2.2 Time Considerations\r
+\r
+ Because of the expiration of signatures, one should consider the\r
+ following.\r
+ o The Maximum Zone TTL of your zone data should be a fraction of\r
+ your signature validity period.\r
+ If the TTL would be of similar order as the signature validity\r
+ period, then all RRsets fetched during the validity period\r
+ would be cached until the signature expiration time. As a\r
+ result query load on authoritative servers would peak at\r
+ signature expiration time.\r
+ To avoid query load peaks we suggest the TTL on all the RRs in\r
+ your zone to be at least a few times smaller than your\r
+ signature validity period.\r
+ o The signature publication period should be at least one maximum\r
+ TTL smaller than the signature validity period.\r
+ Resigning a zone shortly before the end of the signature\r
+ validity period may cause simultaneous expiration of data from\r
+ caches. This in turn may lead to peaks in the load on\r
+ authoritative servers.\r
+ o The Minimum zone TTL should be long enough to both fetch and\r
+ verify all the RRs in the authentication chain.\r
+ 1. During validation, some data may expire before the\r
+ validation is complete. The validator should be able to keep\r
+ all data, until is completed. This applies to all RRs needed\r
+ to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and\r
+ the final answers i.e. the RR that is returned for the\r
+ initial query.\r
+ 2. Frequent verification causes load on recursive\r
+ nameservers. Data at delegation points, DSs, DNSKEYs and\r
+ RRSIGs benefit from caching. The TTL on those should be\r
+ relatively long.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 5]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ We have seen events where data needed for verification of an\r
+ authentication chain had expired from caches.\r
+ We suggest the TTL on DNSKEY and DSs to be between ten minutes\r
+ and one hour. We recommend zone administrators to chose TTLs\r
+ longer than half a minute.\r
+ [Editor's Note: this observation could be implementation\r
+ specific. We are not sure if we should leave this item]\r
+ o Slave servers will need to be able to fetch newly signed zones\r
+ well before the data expires from your zone.\r
+ 'Better no answers than bad answers.'\r
+ If a properly implemented slave server is not able to contact a\r
+ master server for an extended period the data will at some\r
+ point expire and the slave server will not hand out any data.\r
+ If the server serves a DNSSEC zone than it may well happen that\r
+ the signatures expire well before the SOA expiration timer\r
+ counts down to zero. It is not possible to completely prevent\r
+ this from happening by tweaking the SOA parameters. However,\r
+ the effects can be minimized where the SOA expiration time is\r
+ equal or smaller than the signature validity period.\r
+ The consequence of an authoritative server not being able to\r
+ update a zone, whilst that zone includes expired signaturs, is\r
+ that non-secure resolvers will continue to be able to resolve\r
+ data served by the particular slave servers. Security aware\r
+ resolvers will experience problems.\r
+ We suggest the SOA expiration timer being approximately one\r
+ third or one fourth of the signature validity period. It will\r
+ allow problems with transfers from the master server to be\r
+ noticed before the actual signature time out.\r
+ We suggest that operators of nameservers with slave zones\r
+ develop 'watch dogs' to spot upcoming signature expirations in\r
+ slave zones, and take appropriate action.\r
+ When determining the value for the expiration parameter one has\r
+ to take the following into account: What are the chances that\r
+ all my secondary zones expire; How quickly can I reach an\r
+ administrator and load a valid zone? All these arguments are\r
+ not DNSSEC specific.\r
+\r
+3. Keys\r
+\r
+ In the DNSSEC protocol there is only one type of key, the zone key.\r
+ With this key, the data in a zone is signed.\r
+\r
+ To make zone re-signing and key rollovers procedures easier to\r
+ implement, it is possible to use one or more keys as Key Signing Keys\r
+ (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other\r
+ keys can be used to sign all the RRsets in a zone and are referred to\r
+ as Zone Signing Keys (ZSK). In this document we assume that KSKs are\r
+ the subset of keys that are used for key exchanges with the parents\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 6]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ and potentially for configuration as trusted anchors - the so called\r
+ Secure Entry Point keys (SEP). In this document we assume a\r
+ one-to-one mapping between KSK and SEP keys and we assume the SEP\r
+ flag [4] to be set on KSKs.\r
+\r
+3.1 Motivations for the KSK and ZSK Functions\r
+\r
+ Differentiating between the KSK to ZSK functions has several\r
+ advantages:\r
+\r
+ o Making the KSK stronger (i.e. using more bits in the key material)\r
+ has little operational impact since it is only used to sign a\r
+ small fraction of the zone data.\r
+ o As the KSK is only used to sign a keyset, which is most probably\r
+ updated less frequently than other data in the zone, it can be\r
+ stored separately from (and thus in a safer location than) the\r
+ ZSK.\r
+ o A KSK can be used for longer periods.\r
+ o No parent/child interaction is required when ZSKs are updated.\r
+\r
+ The KSK is used less than ZSK, once a keyset is signed with the KSK\r
+ all the keys in the keyset can be used as ZSK. If a ZSK is\r
+ compromised, it can be simply dropped from the keyset. The new keyset\r
+ is then resigned with the KSK.\r
+\r
+ Given the assumption that for KSKs the SEP flag is set, the KSK can\r
+ be distinguished from a ZSK by examining the flag field in the DNSKEY\r
+ RR. If the flag field is an odd number it is a KSK if it is an even\r
+ number it is a ZSK e.g. a value of 256 and a key signing key has 257.\r
+\r
+ The zone-signing key can be used to sign all the data in a zone on a\r
+ regular basis. When a zone-signing key is to be rolled, no\r
+ interaction with the parent is needed. This allows for relatively\r
+ short "Signature Validity Periods". That is, Signature Validity\r
+ Periods of the order of days.\r
+\r
+ The key-signing key is only to be used to sign the Key RR set from\r
+ the zone apex. If a key-signing key is to be rolled over, there will\r
+ be interactions with parties other than the zone administrator such\r
+ as the registry of the parent zone or administrators of verifying\r
+ resolvers that have the particular key configured as trusted entry\r
+ points. Hence, the "Key Usage Time" of these keys can and should be\r
+ made much longer. Although, given a long enough key, the "Key Usage\r
+ Time" can be on the order of years we suggest to plan for a "Key\r
+ Usage Time" of the order of a few months so that a key rollover\r
+ remains an operational routine.\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 7]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+3.2 Key Security Considerations\r
+\r
+ Keys in DNSSEC have a number of parameters which should all be chosen\r
+ with care, the most important once are: size, algorithm and the key\r
+ validity period (its lifetime).\r
+\r
+3.2.1 Key Validity Period\r
+\r
+ RFC2541 [2] describes a number of considerations with respect to the\r
+ security of keys. The document deals with the generation, lifetime,\r
+ size and storage of private keys.\r
+\r
+ In Section 3 of RFC2541 [2] there are some suggestions for a key\r
+ validity period: 13 months for long-lived keys and 36 days for\r
+ transaction keys but suggestions for key sizes are not made.\r
+\r
+ If we say long-lived keys are key-signing keys and transactions keys\r
+ are zone-signing keys, these recommendations will lead to rollovers\r
+ occurring frequently enough to become part of 'operational habits';\r
+ the procedure does not have to be reinvented every time a key is\r
+ replaced.\r
+\r
+3.2.2 Key Algorithm\r
+\r
+ We recommend you choose RSA/SHA-1 as the preferred algorithm for the\r
+ key. RSA has been developed in an open and transparent manner. As the\r
+ patent on RSA expired in 2001, its use is now also free. The current\r
+ known attacks on RSA can be defeated by making your key longer. As\r
+ the MD5 hashing algorithm is showing (theoretical) cracks, we\r
+ recommend the usage of SHA1.\r
+\r
+3.2.3 Key Sizes\r
+\r
+ When choosing key sizes, zone administrators will need to take into\r
+ account how long a key will be used and how much data will be signed\r
+ during the key publication period. It is hard to give precise\r
+ recommendations but Lenstra and Verheul [9] supplied the following\r
+ table with lower bound estimates for cryptographic key sizes. Their\r
+ recommendations are based on a set of explicitly formulated parameter\r
+ settings, combined with existing data points about cryptosystems. For\r
+ details we refer to the original paper.\r
+\r
+ [Editor's Note: DSA???]\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 8]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ Year RSA Key Sizes Elliptic Curve Key Size\r
+ 2000 952 132\r
+ 2001 990 135\r
+ 2002 1028 139\r
+ 2003 1068 140\r
+ 2004 1108 143\r
+\r
+ 2005 1149 147\r
+ 2006 1191 148\r
+ 2007 1235 152\r
+ 2008 1279 155\r
+ 2009 1323 157\r
+\r
+\r
+ 2010 1369 160\r
+ 2011 1416 163\r
+ 2012 1464 165\r
+ 2013 1513 168\r
+ 2014 1562 172\r
+\r
+ 2015 1613 173\r
+ 2016 1664 177\r
+ 2017 1717 180\r
+ 2018 1771 181\r
+ 2019 1825 185\r
+\r
+\r
+ 2020 1881 188\r
+ 2021 1937 190\r
+ 2022 1995 193\r
+ 2023 2054 197\r
+ 2024 2113 198\r
+\r
+ 2025 2174 202\r
+ 2026 2236 205\r
+ 2027 2299 207\r
+ 2028 2362 210\r
+ 2029 2427 213\r
+\r
+ For example, should you wish your key to last three years from 2003,\r
+ check the RSA keysize values for 2006 in this table. In this case\r
+ 1191.\r
+\r
+3.3 Key Rollovers\r
+\r
+ Key rollovers are a fact of life when using DNSSEC. A DNSSEC key\r
+ cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone\r
+ administrators who are in the process of rolling their keys have to\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 9]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ take into account that data published in previous versions of their\r
+ zone still lives in caches. When deploying DNSSEC, this becomes an\r
+ important consideration; ignoring data that may be in caches may lead\r
+ to loss of service for clients.\r
+\r
+ The most pressing example of this is when zone material signed with\r
+ an old key is being validated by a resolver which does not have the\r
+ old zone key cached. If the old key is no longer present in the\r
+ current zone, this validation fails, marking the data bogus.\r
+ Alternatively, an attempt could be made to validate data which is\r
+ signed with a new key against an old key that lives in a local cache,\r
+ also resulting in data being marked bogus.\r
+\r
+ To appreciate the situation one could think of a number of\r
+ authoritative servers that may not be instantaneously running the\r
+ same version of a zone and a security aware non-recursive resolver\r
+ that sits behind security aware caching forwarders.\r
+\r
+ Note that KSK rollovers and ZSK rollovers are different. A zone-key\r
+ rollover can be handled in two different ways: pre-publish (Section\r
+ Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The\r
+ pre-publish technique works because the key-signing key stays the\r
+ same during this ZSK rollover. With this KSK a cache is able to\r
+ validate the new keyset of a zone. With a KSK rollover a cache can\r
+ not validate the new keyset, because it does not trust the new KSK.\r
+\r
+ [Editors note: This needs more verbose explanation, nobody will\r
+ appreciate the situation just yet. Help with text and examples is\r
+ appreciated]\r
+\r
+3.3.1 Zone-signing Key Rollovers\r
+\r
+ For zone-signing key rollovers there are two ways to make sure that\r
+ during the rollover data still cached can be verified with the new\r
+ keysets or newly generated signatures can be verified with the keys\r
+ still in caches. One schema uses double signatures, it is described\r
+ in Section 3.3.1.2, the other uses key pre-publication (Section\r
+ 3.3.1.1). The pros, cons and recommendations are described in Section\r
+ 3.3.1.3.\r
+\r
+3.3.1.1 Pre-publish Keyset Rollover\r
+\r
+ This section shows how to perform a ZSK rollover without the need to\r
+ sign all the data in a zone twice - the so called "prepublish\r
+ rollover". We recommend this method because it has advantages in the\r
+ case of key compromise. If the old key is compromised, the new key\r
+ has already been distributed in the DNS. The zone administrator is\r
+ then able to quickly switch to the new key and remove the compromised\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 10]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ key from the zone. Another major advantage is that the zone size does\r
+ not double, as is the case with the double signature ZSK rollover. A\r
+ small "HOWTO" for this kind of rollover can be found in Appendix B.\r
+\r
+ normal pre-roll roll after\r
+\r
+ SOA0 SOA1 SOA2 SOA3\r
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)\r
+\r
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1\r
+ DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11\r
+ DNSKEY11 DNSKEY11\r
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)\r
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)\r
+\r
+\r
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.\r
+ DNSKEY 10 is used to sign all the data of the zone, the\r
+ zone-signing key.\r
+ pre-roll: DNSKEY 11 is introduced into the keyset. Note that no\r
+ signatures are generated with this key yet, but this does not\r
+ secure against brute force attacks on the public key. The minimum\r
+ duration of this pre-roll phase is the time it takes for the data\r
+ to propagate to the authoritative servers plus TTL value of the\r
+ keyset. This equates to two times the Maximum Zone TTL.\r
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign\r
+ the data in the zone exclusively (i.e. all the signatures from\r
+ DNSKEY 10 are removed from the zone). DNSKEY 10 remains published\r
+ in the keyset. This way data that was loaded into caches from\r
+ version 1 of the zone can still be verified with key sets fetched\r
+ from version 2 of the zone.\r
+ The minimum time that the keyset including DNSKEY 10 is to be\r
+ published is the time that it takes for zone data from the\r
+ previous version of the zone to expire from old caches i.e. the\r
+ time it takes for this zone to propagate to all authoritative\r
+ servers plus the Maximum Zone TTL value of any of the data in the\r
+ previous version of the zone.\r
+ after: DNSKEY 10 is removed from the zone. The keyset, now only\r
+ containing DNSKEY 11 is resigned with the DNSKEY 1.\r
+\r
+ The above scheme can be simplified by always publishing the "future"\r
+ key immediately after the rollover. The scheme would look as follows\r
+ (we show two rollovers); the future key is introduced in "after" as\r
+ DNSKEY 12 and again a newer one, numbered 13, in "2nd after":\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 11]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ normal roll after 2nd roll 2nd after\r
+\r
+ SOA0 SOA2 SOA3 SOA4 SOA5\r
+ RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)\r
+\r
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1\r
+ DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12\r
+ DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13\r
+ RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)\r
+ RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)\r
+\r
+\r
+ Note that the key introduced after the rollover is not used for\r
+ production yet; the private key can thus be stored in a physically\r
+ secure manner and does not need to be 'fetched' every time a zone\r
+ needs to be signed.\r
+\r
+ This scheme has the benefit that the key that is intended for future\r
+ use: immediately during an emergency rollover assuming that the\r
+ private key was stored in a physically secure manner.\r
+\r
+3.3.1.2 Double Signature Zone-signing Key Rollover\r
+\r
+ This section shows how to perform a ZSK key rollover using the double\r
+ zone data signature scheme, aptly named "double sig rollover".\r
+\r
+ During the rollover stage the new version of the zone file will need\r
+ to propagate to all authoritative servers and the data that exists in\r
+ (distant) caches will need to expire, this will take at least the\r
+ maximum Zone TTL .\r
+\r
+ normal roll after\r
+\r
+ SOA0 SOA1 SOA2\r
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)\r
+ RRSIG11(SOA1)\r
+\r
+ DNSKEY1 DNSKEY1 DNSKEY1\r
+ DNSKEY10 DNSKEY10 DNSKEY11\r
+ DNSKEY11\r
+ RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)\r
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)\r
+ RRSIG11(DNSKEY)\r
+\r
+ normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.\r
+ DNSKEY 10 is used to sign all the data of the zone, the\r
+ zone-signing key.\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 12]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced\r
+ into the keyset and all the data in the zone is signed with DNSKEY\r
+ 10 and DNSKEY 11. The rollover period will need to exist until all\r
+ data from version 0 of the zone has expired from remote caches.\r
+ This will take at least the maximum Zone TTL of version 0 of the\r
+ zone.\r
+ after: DNSKEY 10 is removed from the zone. All the signatures from\r
+ DNSKEY 10 are removed from the zone. The keyset, now only\r
+ containing DNSKEY 11, is resigned with DNSKEY 1.\r
+\r
+ At every instance the data from the previous version of the zone can\r
+ be verified with the key from the current version and vice verse. The\r
+ data from the current version can be verified with the data from the\r
+ previous version of the zone. The duration of the rollover phase and\r
+ the period between rollovers should be at least the "Maximum Zone\r
+ TTL".\r
+\r
+ Making sure that the rollover phase lasts until the signature\r
+ expiration time of the data in version 0 of the zone is recommended.\r
+ However, this date could be considerably longer than the Maximum Zone\r
+ TTL, making the rollover a lengthy procedure.\r
+\r
+ Note that in this example we assumed that the zone was not modified\r
+ during the rollover. New data can be introduced in the zone as long\r
+ as it is signed with both keys.\r
+\r
+3.3.1.3 Pros and Cons of the Schemes\r
+\r
+ Prepublish-keyset rollover: This rollover does not involve signing\r
+ the zone data twice. Instead, just before the actual rollover, the\r
+ new key is published in the keyset and thus available for\r
+ cryptanalysis attacks. A small disavantage is that this process\r
+ requires four steps. Also the prepublish scheme will not work for\r
+ KSKs as explained in Section 3.3.\r
+ Double signature rollover: The drawback of this signing scheme is\r
+ that during the rollover the number of signatures in your zone\r
+ doubles, this may be prohibitive if you have very big zones. An\r
+ advantage is that it only requires three steps.\r
+\r
+3.3.2 Key-signing Key Rollovers\r
+\r
+ For the rollover of a key-signing key the same considerations as for\r
+ the rollover of a zone-signing key apply. However we can use a double\r
+ signature scheme to guarantee that old data (only the apex keyset) in\r
+ caches can be verified with a new keyset and vice versa.\r
+\r
+ Since only the keyset is signed with a KSK, zone size considerations\r
+ do not apply.\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 13]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ normal roll after\r
+\r
+ SOA0 SOA1 SOA2\r
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)\r
+\r
+ DNSKEY1 DNSKEY1 DNSKEY2\r
+ DNSKEY2\r
+ DNSKEY10 DNSKEY10 DNSKEY10\r
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)\r
+ RRSIG2 (DNSKEY)\r
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)\r
+\r
+ normal: Version 0 of the zone. The parental DS points to DNSKEY1.\r
+ Before the rollover starts the child will have to verify what the\r
+ TTL is of the DS RR that points to DNSKEY1 - it is needed during\r
+ the rollover and we refer to the value as TTL_DS.\r
+ roll: During the rollover phase the zone administrator generates a\r
+ second KSK, DNSKEY2. The key is provided to the parent and the\r
+ child will have to wait until a new DS RR has been generated that\r
+ points to DNSKEY2. After that DS RR has been published on _all_\r
+ servers authoritative for the parents zone, the zone administrator\r
+ has to wait at least TTL_DS to make sure that the old DS RR has\r
+ expired from distant caches.\r
+ after: DNSKEY1 has been removed.\r
+\r
+ The scenario above puts the responsibility for maintaining a valid\r
+ chain of trust with the child. It also is based on the premises that\r
+ the parent only has one DS RR (per algorithm) per zone. St John [The\r
+ draft has expired] proposed a mechanism where using an established\r
+ trust relation, the interaction can be performed in-band. In this\r
+ mechanism there are periods where there are two DS RRs at the parent.\r
+\r
+ [Editors note: We probably need to mention more]\r
+\r
+4. Planning for Emergency Key Rollover\r
+\r
+ This section deals with preparation for a possible key compromise.\r
+ Our advice is to have a documented procedure ready for when a key\r
+ compromise is suspected or confirmed.\r
+\r
+ [Editors note: We are much in favor of a rollover tactic that keeps\r
+ the authentication chain intact as long as possible. This means that\r
+ one has to take all the regular rollover properties into account.]\r
+\r
+ When the private material of one of your keys is compromised it can\r
+ be used for as long as a valid authentication chain exists. An\r
+ authentication chain remains intact for:\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 14]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ o as long as a signature over the compromised key in the\r
+ authentication chain is valid,\r
+ o as long as a parental DS RR (and signature) points to the\r
+ compromised key,\r
+ o as long as the key is anchored in a resolver and is used as a\r
+ starting point for validation. (This is the hardest to update.)\r
+ While an authentication chain to your compromised key exists, your\r
+ name-space is vulnerable to abuse by the malicious key holder (i.e.\r
+ the owner of the compromised key). Zone operators have to make a\r
+ trade off if the abuse of the compromised key is worse than having\r
+ data in caches that cannot be validated. If the zone operator chooses\r
+ to break the authentication chain to the compromised key, data in\r
+ caches signed with this key cannot be validated. However, if the zone\r
+ administrator chooses to take the path of a regular roll-over, the\r
+ malicious key holder can spoof data so that it appears to be valid,\r
+ note that this kind of attack will usually be localised in the\r
+ Internet topology.\r
+\r
+\r
+4.1 KSK Compromise\r
+\r
+ When the KSK has been compromised the parent must be notified as soon\r
+ as possible using secure means. The keyset of the zone should be\r
+ resigned as soon as possible. Care must be taken to not break the\r
+ authentication chain. The local zone can only be resigned with the\r
+ new KSK after the parent's zone has been updated with the new KSK.\r
+ Before this update takes place it would be best to drop the security\r
+ status of a zone all together: the parent removes the DS of the child\r
+ at the next zone update. After that the child can be made secure\r
+ again.\r
+\r
+ An additional danger of a key compromise is that the compromised key\r
+ can be used to facilitate a legitimate DNSKEY/DS and/or nameserver\r
+ rollover at the parent. When that happens the domain can be in\r
+ dispute. An out of band and secure notify mechanism to contact a\r
+ parent is needed in this case.\r
+\r
+4.2 ZSK Compromise\r
+\r
+ Primarily because there is no parental interaction required when a\r
+ ZSK is compromised, the situation is less severe than with with a KSK\r
+ compromise. The zone must still be resigned with a new ZSK as soon\r
+ as possible. As this is a local operation and requires no\r
+ communication between the parent and child this can be achieved\r
+ fairly quickly. However, one has to take into account that just as\r
+ with a normal rollover the immediate disappearance from the old\r
+ compromised key may lead to verification problems. The\r
+ pre-publication scheme as discussed above minimises such problems.\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 15]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+4.3 Compromises of Keys Anchored in Resolvers\r
+\r
+ A key can also be pre-configured in resolvers. If DNSSEC is rolled\r
+ out as planned the root key should be pre-configured in every secure\r
+ aware resolver on the planet. [Editors Note: add more about\r
+ authentication of a newly received resolver key]\r
+\r
+ If trust-anchor keys are compromised, the resolvers using these keys\r
+ should be notified of this fact. Zone administrators may consider\r
+ setting up a mailing list to communicate the fact that a SEP key is\r
+ about to be rolled over. This communication will of course need to be\r
+ authenticated e.g. by using digital signatures.\r
+\r
+5. Parental Policies\r
+\r
+5.1 Initial Key Exchanges and Parental Policies Considerations\r
+\r
+ The initial key exchange is always subject to the policies set by the\r
+ parent (or its registry). When designing a key exchange policy one\r
+ should take into account that the authentication and authorisation\r
+ mechanisms used during a key exchange should be as strong as the\r
+ authentication and authorisation mechanisms used for the exchange of\r
+ delegation information between parent and child.\r
+\r
+ Using the DNS itself as the source for the actual DNSKEY material,\r
+ with an off-band check on the validity of the DNSKEY, has the benefit\r
+ that it reduces the chances of user error. A parental DNSKEY download\r
+ tool can make use of the SEP bit [4] to select the proper key from a\r
+ DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is\r
+ sent. It can validate the self-signature over a key; thereby\r
+ verifying the ownership of the private key material. Fetching the\r
+ DNSKEY from the DNS ensures that the child will not become bogus once\r
+ the parent publishes the DS RR indicating the child is secure.\r
+\r
+ Note: the off-band verification is still needed when the key-material\r
+ is fetched by a tool. The parent can not be sure whether the DNSKEY\r
+ RRs have been spoofed.\r
+\r
+5.2 Storing Keys So Hashes Can Be Regenerated\r
+\r
+ When designing a registry system one should consider if the DNSKEYs\r
+ and/or the corresponding DSs are stored. Storing DNSKEYs will help\r
+ during troubleshooting while the overhead of calculating DS records\r
+ from them is minimal.\r
+\r
+ Having an out-of-band mechanism, such as a Whois database, to find\r
+ out which keys are used to generate DS Resource Records for specific\r
+ owners may also help with troubleshooting.\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 16]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+5.3 Security Lameness Checks\r
+\r
+ Security Lameness is defined as what happens when a parent has a DS\r
+ Resource Record pointing to a non-existing DNSKEY RR. During key\r
+ exchange a parent should make sure that the child's key is actually\r
+ configured in the DNS before publishing a DS RR in its zone. Failure\r
+ to do so would render the child's zone being marked as bogus.\r
+\r
+ Child zones should be very careful removing DNSKEY material,\r
+ specifically SEP keys, for which a DS RR exists.\r
+\r
+ Once a zone is "security lame" a fix (e.g. by removing a DS RR) will\r
+ take time to propagate through the DNS.\r
+\r
+5.4 DS Signature Validity Period\r
+\r
+ Since the DS can be replayed as long as it has a valid signature a\r
+ short signature validity period over the DS minimises the time a\r
+ child is vulnerable in the case of a compromise of the child's\r
+ KSK(s). A signature validity period that is too short introduces the\r
+ possibility that a zone is marked bogus in case of a configuration\r
+ error in the signer; there may not be enough time to fix the problems\r
+ before signatures expire. Something as mundane as operator\r
+ unavailability during weekends shows the need for DS signature\r
+ lifetimes longer than 2 days. We recommend the minimum for a DS\r
+ signature validity period to be a few days.\r
+\r
+ The maximum signature lifetime of the DS record depends on how long\r
+ child zones are willing to be vulnerable after a key compromise. We\r
+ consider a signature validity period of around one week to be a good\r
+ compromise between the operational constraints of the parent and\r
+ minimising damage for the child.\r
+\r
+6. Security Considerations\r
+\r
+ DNSSEC adds data integrity to the DNS. This document tries to assess\r
+ considerations to operate a stable and secure DNSSEC service. Not\r
+ taking into account the 'data propagation' properties in the DNS will\r
+ cause validation failures and may make secured zones unavailable to\r
+ security aware resolvers.\r
+\r
+7. Acknowledgments\r
+\r
+ We, the folk mentioned as authors, only acted as editors. Most of the\r
+ ideas in this draft were the result of collective efforts during\r
+ workshops, discussions and try outs.\r
+\r
+ At the risk of forgetting individuals who where the original\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 17]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ contributors of the ideas we would like to acknowledge people who\r
+ where actively involved in the compilation of this document. In\r
+ random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,\r
+ Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier\r
+ Courtay, Sam Weiler.\r
+\r
+ Emma Bretherick and Adrian Bedford corrected many of the spelling and\r
+ style issues.\r
+\r
+ Kolkman and Gieben take the blame for introducing all miscakes(SIC).\r
+\r
+8. References\r
+\r
+8.1 Normative References\r
+\r
+ [1] Eastlake, D., "Domain Name System Security Extensions", RFC\r
+ 2535, March 1999.\r
+\r
+ [2] Eastlake, D., "DNS Security Operational Considerations", RFC\r
+ 2541, March 1999.\r
+\r
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone\r
+ Status", RFC 3090, March 2001.\r
+\r
+ [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key\r
+ (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work\r
+ in progress), February 2003.\r
+\r
+8.2 Informative References\r
+\r
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement\r
+ Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC\r
+ 2308, March 1998.\r
+\r
+ [7] Gudmundsson, O., "Delegation Signer Resource Record",\r
+ draft-ietf-dnsext-delegation-signer-13 (work in progress), March\r
+ 2003.\r
+\r
+ [8] Arends, R., "Protocol Modifications for the DNS Security\r
+ Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in\r
+ progress), March 2003.\r
+\r
+ [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",\r
+ The Journal of Cryptology 14 (255-293), 2001.\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 18]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+Authors' Addresses\r
+\r
+ Olaf M. Kolkman\r
+ RIPE NCC\r
+ Singel 256\r
+ Amsterdam 1016 AB\r
+ The Netherlands\r
+\r
+ Phone: +31 20 535 4444\r
+ EMail: olaf@ripe.net\r
+ URI: http://www.ripe.net/\r
+\r
+\r
+ Miek Gieben\r
+ NLnet Labs\r
+ Kruislaan 419\r
+ Amsterdam 1098 VA\r
+ The Netherlands\r
+\r
+ EMail: miek@nlnetlabs.nl\r
+ URI: http://www.nlnetlabs.nl\r
+\r
+Appendix A. Terminology\r
+\r
+ In this document there is some jargon used that is defined in other\r
+ documents. In most cases we have not copied the text from the\r
+ documents defining the terms but given a more elaborate explanation\r
+ of the meaning. Note that these explanations should not be seen as\r
+ authoritative.\r
+\r
+ Private and Public Keys: DNSSEC secures the DNS through the use of\r
+ public key cryptography. Public key cryptography is based on the\r
+ existence of two keys, a public key and a private key. The public\r
+ keys are published in the DNS by use of the DNSKEY Resource Record\r
+ (DNSKEY RR). Private keys should remain private i.e. should not be\r
+ exposed to parties not-authorised to do the actual signing.\r
+ Signer: The system that has access to the private key material and\r
+ signs the Resource Record sets in a zone. A signer may be\r
+ configured to sign only parts of the zone e.g. only those RRsets\r
+ for which existing signatures are about to expire.\r
+ KSK: A Key-Signing Key (KSK) is a key that is used exclusively for\r
+ signing the apex keyset. The fact that a key is a KSK is only\r
+ relevant to the signing tool.\r
+ ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all\r
+ data in a zone. The fact that a key is a ZSK is only relevant to\r
+ the signing tool.\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 19]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ SEP Key: A KSK that has a parental DS record pointing to it. Note:\r
+ this is not enforced in the protocol. A SEP Key with no parental\r
+ DS is security lame.\r
+ Anchored Key: A DNSKEY configured in resolvers around the globe. This\r
+ Key is hard to update, hence the term anchored.\r
+ Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked\r
+ "Bogus" when a signature of a RRset does not validate against the\r
+ DNSKEY. Even if the key itself was not marked Bogus. A cache may\r
+ choose to cache Bogus data for various reasons.\r
+ Singing the Zone File: The term used for the event where an\r
+ administrator joyfully signs its zone file while producing melodic\r
+ sound patterns.\r
+ Zone Administrator: The 'role' that is responsible for signing a zone\r
+ and publishing it on the primary authoritative server.\r
+\r
+Appendix B. Zone-signing Key Rollover Howto\r
+\r
+ Using the pre-published signature scheme and the most conservative\r
+ method to assure oneself that data does not live in distant caches\r
+ here follows the "HOWTO". [WES: has some comments about this]\r
+ Key notation:\r
+ Step 0: The preparation: Create two keys and publish both in your\r
+ keyset. Mark one of the keys as "active" and the other as\r
+ "published". Use the "active" key for signing your zone data.\r
+ Store the private part of the "published" key, preferably\r
+ off-line.\r
+ Step 1: Determine expiration: At the beginning of the rollover make a\r
+ note of the highest expiration time of signatures in your zone\r
+ file created with the current key marked as "active".\r
+ Wait until the expiration time marked in Step 1 has passed\r
+ Step 2: Then start using the key that was marked as "published" to\r
+ sign your data i.e. mark it as "active". Stop using the key that\r
+ was marked as "active", mark it as "rolled".\r
+ Step 3: It is safe to engage in a new rollover (Step 1) after at\r
+ least one "signature validity period".\r
+\r
+Appendix C. Typographic Conventions\r
+\r
+ The following typographic conventions are used in this document:\r
+ Key notation: A key is denoted by KEYx, where x is a number, x could\r
+ be thought of as the key id.\r
+ RRset notations: RRs are only denoted by the type. All other\r
+ information - owner, class, rdata and TTL - is left out. Thus:\r
+ example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a\r
+ list of RRs. A example of this would be: A1,A2, specifying the\r
+ RRset containing two A records. This could again be abbreviated to\r
+ just: A.\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 20]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ Signature notation: Signatures are denoted as RRSIGx(RRset), which\r
+ means that RRset is signed with DNSKEYx.\r
+ Zone representation: Using the above notation we have simplified the\r
+ representation of a signed zone by leaving out all unnecessary\r
+ details such as the names and by representing all data by "SOAx"\r
+ SOA representation: SOA's are represented as SOAx, where x is the\r
+ serial number.\r
+ Using this notation the following zone :\r
+\r
+\r
+ example.net. 600 IN SOA ns.example.net. ernie.example.net. (\r
+ 10 ; serial\r
+ 450 ; refresh (7 minutes 30 seconds)\r
+ 600 ; retry (10 minutes)\r
+ 345600 ; expire (4 days)\r
+ 300 ; minimum (5 minutes)\r
+ )\r
+ 600 RRSIG SOA 5 2 600 20130522213204 (\r
+ 20130422213204 14 example.net.\r
+ cmL62SI6iAX46xGNQAdQ... )\r
+ 600 NS a.iana-servers.net.\r
+ 600 NS b.iana-servers.net.\r
+ 600 RRSIG NS 5 2 600 20130507213204 (\r
+ 20130407213204 14 example.net.\r
+ SO5epiJei19AjXoUpFnQ ... )\r
+ 3600 DNSKEY 256 3 5 (\r
+ EtRB9MP5/AvOuVO0I8XDxy0...\r
+ ) ; key id = 14\r
+ 3600 DNSKEY 256 3 5 (\r
+ gsPW/Yy19GzYIY+Gnr8HABU...\r
+ ) ; key id = 15\r
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (\r
+ 20130422213204 14 example.net.\r
+ J4zCe8QX4tXVGjV4e1r9... )\r
+ 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (\r
+ 20130422213204 15 example.net.\r
+ keVDCOpsSeDReyV6O... )\r
+ 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC\r
+ 600 RRSIG NSEC 5 2 600 20130507213204 (\r
+ 20130407213204 14 example.net.\r
+ obj3HEp1GjnmhRjX... )\r
+ a.example.net. 600 IN TXT "A label"\r
+ 600 RRSIG TXT 5 3 600 20130507213204 (\r
+ 20130407213204 14 example.net.\r
+ IkDMlRdYLmXH7QJnuF3v... )\r
+ 600 NSEC b.example.com. TXT RRSIG NSEC\r
+ 600 RRSIG NSEC 5 3 600 20130507213204 (\r
+ 20130407213204 14 example.net.\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 21]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ bZMjoZ3bHjnEz0nIsPMM... )\r
+\r
+ ...\r
+\r
+\r
+ is reduced to the following represenation:\r
+\r
+ SOA10\r
+ RRSIG14(SOA10)\r
+\r
+ DNSKEY14\r
+ DNSKEY15\r
+\r
+ RRSIG14(KEY)\r
+ RRSIG15(KEY)\r
+\r
+ The rest of the zone data has the same signature as the SOA record,\r
+ i.e a RRSIG created with DNSKEY 14.\r
+\r
+Appendix D. Document Details and Changes\r
+\r
+ This section is to be removed by the RFC editor if and when the\r
+ document is published.\r
+\r
+ $Header: /var/cvs/dnssec-key/\r
+ draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12\r
+ 08:29:11 dnssec Exp $\r
+\r
+D.1 draft-ietf-dnsop-dnssec-operational-practices-00\r
+\r
+ Submission as working group document. This document is a modified and\r
+ updated version of draft-kolkman-dnssec-operational-practices-00.\r
+\r
+D.2 draft-ietf-dnsop-dnssec-operational-practices-01\r
+\r
+ changed the definition of "Bogus" to reflect the one in the protocol\r
+ draft.\r
+\r
+ Bad to Bogus\r
+\r
+ Style and spelling corrections\r
+\r
+ KSK - SEP mapping made explicit.\r
+\r
+ Updates from Sam Weiler added\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 22]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+Intellectual Property Statement\r
+\r
+ The IETF takes no position regarding the validity or scope of any\r
+ intellectual property or other rights that might be claimed to\r
+ pertain to the implementation or use of the technology described in\r
+ this document or the extent to which any license under such rights\r
+ might or might not be available; neither does it represent that it\r
+ has made any effort to identify any such rights. Information on the\r
+ IETF's procedures with respect to rights in standards-track and\r
+ standards-related documentation can be found in BCP-11. Copies of\r
+ claims of rights made available for publication and any assurances of\r
+ licenses to be made available, or the result of an attempt made to\r
+ obtain a general license or permission for the use of such\r
+ proprietary rights by implementors or users of this specification can\r
+ be obtained from the IETF Secretariat.\r
+\r
+ The IETF invites any interested party to bring to its attention any\r
+ copyrights, patents or patent applications, or other proprietary\r
+ rights which may cover technology that may be required to practice\r
+ this standard. Please address the information to the IETF Executive\r
+ Director.\r
+\r
+\r
+Full Copyright Statement\r
+\r
+ Copyright (C) The Internet Society (2004). All Rights Reserved.\r
+\r
+ This document and translations of it may be copied and furnished to\r
+ others, and derivative works that comment on or otherwise explain it\r
+ or assist in its implementation may be prepared, copied, published\r
+ and distributed, in whole or in part, without restriction of any\r
+ kind, provided that the above copyright notice and this paragraph are\r
+ included on all such copies and derivative works. However, this\r
+ document itself may not be modified in any way, such as by removing\r
+ the copyright notice or references to the Internet Society or other\r
+ Internet organizations, except as needed for the purpose of\r
+ developing Internet standards in which case the procedures for\r
+ copyrights defined in the Internet Standards process must be\r
+ followed, or as required to translate it into languages other than\r
+ English.\r
+\r
+ The limited permissions granted above are perpetual and will not be\r
+ revoked by the Internet Society or its successors or assignees.\r
+\r
+ This document and the information contained herein is provided on an\r
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 23]\r
+\f\r
+Internet-Draft DNSSEC Operational Practices March 2004\r
+\r
+\r
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+Acknowledgment\r
+\r
+ Funding for the RFC Editor function is currently provided by the\r
+ Internet Society.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Kolkman & Gieben Expires August 30, 2004 [Page 24]\r
+\f\r
+\r
projects / thirdparty / bind9.git / commitdiff
