diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc4641.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc4641.txt | 1963 |
1 files changed, 0 insertions, 1963 deletions
diff --git a/contrib/bind9/doc/rfc/rfc4641.txt b/contrib/bind9/doc/rfc/rfc4641.txt deleted file mode 100644 index 0a013bc..0000000 --- a/contrib/bind9/doc/rfc/rfc4641.txt +++ /dev/null @@ -1,1963 +0,0 @@ - - - - - - -Network Working Group O. Kolkman -Request for Comments: 4641 R. Gieben -Obsoletes: 2541 NLnet Labs -Category: Informational September 2006 - - - DNSSEC Operational Practices - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a set of practices for operating the DNS with - security extensions (DNSSEC). The target audience is zone - administrators deploying DNSSEC. - - The document discusses operational aspects of using keys and - signatures in the DNS. It discusses issues of key generation, key - storage, signature generation, key rollover, and related policies. - - This document obsoletes RFC 2541, as it covers more operational - ground and gives more up-to-date requirements with respect to key - sizes and the new DNSSEC specification. - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Informational [Page 1] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. The Use of the Term 'key' ..................................4 - 1.2. Time Definitions ...........................................4 - 2. Keeping the Chain of Trust Intact ...............................5 - 3. Keys Generation and Storage .....................................6 - 3.1. Zone and Key Signing Keys ..................................6 - 3.1.1. Motivations for the KSK and ZSK Separation ..........6 - 3.1.2. KSKs for High-Level Zones ...........................7 - 3.2. Key Generation .............................................8 - 3.3. Key Effectivity Period .....................................8 - 3.4. Key Algorithm ..............................................9 - 3.5. Key Sizes ..................................................9 - 3.6. Private Key Storage .......................................11 - 4. Signature Generation, Key Rollover, and Related Policies .......12 - 4.1. Time in DNSSEC ............................................12 - 4.1.1. Time Considerations ................................12 - 4.2. Key Rollovers .............................................14 - 4.2.1. Zone Signing Key Rollovers .........................14 - 4.2.1.1. Pre-Publish Key Rollover ..................15 - 4.2.1.2. Double Signature Zone Signing Key - Rollover ..................................17 - 4.2.1.3. Pros and Cons of the Schemes ..............18 - 4.2.2. Key Signing Key Rollovers ..........................18 - 4.2.3. Difference Between ZSK and KSK Rollovers ...........20 - 4.2.4. Automated Key Rollovers ............................21 - 4.3. Planning for Emergency Key Rollover .......................21 - 4.3.1. KSK Compromise .....................................22 - 4.3.1.1. Keeping the Chain of Trust Intact .........22 - 4.3.1.2. Breaking the Chain of Trust ...............23 - 4.3.2. ZSK Compromise .....................................23 - 4.3.3. Compromises of Keys Anchored in Resolvers ..........24 - 4.4. Parental Policies .........................................24 - 4.4.1. Initial Key Exchanges and Parental Policies - Considerations .....................................24 - 4.4.2. Storing Keys or Hashes? ............................25 - 4.4.3. Security Lameness ..................................25 - 4.4.4. DS Signature Validity Period .......................26 - 5. Security Considerations ........................................26 - 6. Acknowledgments ................................................26 - 7. References .....................................................27 - 7.1. Normative References ......................................27 - 7.2. Informative References ....................................28 - Appendix A. Terminology ...........................................30 - Appendix B. Zone Signing Key Rollover How-To ......................31 - Appendix C. Typographic Conventions ...............................32 - - - - -Kolkman & Gieben Informational [Page 2] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -1. Introduction - - This document describes how to run a DNS Security (DNSSEC)-enabled - environment. It is intended for operators who have knowledge of the - DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. - See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the - newly introduced Resource Records (RRs), and RFC 4035 [6] for the - protocol changes. - - During workshops and early operational deployment tests, operators - and system administrators have gained experience about operating the - DNS with security extensions (DNSSEC). This document translates - these experiences into a set of practices for zone administrators. - At the time of writing, there exists very little experience with - DNSSEC in production environments; this document should therefore - explicitly not be seen as representing 'Best Current Practices'. - - The procedures herein are focused on the maintenance of signed zones - (i.e., signing and publishing zones on authoritative servers). It is - intended that maintenance of zones such as re-signing or key - rollovers be transparent to any verifying clients on the Internet. - - The structure of this document is as follows. In Section 2, we - discuss the importance of keeping the "chain of trust" intact. - Aspects of key generation and storage of private keys are discussed - in Section 3; the focus in this section is mainly on the private part - of the key(s). Section 4 describes considerations concerning the - public part of the keys. Since these public keys appear in the DNS - one has to take into account all kinds of timing issues, which are - discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the - rollover, or supercession, of keys. Finally, Section 4.4 discusses - considerations on how parents deal with their children's public keys - in order to maintain chains of trust. - - The typographic conventions used in this document are explained in - Appendix C. - - Since this is a document with operational suggestions and there are - no protocol specifications, the RFC 2119 [7] language does not apply. - - This document obsoletes RFC 2541 [12] to reflect the evolution of the - underlying DNSSEC protocol since then. Changes in the choice of - cryptographic algorithms, DNS record types and type names, and the - parent-child key and signature exchange demanded a major rewrite and - additional information and explanation. - - - - - - -Kolkman & Gieben Informational [Page 3] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -1.1. The Use of the Term 'key' - - It is assumed that the reader is familiar with the concept of - asymmetric keys on which DNSSEC is based (public key cryptography - [17]). Therefore, this document will use the term 'key' rather - loosely. Where it is written that 'a key is used to sign data' it is - assumed that the reader understands that it is the private part of - the key pair that is used for signing. It is also assumed that the - reader understands that the public part of the key pair is published - in the DNSKEY Resource Record and that it is the public part that is - used in key exchanges. - -1.2. Time Definitions - - In this document, we will be using a number of time-related terms. - The following definitions apply: - - o "Signature validity period" The period that a signature is valid. - It starts at the time specified in the signature inception field - of the RRSIG RR and ends at the time specified in the expiration - field of the RRSIG RR. - - o "Signature publication period" Time after which a signature (made - with a specific key) is replaced with a new signature (made with - the same key). This replacement takes place by publishing the - relevant RRSIG in the master zone file. After one stops - publishing an RRSIG in a zone, it may take a while before the - RRSIG has expired from caches and has actually been removed from - the DNS. - - o "Key effectivity period" The period during which a key pair is - expected to be effective. This period is defined as the time - between the first inception time stamp and the last expiration - date of any signature made with this key, regardless of any - discontinuity in the use of the key. The key effectivity period - can span multiple signature validity periods. - - o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum - value of the TTLs from the complete set of RRs in a zone. Note - that the minimum TTL is not the same as the MINIMUM field in the - SOA RR. See [11] for more information. - - - - - - - - - - -Kolkman & Gieben Informational [Page 4] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -2. Keeping the Chain of Trust Intact - - Maintaining a valid chain of trust is important because broken chains - of trust will result in data being marked as Bogus (as defined in [4] - Section 5), which may cause entire (sub)domains to become invisible - to verifying clients. The administrators of secured zones have to - realize that their zone is, to verifying clients, part of a chain of - trust. - - As mentioned in the introduction, the procedures herein are intended - to ensure that maintenance of zones, such as re-signing or key - rollovers, will be transparent to the verifying clients on the - Internet. - - Administrators of secured zones will have to keep in mind that data - published on an authoritative primary server will not be immediately - seen by verifying clients; it may take some time for the data to be - transferred to other secondary authoritative nameservers and clients - may be fetching data from caching non-authoritative servers. In this - light, note that the time for a zone transfer from master to slave is - negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. - It increases when full zone transfers (AXFR) are used in combination - with NOTIFY. It increases even more if you rely on full zone - transfers based on only the SOA timing parameters for refresh. - - For the verifying clients, it is important that data from secured - zones can be used to build chains of trust regardless of whether the - data came directly from an authoritative server, a caching - nameserver, or some middle box. Only by carefully using the - available timing parameters can a zone administrator ensure that the - data necessary for verification can be obtained. - - The responsibility for maintaining the chain of trust is shared by - administrators of secured zones in the chain of trust. This is most - obvious in the case of a 'key compromise' when a trade-off between - maintaining a valid chain of trust and replacing the compromised keys - as soon as possible must be made. Then zone administrators will have - to make a trade-off, between keeping the chain of trust intact -- - thereby allowing for attacks with the compromised key -- or - deliberately breaking the chain of trust and making secured - subdomains invisible to security-aware resolvers. Also see Section - 4.3. - - - - - - - - - -Kolkman & Gieben Informational [Page 5] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -3. Keys Generation and Storage - - This section describes a number of considerations with respect to the - security of keys. It deals with the generation, effectivity period, - size, and storage of private keys. - -3.1. Zone and Key Signing Keys - - The DNSSEC validation protocol does not distinguish between different - types of DNSKEYs. All DNSKEYs can be used during the validation. In - practice, operators use Key Signing and Zone Signing Keys and use the - so-called Secure Entry Point (SEP) [3] flag to distinguish between - them during operations. The dynamics and considerations are - discussed below. - - To make zone re-signing and key rollover procedures easier to - implement, it is possible to use one or more keys as Key Signing Keys - (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. - Other keys can be used to sign all the RRSets in a zone and are - referred to as Zone Signing Keys (ZSKs). In this document, we assume - that KSKs are the subset of keys that are used for key exchanges with - the parent and potentially for configuration as trusted anchors -- - the SEP keys. In this document, we assume a one-to-one mapping - between KSK and SEP keys and we assume the SEP flag to be set on all - KSKs. - -3.1.1. Motivations for the KSK and ZSK Separation - - Differentiating between the KSK and ZSK functions has several - advantages: - - o No parent/child interaction is required when ZSKs are updated. - - o The KSK can be made stronger (i.e., using more bits in the key - material). This has little operational impact since it is only - used to sign a small fraction of the zone data. Also, the KSK is - only used to verify the zone's key set, not for other RRSets in - the zone. - - o As the KSK is only used to sign a key set, which is most probably - updated less frequently than other data in the zone, it can be - stored separately from and in a safer location than the ZSK. - - o A KSK can have a longer key effectivity period. - - For almost any method of key management and zone signing, the KSK is - used less frequently than the ZSK. Once a key set is signed with the - KSK, all the keys in the key set can be used as ZSKs. If a ZSK is - - - -Kolkman & Gieben Informational [Page 6] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - compromised, it can be simply dropped from the key set. The new key - set is then re-signed with the KSK. - - Given the assumption that for KSKs the SEP flag is set, the KSK can - be distinguished from a ZSK by examining the flag field in the DNSKEY - RR. If the flag field is an odd number it is a KSK. If it is an - even number it is a ZSK. - - The Zone Signing Key can be used to sign all the data in a zone on a - regular basis. When a Zone Signing Key is to be rolled, no - interaction with the parent is needed. This allows for signature - validity periods on the order of days. - - The Key Signing Key is only to be used to sign the DNSKEY RRs in a - zone. If a Key Signing Key is to be rolled over, there will be - interactions with parties other than the zone administrator. These - can include the registry of the parent zone or administrators of - verifying resolvers that have the particular key configured as secure - entry points. Hence, the key effectivity period of these keys can - and should be made much longer. Although, given a long enough key, - the key effectivity period can be on the order of years, we suggest - planning for a key effectivity on the order of a few months so that a - key rollover remains an operational routine. - -3.1.2. KSKs for High-Level Zones - - Higher-level zones are generally more sensitive than lower-level - zones. Anyone controlling or breaking the security of a zone thereby - obtains authority over all of its subdomains (except in the case of - resolvers that have locally configured the public key of a subdomain, - in which case this, and only this, subdomain wouldn't be affected by - the compromise of the parent zone). Therefore, extra care should be - taken with high-level zones, and strong keys should be used. - - The root zone is the most critical of all zones. Someone controlling - or compromising the security of the root zone would control the - entire DNS namespace of all resolvers using that root zone (except in - the case of resolvers that have locally configured the public key of - a subdomain). Therefore, the utmost care must be taken in the - securing of the root zone. The strongest and most carefully handled - keys should be used. The root zone private key should always be kept - off-line. - - Many resolvers will start at a root server for their access to and - authentication of DNS data. Securely updating the trust anchors in - an enormous population of resolvers around the world will be - extremely difficult. - - - - -Kolkman & Gieben Informational [Page 7] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -3.2. Key Generation - - Careful generation of all keys is a sometimes overlooked but - absolutely essential element in any cryptographically secure system. - The strongest algorithms used with the longest keys are still of no - use if an adversary can guess enough to lower the size of the likely - key space so that it can be exhaustively searched. Technical - suggestions for the generation of random keys will be found in RFC - 4086 [14]. One should carefully assess if the random number - generator used during key generation adheres to these suggestions. - - Keys with a long effectivity period are particularly sensitive as - they will represent a more valuable target and be subject to attack - for a longer time than short-period keys. It is strongly recommended - that long-term key generation occur off-line in a manner isolated - from the network via an air gap or, at a minimum, high-level secure - hardware. - -3.3. Key Effectivity Period - - For various reasons, keys in DNSSEC need to be changed once in a - while. The longer a key is in use, the greater the probability that - it will have been compromised through carelessness, accident, - espionage, or cryptanalysis. Furthermore, when key rollovers are too - rare an event, they will not become part of the operational habit and - there is risk that nobody on-site will remember the procedure for - rollover when the need is there. - - From a purely operational perspective, a reasonable key effectivity - period for Key Signing Keys is 13 months, with the intent to replace - them after 12 months. An intended key effectivity period of a month - is reasonable for Zone Signing Keys. - - For key sizes that match these effectivity periods, see Section 3.5. - - As argued in Section 3.1.2, securely updating trust anchors will be - extremely difficult. On the other hand, the "operational habit" - argument does also apply to trust anchor reconfiguration. If a short - key effectivity period is used and the trust anchor configuration has - to be revisited on a regular basis, the odds that the configuration - tends to be forgotten is smaller. The trade-off is against a system - that is so dynamic that administrators of the validating clients will - not be able to follow the modifications. - - Key effectivity periods can be made very short, as in a few minutes. - But when replacing keys one has to take the considerations from - Section 4.1 and Section 4.2 into account. - - - - -Kolkman & Gieben Informational [Page 8] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -3.4. Key Algorithm - - There are currently three different types of algorithms that can be - used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The - latter is fairly new and has yet to be standardized for usage in - DNSSEC. - - RSA has been developed in an open and transparent manner. As the - patent on RSA expired in 2000, its use is now also free. - - DSA has been developed by the National Institute of Standards and - Technology (NIST). The creation of signatures takes roughly the same - time as with RSA, but is 10 to 40 times as slow for verification - [17]. - - We suggest the use of RSA/SHA-1 as the preferred algorithm for the - key. The current known attacks on RSA can be defeated by making your - key longer. As the MD5 hashing algorithm is showing cracks, we - recommend the usage of SHA-1. - - At the time of publication, it is known that the SHA-1 hash has - cryptanalysis issues. There is work in progress on addressing these - issues. We recommend the use of public key algorithms based on - hashes stronger than SHA-1 (e.g., SHA-256), as soon as these - algorithms are available in protocol specifications (see [19] and - [20]) and implementations. - -3.5. Key Sizes - - When choosing key sizes, zone administrators will need to take into - account how long a key will be used, how much data will be signed - during the key publication period (see Section 8.10 of [17]), and, - optionally, how large the key size of the parent is. As the chain of - trust really is "a chain", there is not much sense in making one of - the keys in the chain several times larger then the others. As - always, it's the weakest link that defines the strength of the entire - chain. Also see Section 3.1.1 for a discussion of how keys serving - different roles (ZSK vs. KSK) may need different key sizes. - - Generating a key of the correct size is a difficult problem; RFC 3766 - [13] tries to deal with that problem. The first part of the - selection procedure in Section 1 of the RFC states: - - 1. Determine the attack resistance necessary to satisfy the - security requirements of the application. Do this by - estimating the minimum number of computer operations that the - attacker will be forced to do in order to compromise the - - - - -Kolkman & Gieben Informational [Page 9] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - security of the system and then take the logarithm base two of - that number. Call that logarithm value "n". - - A 1996 report recommended 90 bits as a good all-around choice - for system security. The 90 bit number should be increased by - about 2/3 bit/year, or about 96 bits in 2005. - - [13] goes on to explain how this number "n" can be used to calculate - the key sizes in public key cryptography. This culminated in the - table given below (slightly modified for our purpose): - - +-------------+-----------+--------------+ - | System | | | - | requirement | Symmetric | RSA or DSA | - | for attack | key size | modulus size | - | resistance | (bits) | (bits) | - | (bits) | | | - +-------------+-----------+--------------+ - | 70 | 70 | 947 | - | 80 | 80 | 1228 | - | 90 | 90 | 1553 | - | 100 | 100 | 1926 | - | 150 | 150 | 4575 | - | 200 | 200 | 8719 | - | 250 | 250 | 14596 | - +-------------+-----------+--------------+ - - The key sizes given are rather large. This is because these keys are - resilient against a trillionaire attacker. Assuming this rich - attacker will not attack your key and that the key is rolled over - once a year, we come to the following recommendations about KSK - sizes: 1024 bits for low-value domains, 1300 bits for medium-value - domains, and 2048 bits for high-value domains. - - Whether a domain is of low, medium, or high value depends solely on - the views of the zone owner. One could, for instance, view leaf - nodes in the DNS as of low value, and top-level domains (TLDs) or the - root zone of high value. The suggested key sizes should be safe for - the next 5 years. - - As ZSKs can be rolled over more easily (and thus more often), the key - sizes can be made smaller. But as said in the introduction of this - paragraph, making the ZSKs' key sizes too small (in relation to the - KSKs' sizes) doesn't make much sense. Try to limit the difference in - size to about 100 bits. - - - - - - -Kolkman & Gieben Informational [Page 10] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - Note that nobody can see into the future and that these key sizes are - only provided here as a guide. Further information can be found in - [16] and Section 7.5 of [17]. It should be noted though that [16] is - already considered overly optimistic about what key sizes are - considered safe. - - One final note concerning key sizes. Larger keys will increase the - sizes of the RRSIG and DNSKEY records and will therefore increase the - chance of DNS UDP packet overflow. Also, the time it takes to - validate and create RRSIGs increases with larger keys, so don't - needlessly double your key sizes. - -3.6. Private Key Storage - - It is recommended that, where possible, zone private keys and the - zone file master copy that is to be signed be kept and used in off- - line, non-network-connected, physically secure machines only. - Periodically, an application can be run to add authentication to a - zone by adding RRSIG and NSEC RRs. Then the augmented file can be - transferred. - - When relying on dynamic update to manage a signed zone [10], be aware - that at least one private key of the zone will have to reside on the - master server. This key is only as secure as the amount of exposure - the server receives to unknown clients and the security of the host. - Although not mandatory, one could administer the DNS in the following - way. The master that processes the dynamic updates is unavailable - from generic hosts on the Internet, it is not listed in the NS RR - set, although its name appears in the SOA RRs MNAME field. The - nameservers in the NS RRSet are able to receive zone updates through - NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This - approach is known as the "hidden master" setup. - - The ideal situation is to have a one-way information flow to the - network to avoid the possibility of tampering from the network. - Keeping the zone master file on-line on the network and simply - cycling it through an off-line signer does not do this. The on-line - version could still be tampered with if the host it resides on is - compromised. For maximum security, the master copy of the zone file - should be off-net and should not be updated based on an unsecured - network mediated communication. - - In general, keeping a zone file off-line will not be practical and - the machines on which zone files are maintained will be connected to - a network. Operators are advised to take security measures to shield - unauthorized access to the master copy. - - - - - -Kolkman & Gieben Informational [Page 11] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - For dynamically updated secured zones [10], both the master copy and - the private key that is used to update signatures on updated RRs will - need to be on-line. - -4. Signature Generation, Key Rollover, and Related Policies - -4.1. Time in DNSSEC - - Without DNSSEC, all times in the DNS are relative. The SOA fields - REFRESH, RETRY, and EXPIRATION are timers used to determine the time - elapsed after a slave server synchronized with a master server. The - Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] - are used to determine how long a forwarder should cache data after it - has been fetched from an authoritative server. By using a signature - validity period, DNSSEC introduces the notion of an absolute time in - the DNS. Signatures in DNSSEC have an expiration date after which - the signature is marked as invalid and the signed data is to be - considered Bogus. - -4.1.1. Time Considerations - - Because of the expiration of signatures, one should consider the - following: - - o We suggest the Maximum Zone TTL of your zone data to be a fraction - of your signature validity period. - - If the TTL would be of similar order as the signature validity - period, then all RRSets fetched during the validity period - would be cached until the signature expiration time. Section - 7.1 of [4] suggests that "the resolver may use the time - remaining before expiration of the signature validity period of - a signed RRSet as an upper bound for the TTL". As a result, - query load on authoritative servers would peak at signature - expiration time, as this is also the time at which records - simultaneously expire from caches. - - To avoid query load peaks, we suggest the TTL on all the RRs in - your zone to be at least a few times smaller than your - signature validity period. - - o We suggest the signature publication period to end at least one - Maximum Zone TTL duration before the end of the signature validity - period. - - - - - - - -Kolkman & Gieben Informational [Page 12] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - Re-signing a zone shortly before the end of the signature - validity period may cause simultaneous expiration of data from - caches. This in turn may lead to peaks in the load on - authoritative servers. - - o We suggest the Minimum Zone TTL to be long enough to both fetch - and verify all the RRs in the trust chain. In workshop - environments, it has been demonstrated [18] that a low TTL (under - 5 to 10 minutes) caused disruptions because of the following two - problems: - - 1. During validation, some data may expire before the - validation is complete. The validator should be able to - keep all data until it is completed. This applies to all - RRs needed to complete the chain of trust: DSes, DNSKEYs, - RRSIGs, and the final answers, i.e., the RRSet that is - returned for the initial query. - - 2. Frequent verification causes load on recursive nameservers. - Data at delegation points, DSes, DNSKEYs, and RRSIGs - benefit from caching. The TTL on those should be - relatively long. - - o Slave servers will need to be able to fetch newly signed zones - well before the RRSIGs in the zone served by the slave server pass - their signature expiration time. - - When a slave server is out of sync with its master and data in - a zone is signed by expired signatures, it may be better for - the slave server not to give out any answer. - - Normally, a slave server that is not able to contact a master - server for an extended period will expire a zone. When that - happens, the server will respond differently to queries for - that zone. Some servers issue SERVFAIL, whereas others turn - off the 'AA' bit in the answers. The time of expiration is set - in the SOA record and is relative to the last successful - refresh between the master and the slave servers. There exists - no coupling between the signature expiration of RRSIGs in the - zone and the expire parameter in the SOA. - - If the server serves a DNSSEC zone, then it may well happen - that the signatures expire well before the SOA expiration timer - counts down to zero. It is not possible to completely prevent - this from happening by tweaking the SOA parameters. However, - the effects can be minimized where the SOA expiration time is - equal to or shorter than the signature validity period. The - consequence of an authoritative server not being able to update - - - -Kolkman & Gieben Informational [Page 13] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - a zone, whilst that zone includes expired signatures, is that - non-secure resolvers will continue to be able to resolve data - served by the particular slave servers while security-aware - resolvers will experience problems because of answers being - marked as Bogus. - - We suggest the SOA expiration timer being approximately one - third or one fourth of the signature validity period. It will - allow problems with transfers from the master server to be - noticed before the actual signature times out. We also suggest - that operators of nameservers that supply secondary services - develop 'watch dogs' to spot upcoming signature expirations in - zones they slave, and take appropriate action. - - When determining the value for the expiration parameter one has - to take the following into account: What are the chances that - all my secondaries expire the zone? How quickly can I reach an - administrator of secondary servers to load a valid zone? These - questions are not DNSSEC specific but may influence the choice - of your signature validity intervals. - -4.2. Key Rollovers - - A DNSSEC key cannot be used forever (see Section 3.3). So key - rollovers -- or supercessions, as they are sometimes called -- are a - fact of life when using DNSSEC. Zone administrators who are in the - process of rolling their keys have to take into account that data - published in previous versions of their zone still lives in caches. - When deploying DNSSEC, this becomes an important consideration; - ignoring data that may be in caches may lead to loss of service for - clients. - - The most pressing example of this occurs when zone material signed - with an old key is being validated by a resolver that does not have - the old zone key cached. If the old key is no longer present in the - current zone, this validation fails, marking the data "Bogus". - Alternatively, an attempt could be made to validate data that is - signed with a new key against an old key that lives in a local cache, - also resulting in data being marked "Bogus". - -4.2.1. Zone Signing Key Rollovers - - For "Zone Signing Key rollovers", there are two ways to make sure - that during the rollover data still cached can be verified with the - new key sets or newly generated signatures can be verified with the - keys still in caches. One schema, described in Section 4.2.1.2, uses - - - - - -Kolkman & Gieben Informational [Page 14] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - double signatures; the other uses key pre-publication (Section - 4.2.1.1). The pros, cons, and recommendations are described in - Section 4.2.1.3. - -4.2.1.1. Pre-Publish Key Rollover - - This section shows how to perform a ZSK rollover without the need to - sign all the data in a zone twice -- the "pre-publish key rollover". - This method has advantages in the case of a key compromise. If the - old key is compromised, the new key has already been distributed in - the DNS. The zone administrator is then able to quickly switch to - the new key and remove the compromised key from the zone. Another - major advantage is that the zone size does not double, as is the case - with the double signature ZSK rollover. A small "how-to" for this - kind of rollover can be found in Appendix B. - - Pre-publish key rollover involves four stages as follows: - - ---------------------------------------------------------------- - initial new DNSKEY new RRSIGs DNSKEY removal - ---------------------------------------------------------------- - SOA0 SOA1 SOA2 SOA3 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) - - DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - ---------------------------------------------------------------- - - Pre-Publish Key Rollover - - initial: Initial version of the zone: DNSKEY 1 is the Key Signing - Key. DNSKEY 10 is used to sign all the data of the zone, the Zone - Signing Key. - - new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no - signatures are generated with this key yet, but this does not - secure against brute force attacks on the public key. The minimum - duration of this pre-roll phase is the time it takes for the data - to propagate to the authoritative servers plus TTL value of the - key set. - - new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is - used to sign the data in the zone exclusively (i.e., all the - signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 - remains published in the key set. This way data that was loaded - - - -Kolkman & Gieben Informational [Page 15] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - into caches from version 1 of the zone can still be verified with - key sets fetched from version 2 of the zone. The minimum time - that the key set including DNSKEY 10 is to be published is the - time that it takes for zone data from the previous version of the - zone to expire from old caches, i.e., the time it takes for this - zone to propagate to all authoritative servers plus the Maximum - Zone TTL value of any of the data in the previous version of the - zone. - - DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now - only containing DNSKEY 1 and DNSKEY 11, is re-signed with the - DNSKEY 1. - - The above scheme can be simplified by always publishing the "future" - key immediately after the rollover. The scheme would look as follows - (we show two rollovers); the future key is introduced in "new DNSKEY" - as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY - (II)": - - ---------------------------------------------------------------- - initial new RRSIGs new DNSKEY - ---------------------------------------------------------------- - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 DNSKEY12 - RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - ---------------------------------------------------------------- - - ---------------------------------------------------------------- - new RRSIGs (II) new DNSKEY (II) - ---------------------------------------------------------------- - SOA3 SOA4 - RRSIG12(SOA3) RRSIG12(SOA4) - - DNSKEY1 DNSKEY1 - DNSKEY11 DNSKEY12 - DNSKEY12 DNSKEY13 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG12(DNSKEY) RRSIG12(DNSKEY) - ---------------------------------------------------------------- - - Pre-Publish Key Rollover, Showing Two Rollovers - - - - - -Kolkman & Gieben Informational [Page 16] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - Note that the key introduced in the "new DNSKEY" phase is not used - for production yet; the private key can thus be stored in a - physically secure manner and does not need to be 'fetched' every time - a zone needs to be signed. - -4.2.1.2. Double Signature Zone Signing Key Rollover - - This section shows how to perform a ZSK key rollover using the double - zone data signature scheme, aptly named "double signature rollover". - - During the "new DNSKEY" stage the new version of the zone file will - need to propagate to all authoritative servers and the data that - exists in (distant) caches will need to expire, requiring at least - the Maximum Zone TTL. - - Double signature ZSK rollover involves three stages as follows: - - ---------------------------------------------------------------- - initial new DNSKEY DNSKEY removal - ---------------------------------------------------------------- - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) - RRSIG11(SOA1) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) - RRSIG11(DNSKEY) - ---------------------------------------------------------------- - - Double Signature Zone Signing Key Rollover - - initial: Initial Version of the zone: DNSKEY 1 is the Key Signing - Key. DNSKEY 10 is used to sign all the data of the zone, the Zone - Signing Key. - - new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is - introduced into the key set and all the data in the zone is signed - with DNSKEY 10 and DNSKEY 11. The rollover period will need to - continue until all data from version 0 of the zone has expired - from remote caches. This will take at least the Maximum Zone TTL - of version 0 of the zone. - - DNSKEY removal: DNSKEY 10 is removed from the zone. All the - signatures from DNSKEY 10 are removed from the zone. The key set, - now only containing DNSKEY 11, is re-signed with DNSKEY 1. - - - -Kolkman & Gieben Informational [Page 17] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - At every instance, RRSIGs from the previous version of the zone can - be verified with the DNSKEY RRSet from the current version and the - other way around. The data from the current version can be verified - with the data from the previous version of the zone. The duration of - the "new DNSKEY" phase and the period between rollovers should be at - least the Maximum Zone TTL. - - Making sure that the "new DNSKEY" phase lasts until the signature - expiration time of the data in initial version of the zone is - recommended. This way all caches are cleared of the old signatures. - However, this duration could be considerably longer than the Maximum - Zone TTL, making the rollover a lengthy procedure. - - Note that in this example we assumed that the zone was not modified - during the rollover. New data can be introduced in the zone as long - as it is signed with both keys. - -4.2.1.3. Pros and Cons of the Schemes - - Pre-publish key rollover: This rollover does not involve signing the - zone data twice. Instead, before the actual rollover, the new key - is published in the key set and thus is available for - cryptanalysis attacks. A small disadvantage is that this process - requires four steps. Also the pre-publish scheme involves more - parental work when used for KSK rollovers as explained in Section - 4.2.3. - - Double signature ZSK rollover: The drawback of this signing scheme is - that during the rollover the number of signatures in your zone - doubles; this may be prohibitive if you have very big zones. An - advantage is that it only requires three steps. - -4.2.2. Key Signing Key Rollovers - - For the rollover of a Key Signing Key, the same considerations as for - the rollover of a Zone Signing Key apply. However, we can use a - double signature scheme to guarantee that old data (only the apex key - set) in caches can be verified with a new key set and vice versa. - Since only the key set is signed with a KSK, zone size considerations - do not apply. - - - - - - - - - - - -Kolkman & Gieben Informational [Page 18] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - -------------------------------------------------------------------- - initial new DNSKEY DS change DNSKEY removal - -------------------------------------------------------------------- - Parent: - SOA0 --------> SOA1 --------> - RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> - DS1 --------> DS2 --------> - RRSIGpar(DS) --------> RRSIGpar(DS) --------> - - - Child: - SOA0 SOA1 --------> SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) - --------> - DNSKEY1 DNSKEY1 --------> DNSKEY2 - DNSKEY2 --------> - DNSKEY10 DNSKEY10 --------> DNSKEY10 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) - RRSIG2 (DNSKEY) --------> - RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) - -------------------------------------------------------------------- - - Stages of Deployment for a Double Signature Key Signing Key Rollover - - initial: Initial version of the zone. The parental DS points to - DNSKEY1. Before the rollover starts, the child will have to - verify what the TTL is of the DS RR that points to DNSKEY1 -- it - is needed during the rollover and we refer to the value as TTL_DS. - - new DNSKEY: During the "new DNSKEY" phase, the zone administrator - generates a second KSK, DNSKEY2. The key is provided to the - parent, and the child will have to wait until a new DS RR has been - generated that points to DNSKEY2. After that DS RR has been - published on all servers authoritative for the parent's zone, the - zone administrator has to wait at least TTL_DS to make sure that - the old DS RR has expired from caches. - - DS change: The parent replaces DS1 with DS2. - - DNSKEY removal: DNSKEY1 has been removed. - - The scenario above puts the responsibility for maintaining a valid - chain of trust with the child. It also is based on the premise that - the parent only has one DS RR (per algorithm) per zone. An - alternative mechanism has been considered. Using an established - trust relation, the interaction can be performed in-band, and the - removal of the keys by the child can possibly be signaled by the - parent. In this mechanism, there are periods where there are two DS - - - -Kolkman & Gieben Informational [Page 19] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - RRs at the parent. Since at the moment of writing the protocol for - this interaction has not been developed, further discussion is out of - scope for this document. - -4.2.3. Difference Between ZSK and KSK Rollovers - - Note that KSK rollovers and ZSK rollovers are different in the sense - that a KSK rollover requires interaction with the parent (and - possibly replacing of trust anchors) and the ensuing delay while - waiting for it. - - A zone key rollover can be handled in two different ways: pre-publish - (Section 4.2.1.1) and double signature (Section 4.2.1.2). - - As the KSK is used to validate the key set and because the KSK is not - changed during a ZSK rollover, a cache is able to validate the new - key set of the zone. The pre-publish method would also work for a - KSK rollover. The records that are to be pre-published are the - parental DS RRs. The pre-publish method has some drawbacks for KSKs. - We first describe the rollover scheme and then indicate these - drawbacks. - - -------------------------------------------------------------------- - initial new DS new DNSKEY DS/DNSKEY removal - -------------------------------------------------------------------- - Parent: - SOA0 SOA1 --------> SOA2 - RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) - DS1 DS1 --------> DS2 - DS2 --------> - RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) - - - Child: - SOA0 --------> SOA1 SOA1 - RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) - --------> - DNSKEY1 --------> DNSKEY2 DNSKEY2 - --------> - DNSKEY10 --------> DNSKEY10 DNSKEY10 - RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) - RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) - -------------------------------------------------------------------- - - Stages of Deployment for a Pre-Publish Key Signing Key Rollover - - - - - - -Kolkman & Gieben Informational [Page 20] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - When the child zone wants to roll, it notifies the parent during the - "new DS" phase and submits the new key (or the corresponding DS) to - the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 - and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), - which can take place as soon as the new DS set propagated through the - DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that - ("DS/DNSKEY removal" phase), it can notify the parent that the old DS - record can be deleted. - - The drawbacks of this scheme are that during the "new DS" phase the - parent cannot verify the match between the DS2 RR and DNSKEY2 using - the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a - "security lame" key (see Section 4.4.3). Finally, the child-parent - interaction consists of two steps. The "double signature" method - only needs one interaction. - -4.2.4. Automated Key Rollovers - - As keys must be renewed periodically, there is some motivation to - automate the rollover process. Consider the following: - - o ZSK rollovers are easy to automate as only the child zone is - involved. - - o A KSK rollover needs interaction between parent and child. Data - exchange is needed to provide the new keys to the parent; - consequently, this data must be authenticated and integrity must - be guaranteed in order to avoid attacks on the rollover. - -4.3. 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. - - When the private material of one of your keys is compromised it can - be used for as long as a valid trust chain exists. A trust chain - remains intact for - - o as long as a signature over the compromised key in the trust chain - is valid, - - o as long as a parental DS RR (and signature) points to the - compromised key, - - o as long as the key is anchored in a resolver and is used as a - starting point for validation (this is generally the hardest to - update). - - - -Kolkman & Gieben Informational [Page 21] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - While a trust chain to your compromised key exists, your namespace is - vulnerable to abuse by anyone who has obtained illegitimate - possession of the key. 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 - trust chain to the compromised key, data in caches signed with this - key cannot be validated. However, if the zone administrator chooses - to take the path of a regular rollover, the malicious key holder can - spoof data so that it appears to be valid. - -4.3.1. KSK Compromise - - A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable - as long as the compromised KSK is configured as trust anchor or a - parental DS points to it. - - A compromised KSK can be used to sign the key set of an attacker's - zone. That zone could be used to poison the DNS. - - Therefore, when the KSK has been compromised, the trust anchor or the - parental DS should be replaced as soon as possible. It is local - policy whether to break the trust chain during the emergency - rollover. The trust chain would be broken when the compromised KSK - is removed from the child's zone while the parent still has a DS - pointing to the compromised KSK (the assumption is that there is only - one DS at the parent. If there are multiple DSes this does not apply - -- however the chain of trust of this particular key is broken). - - Note that an attacker's zone still uses the compromised KSK and the - presence of a parental DS would cause the data in this zone to appear - as valid. Removing the compromised key would cause the attacker's - zone to appear as valid and the child's zone as Bogus. Therefore, we - advise not to remove the KSK before the parent has a DS to a new KSK - in place. - -4.3.1.1. Keeping the Chain of Trust Intact - - If we follow this advice, the timing of the replacement of the KSK is - somewhat critical. The goal is to remove the compromised KSK as soon - as the new DS RR is available at the parent. And also make sure that - the signature made with a new KSK over the key set with the - compromised KSK in it expires just after the new DS appears at the - parent, thus removing the old cruft in one swoop. - - The procedure is as follows: - - 1. Introduce a new KSK into the key set, keep the compromised KSK in - the key set. - - - -Kolkman & Gieben Informational [Page 22] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - 2. Sign the key set, with a short validity period. The validity - period should expire shortly after the DS is expected to appear - in the parent and the old DSes have expired from caches. - - 3. Upload the DS for this new key to the parent. - - 4. Follow the procedure of the regular KSK rollover: Wait for the DS - to appear in the authoritative servers and then wait as long as - the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet - and modify/extend the expiration time. - - 5. Remove the compromised DNSKEY RR from the zone and re-sign the - key set using your "normal" validity interval. - - An additional danger of a key compromise is that the compromised key - could be used to facilitate a legitimate DNSKEY/DS rollover and/or - nameserver changes at the parent. When that happens, the domain may - be in dispute. An authenticated out-of-band and secure notify - mechanism to contact a parent is needed in this case. - - Note that this is only a problem when the DNSKEY and or DS records - are used for authentication at the parent. - -4.3.1.2. Breaking the Chain of Trust - - There are two methods to break the chain of trust. The first method - causes the child zone to appear 'Bogus' to validating resolvers. The - other causes the child zone to appear 'insecure'. These are - described below. - - In the method that causes the child zone to appear 'Bogus' to - validating resolvers, the child zone replaces the current KSK with a - new one and re-signs the key set. Next it sends the DS of the new - key to the parent. Only after the parent has placed the new DS in - the zone is the child's chain of trust repaired. - - An alternative method of breaking the chain of trust is by removing - the DS RRs from the parent zone altogether. As a result, the child - zone would become insecure. - -4.3.2. ZSK Compromise - - Primarily because there is no parental interaction required when a - ZSK is compromised, the situation is less severe than with a KSK - compromise. The zone must still be re-signed 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. However, one has to take into account that just as - - - -Kolkman & Gieben Informational [Page 23] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - with a normal rollover the immediate disappearance of the old - compromised key may lead to verification problems. Also note that as - long as the RRSIG over the compromised ZSK is not expired the zone - may be still at risk. - -4.3.3. Compromises of Keys Anchored in Resolvers - - A key can also be pre-configured in resolvers. For instance, if - DNSSEC is successfully deployed the root key may be pre-configured in - most security aware resolvers. - - If trust-anchor keys are compromised, the resolvers using these keys - 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. - - End-users faced with the task of updating an anchored key should - always validate the new key. New keys should be authenticated out- - of-band, for example, through the use of an announcement website that - is secured using secure sockets (TLS) [21]. - -4.4. Parental Policies - -4.4.1. Initial Key Exchanges and Parental Policies Considerations - - The initial key exchange is always subject to the policies set by the - parent. 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. That is, there is no implicit - need in DNSSEC to make the authentication process stronger than it - was in DNS. - - Using the DNS itself as the source for the actual DNSKEY material, - with an out-of-band check on the validity of the DNSKEY, has the - benefit that it reduces the chances of user error. A DNSKEY query - tool can make use of the SEP bit [3] to select the proper key from a - DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is - sent. It can validate the self-signature over a key; thereby - verifying the ownership of the private key material. Fetching the - DNSKEY from the DNS ensures that the chain of trust remains intact - once the parent publishes the DS RR indicating the child is secure. - - Note: the out-of-band verification is still needed when the key - material is fetched via the DNS. The parent can never be sure - whether or not the DNSKEY RRs have been spoofed. - - - -Kolkman & Gieben Informational [Page 24] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -4.4.2. Storing Keys or Hashes? - - When designing a registry system one should consider which of the - DNSKEYs and/or the corresponding DSes to store. Since a child zone - might wish to have a DS published using a message digest algorithm - not yet understood by the registry, the registry can't count on being - able to generate the DS record from a raw DNSKEY. Thus, we recommend - that registry systems at least support storing DS records. - - It may also be useful to store DNSKEYs, since having them may help - during troubleshooting and, as long as the child's chosen message - digest is supported, the overhead of generating DS records from them - is minimal. Having an out-of-band mechanism, such as a registry - directory (e.g., Whois), to find out which keys are used to generate - DS Resource Records for specific owners and/or zones may also help - with troubleshooting. - - The storage considerations also relate to the design of the customer - interface and the method by which data is transferred between - registrant and registry; Will the child zone administrator be able to - upload DS RRs with unknown hash algorithms or does the interface only - allow DNSKEYs? In the registry-registrar model, one can use the - DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], - which allows transfer of DS RRs and optionally DNSKEY RRs. - -4.4.3. Security Lameness - - Security lameness is defined as what happens when a parent has a DS - RR pointing to a non-existing DNSKEY RR. When this happens, the - child's zone may be marked "Bogus" by verifying DNS clients. - - As part of a comprehensive delegation check, the parent could, at key - exchange time, verify that the child's key is actually configured in - the DNS. However, if a parent does not understand the hashing - algorithm used by child, the parental checks are limited to only - comparing the key id. - - Child zones should be very careful in removing DNSKEY material, - specifically SEP keys, for which a DS RR exists. - - Once a zone is "security lame", a fix (e.g., removing a DS RR) will - take time to propagate through the DNS. - - - - - - - - - -Kolkman & Gieben Informational [Page 25] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -4.4.4. DS Signature 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(s). A signature validity period that is too short introduces the - possibility that a zone is marked "Bogus" 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 operator - unavailability during weekends shows the need for DS signature - validity periods longer than 2 days. We recommend an absolute - minimum for a DS signature validity period of a few days. - - The maximum signature validity period of the DS record depends on how - long child zones are willing to be vulnerable after a key compromise. - On the other hand, shortening the DS signature validity interval - increases the operational risk for the parent. Therefore, the parent - may have policy to use a signature validity interval that is - considerably longer than the child would hope for. - - A compromise between the operational constraints of the parent and - minimizing damage for the child may result in a DS signature validity - period somewhere between a week and months. - - In addition to the signature validity period, which sets a lower - bound on the number of times the zone owner will need to sign the - zone data and which sets an upper bound to the time a child is - vulnerable after key compromise, there is the TTL value on the DS - RRs. Shortening the TTL means that the authoritative servers will - see more queries. But on the other hand, a short TTL lowers the - persistence of DS RRSets in caches thereby increasing the speed with - which updated DS RRSets propagate through the DNS. - -5. Security Considerations - - DNSSEC adds data integrity to the DNS. This document tries to assess - the operational considerations to maintain a stable and secure DNSSEC - service. Not taking into account the 'data propagation' properties - in the DNS will cause validation failures and may make secured zones - unavailable to security-aware resolvers. - -6. Acknowledgments - - Most of the ideas in this document were the result of collective - efforts during workshops, discussions, and tryouts. - - At the risk of forgetting individuals who were the original - contributors of the ideas, we would like to acknowledge people who - - - -Kolkman & Gieben Informational [Page 26] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - were actively involved in the compilation of this document. In - random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael - Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette - Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger - Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch. - - Some material in this document has been copied from RFC 2541 [12]. - - Mike StJohns designed the key exchange between parent and child - mentioned in the last paragraph of Section 4.2.2 - - Section 4.2.4 was supplied by G. Guette and O. Courtay. - - Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of - the spelling and style issues. - - Kolkman and Gieben take the blame for introducing all miscakes (sic). - - While working on this document, Kolkman was employed by the RIPE NCC - and Gieben was employed by NLnet Labs. - -7. References - -7.1. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System - KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) - Flag", RFC 3757, May 2004. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, March - 2005. - - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", RFC - 4035, March 2005. - - - - - -Kolkman & Gieben Informational [Page 27] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -7.2. Informative References - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August - 1996. - - [9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", RFC 1996, August 1996. - - [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [12] Eastlake, D., "DNS Security Operational Considerations", RFC - 2541, March 1999. - - [13] Orman, H. and P. Hoffman, "Determining Strengths For Public - Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, - April 2004. - - [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - - [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions - Mapping for the Extensible Provisioning Protocol (EPP)", RFC - 4310, December 2005. - - [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key - Sizes", The Journal of Cryptology 14 (255-293), 2001. - - [17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and - Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN - (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., - 1996. - - [18] Rose, S., "NIST DNSSEC workshop notes", June 2001. - - [19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource - Records in DNSSEC", Work in Progress, January 2006. - - [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) - Resource Records (RRs)", RFC 4509, May 2006. - - - - - -Kolkman & Gieben Informational [Page 28] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - [21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and - T. Wright, "Transport Layer Security (TLS) Extensions", RFC - 4366, April 2006. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Informational [Page 29] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -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 have given a more elaborate - explanation of the meaning. Note that these explanations should not - be seen as authoritative. - - Anchored key: A DNSKEY configured in resolvers around the globe. - This key is hard to update, hence the term anchored. - - Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked - "Bogus" when a signature of an RRSet does not validate against a - DNSKEY. - - Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used - exclusively for signing the apex key set. The fact that a key is - a KSK is only relevant to the signing tool. - - Key size: The term 'key size' can be substituted by 'modulus size' - throughout the document. It is mathematically more correct to use - modulus size, but as this is a document directed at operators we - feel more at ease with the term key size. - - Private and public keys: DNSSEC secures the DNS through the use of - public key cryptography. Public key cryptography is based on the - existence of two (mathematically related) keys, a public key and a - private key. The public keys are published in the DNS by use of - the DNSKEY Resource Record (DNSKEY RR). Private keys should - remain private. - - Key rollover: A key rollover (also called key supercession in some - environments) is the act of replacing one key pair with another at - the end of a key effectivity period. - - Secure Entry Point (SEP) key: A KSK that has a parental DS record - pointing to it or is configured as a trust anchor. Although not - required by the protocol, we recommend that the SEP flag [3] is - set on these keys. - - Self-signature: This only applies to signatures over DNSKEYs; a - signature made with DNSKEY x, over DNSKEY x is called a self- - signature. Note: without further information, self-signatures - convey no trust. They are useful to check the authenticity of the - DNSKEY, i.e., they can be used as a hash. - - - - - - -Kolkman & Gieben Informational [Page 30] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - Singing the zone file: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. - - 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. - - Zone Signing Key (ZSK): 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. - - Zone administrator: The 'role' that is responsible for signing a zone - and publishing it on the primary authoritative server. - -Appendix B. Zone Signing Key Rollover How-To - - Using the pre-published signature scheme and the most conservative - method to assure oneself that data does not live in caches, here - follows the "how-to". - - Step 0: The preparation: Create two keys and publish both in your key - set. Mark one of the keys "active" and the other "published". - Use the "active" key for signing your zone data. Store the - private part of the "published" key, preferably off-line. The - protocol does not provide for attributes to mark a key as active - or published. This is something you have to do on your own, - through the use of a notebook or key management tool. - - Step 1: Determine expiration: At the beginning of the rollover make a - note of the highest expiration time of signatures in your zone - file created with the current key marked as active. Wait until - the expiration time marked in Step 1 has passed. - - Step 2: Then start using the key that was marked "published" to sign - your data (i.e., mark it "active"). Stop using the key that was - marked "active"; mark it "rolled". - - Step 3: It is safe to engage in a new rollover (Step 1) after at - least one signature validity period. - - - - - - - - - - -Kolkman & Gieben Informational [Page 31] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -Appendix C. Typographic Conventions - - The following typographic conventions are used in this document: - - Key notation: A key is denoted by DNSKEYx, where x is a number or an - identifier, 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.0.2.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 abbreviated to - just "A". - - Signature notation: Signatures are denoted as RRSIGx(RRSet), which - means that RRSet is signed with DNSKEYx. - - Zone representation: Using the above notation we have simplified the - representation of a signed zone by leaving out all unnecessary - details such as the names and by representing all data by "SOAx" - - SOA representation: SOAs are represented as SOAx, where x is the - serial number. - - Using this notation the following signed zone: - - example.net. 86400 IN SOA ns.example.net. bert.example.net. ( - 2006022100 ; serial - 86400 ; refresh ( 24 hours) - 7200 ; retry ( 2 hours) - 3600000 ; expire (1000 hours) - 28800 ) ; minimum ( 8 hours) - 86400 RRSIG SOA 5 2 86400 20130522213204 ( - 20130422213204 14 example.net. - cmL62SI6iAX46xGNQAdQ... ) - 86400 NS a.iana-servers.net. - 86400 NS b.iana-servers.net. - 86400 RRSIG NS 5 2 86400 20130507213204 ( - 20130407213204 14 example.net. - SO5epiJei19AjXoUpFnQ ... ) - 86400 DNSKEY 256 3 5 ( - EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 - 86400 DNSKEY 257 3 5 ( - gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 - 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( - 20130422213204 14 example.net. - J4zCe8QX4tXVGjV4e1r9... ) - - - - -Kolkman & Gieben Informational [Page 32] - -RFC 4641 DNSSEC Operational Practices September 2006 - - - 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( - 20130422213204 15 example.net. - keVDCOpsSeDReyV6O... ) - 86400 RRSIG NSEC 5 2 86400 20130507213204 ( - 20130407213204 14 example.net. - obj3HEp1GjnmhRjX... ) - a.example.net. 86400 IN TXT "A label" - 86400 RRSIG TXT 5 3 86400 20130507213204 ( - 20130407213204 14 example.net. - IkDMlRdYLmXH7QJnuF3v... ) - 86400 NSEC b.example.com. TXT RRSIG NSEC - 86400 RRSIG NSEC 5 3 86400 20130507213204 ( - 20130407213204 14 example.net. - bZMjoZ3bHjnEz0nIsPMM... ) - ... - - is reduced to the following representation: - - SOA2006022100 - RRSIG14(SOA2006022100) - DNSKEY14 - DNSKEY15 - - RRSIG14(KEY) - RRSIG15(KEY) - - The rest of the zone data has the same signature as the SOA record, - i.e., an RRSIG created with DNSKEY 14. - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Informational [Page 33] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -Authors' Addresses - - Olaf M. Kolkman - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - EMail: olaf@nlnetlabs.nl - URI: http://www.nlnetlabs.nl - - - R. (Miek) Gieben - - EMail: miek@miek.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Informational [Page 34] - -RFC 4641 DNSSEC Operational Practices September 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights 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; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Kolkman & Gieben Informational [Page 35] - |
