RFC 6781
DNSSEC Operational Practices, Version 2
6. Security Considerations
DNSSEC adds data origin authentication and data integrity to the DNS, using digital signatures over Resource Record sets. DNSSEC does not protect against denial-of-service attacks, nor does it provide confidentiality. For more general security considerations related to DNSSEC, please see RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035].
This document tries to assess the operational considerations to maintain a stable and secure DNSSEC service. When performing key rollovers, it is important to keep in mind that it takes time for the data to be propagated to the verifying clients. It is also important to note that this data may be cached. Not taking into account the 'data propagation' properties in the DNS may cause validation failures, because cached data may mismatch data fetched from the authoritative servers; this will make secured zones unavailable to security-aware resolvers.7. Acknowledgments
Significant parts of the text of this document are copied from RFC 4641 [RFC4641]. That document was edited by Olaf Kolkman and Miek Gieben. Other people that contributed or were otherwise involved in that work were, 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, Peter Koch, Mike StJohns, Emma Bretherick, Adrian Bedford, Lindy Foster, and O. Courtay. For this version of the document, we would like to acknowledge people who were actively involved in the compilation of the document. In random order: Mark Andrews, Patrik Faltstrom, Tony Finch, Alfred Hoenes, Bill Manning, Scott Rose, Wouter Wijngaards, Antoin Verschuren, Marc Lampo, George Barwood, Sebastian Castro, Suresh Krishnaswamy, Eric Rescorla, Stephen Morris, Olafur Gudmundsson, Ondrej Sury, and Rickard Bellgrim.8. Contributors
Significant contributions to this document were from: Paul Hoffman, who contributed on the choice of cryptographic parameters and addressing some of the trust anchor issues; Jelte Jansen, who provided the initial text in Section 4.1.4; Paul Wouters, who provided the initial text for Section 5, and Alex Bligh, who improved it. The figure in Section 4.4.2 was adapted from the OpenDNSSEC user documentation.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.9.2. Informative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, September 2002. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007. [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010. [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, July 2010. [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, April 2012. [NIST-Workshop] Rose, S., "NIST DNSSEC workshop notes", July 2001, <http://www.ietf.org/mail-archive/web/dnsop/current/ msg01020.html>. [NIST-SP-800-90A] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST Special Publication 800-90A, January 2012. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[DNSSEC-KEY-TIMING] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing Considerations", Work in Progress, July 2012. [DNSSEC-DPS] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A Framework for DNSSEC Policies and DNSSEC Practice Statements", Work in Progress, November 2012. [DNSSEC-TRUST-ANCHOR] Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor Configuration and Maintenance", Work in Progress, October 2010. [NSEC3-HASH-PERF] Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs document 2010-002, March 2010.
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 RFC 4033 [RFC4033]. An RRset in DNSSEC is marked "Bogus" when a signature of an RRset does not validate against a DNSKEY. 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. 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 for RSA keys. It is mathematically more correct to use modulus size for RSA keys, 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 the use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private. Refresh Period: The period before the expiration time of the signature, during which the signature is refreshed by the signer. Re-Sign Period: This refers to the frequency with which a signing pass on the zone is performed. The Re-Sign Period defines when the zone is exposed to the signer. And on the signer, not all signatures in the zone have to be regenerated: That depends on the Refresh Period.
Secure Entry Point (SEP) key: A KSK that has a DS record in the
parent zone pointing to it or that is configured as a trust
anchor. Although not required by the protocol, we suggest that
the SEP flag [RFC4034] be 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.
Signing jitter: A random variation in the signature validity period
of RRSIGs in a zone to prevent all of them from expiring at the
same time.
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.
Singing the zone file: The term used for the event where an
administrator joyfully signs its zone file while producing melodic
sound patterns.
Single-Type Signing Scheme: A signing scheme whereby the distinction
between Zone Signing Keys and Key Signing Keys is not made.
Zone administrator: The 'role' that is responsible for signing a
zone and publishing it on the primary authoritative server.
Zone Signing Key (ZSK): A key that is used for signing all data in a
zone (except, perhaps, the DNSKEY RRset). The fact that a key is
a ZSK is only relevant to the signing tool.
Appendix B. Typographic Conventions
The following typographic conventions are used in this document: Key notation: A key is denoted by DNSKEY_x_y, where x is an identifier for the type of key: K for Key Signing Key, Z for Zone Signing Key, and S when there is no distinction made between KSKs and ZSKs but the key is used as a secure entry point. The 'y' denotes a number or an identifier; y could be thought of as the key id. RRsets ignored: If the signatures of non-DNSKEY RRsets have the same parameters as the SOA, then those are not mentioned; e.g., in the example below, the SOA is signed with the same parameters as the foo.example.com A RRset and the latter is therefore ignored in the abbreviated notation. 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. An 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 RRSIG_x_y(type), which means that the RRset with the specific RRTYPE 'type' is signed with DNSKEY_x_y. Signatures in the parent zone are denoted as RRSIG_par(type). SOA representation: SOAs are represented as SOA_x, where x is the serial number. DS representation: DSs are represented as DS_x_y, where x and y are identifiers similar to the key notation: x is an identifier for the type of key the DS record refers to; y is the 'key id' of the key it refers to. 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 "SOA_x".
Using this notation, the following signed zone:
example.com. 3600 IN SOA ns1.example.com. olaf.example.net. (
2005092303 ; serial
450 ; refresh (7 minutes 30 seconds)
600 ; retry (10 minutes)
345600 ; expire (4 days)
300 ; minimum (5 minutes)
)
3600 RRSIG SOA 5 2 3600 20120824013000 (
20100424013000 14 example.com.
NMafnzmmZ8wevpCOI+/JxqWBzPxrnzPnSXfo
...
OMY3rTMA2qorupQXjQ== )
3600 NS ns1.example.com.
3600 NS ns2.example.com.
3600 NS ns3.example.com.
3600 RRSIG NS 5 2 3600 20120824013000 (
20100424013000 14 example.com.
p0Cj3wzGoPFftFZjj3jeKGK6wGWLwY6mCBEz
...
+SqZIoVHpvE7YBeH46wuyF8w4XknA4Oeimc4
zAgaJM/MeG08KpeHhg== )
3600 TXT "Net::DNS domain"
3600 RRSIG TXT 5 2 3600 20120824013000 (
20100424013000 14 example.com.
o7eP8LISK2TEutFQRvK/+U3wq7t4X+PQaQkp
...
BcQ1o99vwn+IS4+J1g== )
300 NSEC foo.example.com. NS SOA TXT RRSIG NSEC DNSKEY
300 RRSIG NSEC 5 2 300 20120824013000 (
20100424013000 14 example.com.
JtHm8ta0diCWYGu/TdrE1O1sYSHblN2i/IX+
...
PkXNI/Vgf4t3xZaIyw== )
3600 DNSKEY 256 3 5 (
AQPaoHW/nC0fj9HuCW3hACSGiP0AkPS3dQFX
...
sAuryjQ/HFa5r4mrbhkJ
) ; key id = 14
3600 DNSKEY 257 3 5 (
AQPUiszMMAi36agx/V+7Tw95l8PYmoVjHWvO
...
oy88Nh+u2c9HF1tw0naH
) ; key id = 15
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 14 example.com.
HWj/VEr6p/FiUUiL70QQWtk+NBIlsJ9mdj5U
...
QhhmMwV3tIxJk2eDRQ== )
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 15 example.com.
P47CUy/xPV8qIEuua4tMKG6ei3LQ8RYv3TwE
...
JWL70YiUnUG3m9OL9w== )
foo.example.com. 3600 IN A 192.0.2.2
3600 RRSIG A 5 3 3600 20120824013000 (
20100424013000 14 example.com.
xHr023P79YrSHHMtSL0a1nlfUt4ywn/vWqsO
...
JPV/SA4BkoFxIcPrDQ== )
300 NSEC example.com. A RRSIG NSEC
300 RRSIG NSEC 5 3 300 20120824013000 (
20100424013000 14 example.com.
Aaa4kgKhqY7Lzjq3rlPlFidymOeBEK1T6vUF
...
Qe000JyzObxx27pY8A== )
is reduced to the following representation:
SOA_2005092303
RRSIG_Z_14(SOA_2005092303)
DNSKEY_K_14
DNSKEY_Z_15
RRSIG_K_14(DNSKEY)
RRSIG_Z_15(DNSKEY)
The rest of the zone data has the same signature as the SOA record,
i.e., an RRSIG created with DNSKEY_K_14.
Appendix C. Transition Figures for Special Cases of Algorithm Rollovers
The figures in this appendix complement and illustrate the special cases of algorithm rollovers as described in Section 4.1.4. ---------------------------------------------------------------- initial new RRSIGs new DNSKEY ---------------------------------------------------------------- Parent: SOA_0 --------------------------------------------------------> RRSIG_par(SOA) -----------------------------------------------> DS_S_1 -------------------------------------------------------> RRSIG_par(DS_S_1) --------------------------------------------> Child: SOA_0 SOA_1 SOA_2 RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_1(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA) DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) ---------------------------------------------------------------- new DS DNSKEY removal RRSIGs removal ---------------------------------------------------------------- Parent: SOA_1 -------------------------------------------------------> RRSIG_par(SOA) ----------------------------------------------> DS_S_2 ------------------------------------------------------> RRSIG_par(DS_S_2) -------------------------------------------> Child: -------------------> SOA_3 SOA_4 -------------------> RRSIG_S_1(SOA) -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA) -------------------> -------------------> DNSKEY_S_2 DNSKEY_S_2 -------------------> RRSIG_S_1(DNSKEY) -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) ---------------------------------------------------------------- Figure 12: Single-Type Signing Scheme Algorithm Roll Also see Section 4.1.4.1.
----------------------------------------------------------------
initial new RRSIGs new DNSKEY
----------------------------------------------------------------
Parent:
SOA_0 -------------------------------------------------------->
RRSIG_par(SOA) ----------------------------------------------->
DS_K_1 ------------------------------------------------------->
RRSIG_par(DS_K_1) -------------------------------------------->
Child:
SOA_0 SOA_1 SOA_2
RRSIG_Z_1(SOA) RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
DNSKEY_K_1 DNSKEY_K_1 DNSKEY_K_1
DNSKEY_K_2
DNSKEY_Z_1 DNSKEY_Z_1 DNSKEY_Z_1
DNSKEY_Z_2
RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY) RRSIG_K_1(DNSKEY)
RRSIG_K_2(DNSKEY)
----------------------------------------------------------------
new DS revoke DNSKEY DNSKEY removal
----------------------------------------------------------------
Parent:
SOA_1 ------------------------------------------------------->
RRSIG_par(SOA) ---------------------------------------------->
DS_K_2 ------------------------------------------------------>
RRSIG_par(DS_K_2) ------------------------------------------->
Child:
-------------------> SOA_3 SOA_4
-------------------> RRSIG_Z_1(SOA) RRSIG_Z_1(SOA)
-------------------> RRSIG_Z_2(SOA) RRSIG_Z_2(SOA)
-------------------> DNSKEY_K_1_REVOKED
-------------------> DNSKEY_K_2 DNSKEY_K_2
------------------->
-------------------> DNSKEY_Z_2 DNSKEY_Z_2
-------------------> RRSIG_K_1(DNSKEY)
-------------------> RRSIG_K_2(DNSKEY) RRSIG_K_2(DNSKEY)
---------------------------------------------------------------- RRSIGs removal ---------------------------------------------------------------- Parent: -------------------------------------> -------------------------------------> -------------------------------------> -------------------------------------> Child: SOA_5 RRSIG_Z_2(SOA) DNSKEY_K_2 DNSKEY_Z_2 RRSIG_K_2(DNSKEY) ---------------------------------------------------------------- Figure 13: RFC 5011 Style Algorithm Roll Also see Section 4.1.4.2. ---------------------------------------------------------------- initial new RRSIGs new DNSKEY ---------------------------------------------------------------- Parent: SOA_0 --------------------------------------------------------> RRSIG_par(SOA) -----------------------------------------------> DS_S_1 -------------------------------------------------------> RRSIG_par(DS_S_1) --------------------------------------------> Child: SOA_0 SOA_1 SOA_2 RRSIG_S_1(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_Z_10(SOA) RRSIG_S_2(SOA) RRSIG_S_2(SOA) DNSKEY_S_1 DNSKEY_S_1 DNSKEY_S_1 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_Z_10 DNSKEY_S_2 RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY)
---------------------------------------------------------------- new DS revoke DNSKEY DNSKEY removal ---------------------------------------------------------------- Parent: SOA_1 -------------------------------------------------------> RRSIG_par(SOA) ----------------------------------------------> DS_S_2 ------------------------------------------------------> RRSIG_par(DS_S_2) -------------------------------------------> Child: -------------------> SOA_3 SOA_4 -------------------> RRSIG_Z_10(SOA) -------------------> RRSIG_S_2(SOA) RRSIG_S_2(SOA) -------------------> DNSKEY_S_1_REVOKED -------------------> DNSKEY_Z_10 -------------------> DNSKEY_S_2 DNSKEY_S_2 -------------------> RRSIG_S_1(DNSKEY) RRSIG_S_1(DNSKEY) -------------------> RRSIG_S_2(DNSKEY) RRSIG_S_2(DNSKEY) ---------------------------------------------------------------- RRSIGs removal ---------------------------------------------------------------- Parent: -------------------------------------> -------------------------------------> -------------------------------------> -------------------------------------> Child: SOA_5 RRSIG_S_2(SOA) DNSKEY_S_2 RRSIG_S_2(DNSKEY) ---------------------------------------------------------------- Figure 14: RFC 5011 Algorithm Roll in a Single-Type Signing Scheme Environment Also see Section 4.1.4.3.
Appendix D. Transition Figure for Changing DNS Operators
The figure in this Appendix complements and illustrates the special case of changing DNS operators as described in Section 4.3.5.1.
------------------------------------------------------------ new DS | pre-publish | ------------------------------------------------------------ Parent: NS_A NS_A DS_A DS_B DS_A DS_B ------------------------------------------------------------ Child at A: Child at A: Child at B: SOA_A0 SOA_A1 SOA_B0 RRSIG_Z_A(SOA) RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) NS_A NS_A NS_B RRSIG_Z_A(NS) NS_B RRSIG_Z_B(NS) RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_A DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ ------------------------------------------------------------ re-delegation | post-migration | ------------------------------------------------------------ Parent: NS_B NS_B DS_A DS_B DS_B ------------------------------------------------------------ Child at A: Child at B: Child at B: SOA_A1 SOA_B0 SOA_B1 RRSIG_Z_A(SOA) RRSIG_Z_B(SOA) RRSIG_Z_B(SOA) NS_A NS_B NS_B NS_B RRSIG_Z_B(NS) RRSIG_Z_B(NS) RRSIG_Z_A(NS) DNSKEY_Z_A DNSKEY_Z_A DNSKEY_Z_B DNSKEY_Z_B DNSKEY_Z_B DNSKEY_K_A DNSKEY_K_B DNSKEY_K_B RRSIG_K_A(DNSKEY) RRSIG_K_B(DNSKEY) RRSIG_K_B(DNSKEY) ------------------------------------------------------------ Figure 15: An Alternative Rollover Approach for Cooperating Operators
Appendix E. Summary of Changes from RFC 4641
This document differs from RFC 4641 [RFC4641] in the following ways: o Addressed the errata listed on <http://www.rfc-editor.org/errata_search.php?rfc=4641>. o Recommended RSA/SHA-256 in addition to RSA/SHA-1. o Did a complete rewrite of Section 3.5 of RFC 4641 (Section 3.4.2 of this document), removing the table and suggesting a key size of 1024 for keys in use for less than 8 years, issued up to at least 2015. o Removed the KSK for high-level zones consideration. o Added text on algorithm rollover. o Added text on changing (non-cooperating) DNS registrars. o Did a significant rewrite of Section 3, whereby the argument is made that the timescales for rollovers are made purely on operational arguments. o Added Section 5. o Introduced Single-Type Signing Scheme terminology and made the arguments for the choice of a Single-Type Signing Scheme more explicit. o Added a section about stand-by keys.
Authors' Addresses
Olaf M. Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands EMail: olaf@nlnetlabs.nl URI: http://www.nlnetlabs.nl W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands EMail: matthijs@nlnetlabs.nl URI: http://www.nlnetlabs.nl R. (Miek) Gieben SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands EMail: miek.gieben@sidn.nl URI: http://www.sidn.nl