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).
AbstractThis 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.
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 18.104.22.168. Pre-Publish Key Rollover ..................15 22.214.171.124. Double Signature Zone Signing Key Rollover ..................................17 126.96.36.199. 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 188.8.131.52. Keeping the Chain of Trust Intact .........22 184.108.40.206. 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
RFC 1034  and RFC 1035 ) and want to deploy DNSSEC. See RFC 4033  for an introduction to DNSSEC, RFC 4034  for the newly introduced Resource Records (RRs), and RFC 4035  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  language does not apply. This document obsoletes RFC 2541  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.
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. 11] for more information.
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  and incremental transfer (IXFR) . It increases when full zone transfers (AXFR) are used in combination with NOTIFY. It increases even more if you rely on full zone transfers based on only the SOA timing parameters for refresh. For the verifying clients, it is important that data from secured zones can be used to build chains of trust regardless of whether the data came directly from an authoritative server, a caching nameserver, or some middle box. Only by carefully using the available timing parameters can a zone administrator ensure that the data necessary for verification can be obtained. The responsibility for maintaining the chain of trust is shared by administrators of secured zones in the chain of trust. This is most obvious in the case of a 'key compromise' when a trade-off between maintaining a valid chain of trust and replacing the compromised keys as soon as possible must be made. Then zone administrators will have to make a trade-off, between keeping the chain of trust intact -- thereby allowing for attacks with the compromised key -- or deliberately breaking the chain of trust and making secured subdomains invisible to security-aware resolvers. Also see Section 4.3.
3] 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.
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.
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.
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  and ) and implementations. 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  tries to deal with that problem. The first part of the selection procedure in Section 1 of the RFC states: 1. Determine the attack resistance necessary to satisfy the security requirements of the application. Do this by estimating the minimum number of computer operations that the attacker will be forced to do in order to compromise the
security of the system and then take the logarithm base two of that number. Call that logarithm value "n". A 1996 report recommended 90 bits as a good all-around choice for system security. The 90 bit number should be increased by about 2/3 bit/year, or about 96 bits in 2005.  goes on to explain how this number "n" can be used to calculate the key sizes in public key cryptography. This culminated in the table given below (slightly modified for our purpose): +-------------+-----------+--------------+ | System | | | | requirement | Symmetric | RSA or DSA | | for attack | key size | modulus size | | resistance | (bits) | (bits) | | (bits) | | | +-------------+-----------+--------------+ | 70 | 70 | 947 | | 80 | 80 | 1228 | | 90 | 90 | 1553 | | 100 | 100 | 1926 | | 150 | 150 | 4575 | | 200 | 200 | 8719 | | 250 | 250 | 14596 | +-------------+-----------+--------------+ The key sizes given are rather large. This is because these keys are resilient against a trillionaire attacker. Assuming this rich attacker will not attack your key and that the key is rolled over once a year, we come to the following recommendations about KSK sizes: 1024 bits for low-value domains, 1300 bits for medium-value domains, and 2048 bits for high-value domains. Whether a domain is of low, medium, or high value depends solely on the views of the zone owner. One could, for instance, view leaf nodes in the DNS as of low value, and top-level domains (TLDs) or the root zone of high value. The suggested key sizes should be safe for the next 5 years. As ZSKs can be rolled over more easily (and thus more often), the key sizes can be made smaller. But as said in the introduction of this paragraph, making the ZSKs' key sizes too small (in relation to the KSKs' sizes) doesn't make much sense. Try to limit the difference in size to about 100 bits.
Note that nobody can see into the future and that these key sizes are only provided here as a guide. Further information can be found in  and Section 7.5 of . It should be noted though that  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. 10], be aware that at least one private key of the zone will have to reside on the master server. This key is only as secure as the amount of exposure the server receives to unknown clients and the security of the host. Although not mandatory, one could administer the DNS in the following way. The master that processes the dynamic updates is unavailable from generic hosts on the Internet, it is not listed in the NS RR set, although its name appears in the SOA RRs MNAME field. The nameservers in the NS RRSet are able to receive zone updates through NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This approach is known as the "hidden master" setup. The ideal situation is to have a one-way information flow to the network to avoid the possibility of tampering from the network. Keeping the zone master file on-line on the network and simply cycling it through an off-line signer does not do this. The on-line version could still be tampered with if the host it resides on is compromised. For maximum security, the master copy of the zone file should be off-net and should not be updated based on an unsecured network mediated communication. In general, keeping a zone file off-line will not be practical and the machines on which zone files are maintained will be connected to a network. Operators are advised to take security measures to shield unauthorized access to the master copy.
For dynamically updated secured zones , both the master copy and the private key that is used to update signatures on updated RRs will need to be on-line. 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] suggests that "the resolver may use the time remaining before expiration of the signature validity period of a signed RRSet as an upper bound for the TTL". As a result, query load on authoritative servers would peak at signature expiration time, as this is also the time at which records simultaneously expire from caches. To avoid query load peaks, we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. o We suggest the signature publication period to end at least one Maximum Zone TTL duration before the end of the signature validity period.
Re-signing a zone shortly before the end of the signature validity period may cause simultaneous expiration of data from caches. This in turn may lead to peaks in the load on authoritative servers. o We suggest the Minimum Zone TTL to be long enough to both fetch and verify all the RRs in the trust chain. In workshop environments, it has been demonstrated  that a low TTL (under 5 to 10 minutes) caused disruptions because of the following two problems: 1. During validation, some data may expire before the validation is complete. The validator should be able to keep all data until it is completed. This applies to all RRs needed to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the final answers, i.e., the RRSet that is returned for the initial query. 2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit from caching. The TTL on those should be relatively long. o Slave servers will need to be able to fetch newly signed zones well before the RRSIGs in the zone served by the slave server pass their signature expiration time. When a slave server is out of sync with its master and data in a zone is signed by expired signatures, it may be better for the slave server not to give out any answer. Normally, a slave server that is not able to contact a master server for an extended period will expire a zone. When that happens, the server will respond differently to queries for that zone. Some servers issue SERVFAIL, whereas others turn off the 'AA' bit in the answers. The time of expiration is set in the SOA record and is relative to the last successful refresh between the master and the slave servers. There exists no coupling between the signature expiration of RRSIGs in the zone and the expire parameter in the SOA. If the server serves a DNSSEC zone, then it may well happen that the signatures expire well before the SOA expiration timer counts down to zero. It is not possible to completely prevent this from happening by tweaking the SOA parameters. However, the effects can be minimized where the SOA expiration time is equal to or shorter than the signature validity period. The consequence of an authoritative server not being able to update
a zone, whilst that zone includes expired signatures, is that non-secure resolvers will continue to be able to resolve data served by the particular slave servers while security-aware resolvers will experience problems because of answers being marked as Bogus. We suggest the SOA expiration timer being approximately one third or one fourth of the signature validity period. It will allow problems with transfers from the master server to be noticed before the actual signature times out. We also suggest that operators of nameservers that supply secondary services develop 'watch dogs' to spot upcoming signature expirations in zones they slave, and take appropriate action. When determining the value for the expiration parameter one has to take the following into account: What are the chances that all my secondaries expire the zone? How quickly can I reach an administrator of secondary servers to load a valid zone? These questions are not DNSSEC specific but may influence the choice of your signature validity intervals.
double signatures; the other uses key pre-publication (Section 220.127.116.11). The pros, cons, and recommendations are described in Section 18.104.22.168.
into caches from version 1 of the zone can still be verified with key sets fetched from version 2 of the zone. The minimum time that the key set including DNSKEY 10 is to be published is the time that it takes for zone data from the previous version of the zone to expire from old caches, i.e., the time it takes for this zone to propagate to all authoritative servers plus the Maximum Zone TTL value of any of the data in the previous version of the zone. DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the DNSKEY 1. The above scheme can be simplified by always publishing the "future" key immediately after the rollover. The scheme would look as follows (we show two rollovers); the future key is introduced in "new DNSKEY" as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY (II)": ---------------------------------------------------------------- initial new RRSIGs new DNSKEY ---------------------------------------------------------------- SOA0 SOA1 SOA2 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY11 DNSKEY12 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) ---------------------------------------------------------------- ---------------------------------------------------------------- new RRSIGs (II) new DNSKEY (II) ---------------------------------------------------------------- SOA3 SOA4 RRSIG12(SOA3) RRSIG12(SOA4) DNSKEY1 DNSKEY1 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) ---------------------------------------------------------------- Pre-Publish Key Rollover, Showing Two Rollovers
Note that the key introduced in the "new DNSKEY" phase is not used for production yet; the private key can thus be stored in a physically secure manner and does not need to be 'fetched' every time a zone needs to be signed.
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.
-------------------------------------------------------------------- initial new DNSKEY DS change DNSKEY removal -------------------------------------------------------------------- Parent: SOA0 --------> SOA1 --------> RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> DS1 --------> DS2 --------> RRSIGpar(DS) --------> RRSIGpar(DS) --------> Child: SOA0 SOA1 --------> SOA2 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) --------> DNSKEY1 DNSKEY1 --------> DNSKEY2 DNSKEY2 --------> DNSKEY10 DNSKEY10 --------> DNSKEY10 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) RRSIG2 (DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) -------------------------------------------------------------------- Stages of Deployment for a Double Signature Key Signing Key Rollover initial: Initial version of the zone. The parental DS points to DNSKEY1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY1 -- it is needed during the rollover and we refer to the value as TTL_DS. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS1 with DS2. DNSKEY removal: DNSKEY1 has been removed. The scenario above puts the responsibility for maintaining a valid chain of trust with the child. It also is based on the premise that the parent only has one DS RR (per algorithm) per zone. An alternative mechanism has been considered. Using an established trust relation, the interaction can be performed in-band, and the removal of the keys by the child can possibly be signaled by the parent. In this mechanism, there are periods where there are two DS
RRs at the parent. Since at the moment of writing the protocol for this interaction has not been developed, further discussion is out of scope for this document.
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.
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.
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.
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. 21]. 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.
15], which allows transfer of DS RRs and optionally DNSKEY RRs.
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 . 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.  Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.  Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004.  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.  Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.  Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.  Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999.  Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.  Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.  Hollenbeck, S., "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 4310, December 2005.  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", The Journal of Cryptology 14 (255-293), 2001.  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.  Rose, S., "NIST DNSSEC workshop notes", June 2001.  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC", Work in Progress, January 2006.  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
 Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
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  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.
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.
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.
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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).