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
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.
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
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,
9.2. Informative References
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
[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,
Rose, S., "NIST DNSSEC workshop notes", July 2001,
Barker, E. and J. Kelsey, "Recommendation for Random
Number Generation Using Deterministic Random Bit
Generators", NIST Special Publication 800-90A,
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key
Timing Considerations", Work in Progress, July 2012.
Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", Work in Progress, November 2012.
Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor
Configuration and Maintenance", Work in Progress,
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
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
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
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
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
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
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
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
SOA representation: SOAs are represented as SOA_x, where x is the
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
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 14 example.com.
3600 RRSIG DNSKEY 5 2 3600 20120824013000 (
20100424013000 15 example.com.
foo.example.com. 3600 IN A 192.0.2.2
3600 RRSIG A 5 3 3600 20120824013000 (
20100424013000 14 example.com.
300 NSEC example.com. A RRSIG NSEC
300 RRSIG NSEC 5 3 300 20120824013000 (
20100424013000 14 example.com.
is reduced to the following representation:
The rest of the zone data has the same signature as the SOA record,
i.e., an RRSIG created with DNSKEY_K_14.
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
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
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
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
o Added a section about stand-by keys.