Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6781

DNSSEC Operational Practices, Version 2

Pages: 71
Obsoletes:  4641
Part 4 of 4 – Pages 54 to 71
First   Prev   None

Top   ToC   RFC6781 - Page 54   prevText

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].
Top   ToC   RFC6781 - Page 55
   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.
Top   ToC   RFC6781 - Page 56

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.
Top   ToC   RFC6781 - Page 57
   [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.

              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,
              January 2012.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
Top   ToC   RFC6781 - Page 58
              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,
              October 2010.

              Schaeffer, Y., "NSEC3 Hash Performance", NLnet Labs
              document 2010-002, March 2010.
Top   ToC   RFC6781 - Page 59

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.
Top   ToC   RFC6781 - Page 60
   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.
Top   ToC   RFC6781 - Page 61

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 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: " 3600 IN A" 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".
Top   ToC   RFC6781 - Page 62
   Using this notation, the following signed zone:  3600  IN SOA (
                           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
                           OMY3rTMA2qorupQXjQ== )
          3600    NS
          3600    NS
          3600    NS
          3600    RRSIG    NS 5 2 3600 20120824013000 (
                           20100424013000 14
                           zAgaJM/MeG08KpeHhg== )
          3600    TXT      "Net::DNS  domain"
          3600    RRSIG    TXT 5 2 3600 20120824013000 (
                           20100424013000 14
                           BcQ1o99vwn+IS4+J1g== )
          300     RRSIG    NSEC 5 2 300 20120824013000 (
                           20100424013000 14
                           PkXNI/Vgf4t3xZaIyw== )
          3600    DNSKEY   256 3 5 (
                           ) ; key id = 14
          3600    DNSKEY   257 3 5 (
                           ) ; key id = 15
Top   ToC   RFC6781 - Page 63
          3600    RRSIG    DNSKEY 5 2 3600 20120824013000 (
                           20100424013000 14
                           QhhmMwV3tIxJk2eDRQ== )
          3600    RRSIG    DNSKEY 5 2 3600 20120824013000 (
                           20100424013000 15
                           JWL70YiUnUG3m9OL9w== )  3600  IN A
          3600    RRSIG    A 5 3 3600 20120824013000 (
                           20100424013000 14
                           JPV/SA4BkoFxIcPrDQ== )
          300     NSEC A RRSIG NSEC
          300     RRSIG    NSEC 5 3 300 20120824013000 (
                           20100424013000 14
                           Qe000JyzObxx27pY8A== )

   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.
Top   ToC   RFC6781 - Page 64

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
Top   ToC   RFC6781 - Page 65
    initial              new RRSIGs           new DNSKEY
    SOA_0 -------------------------------------------------------->
    RRSIG_par(SOA) ----------------------------------------------->
    DS_K_1 ------------------------------------------------------->
    RRSIG_par(DS_K_1) -------------------------------------------->

    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_Z_1           DNSKEY_Z_1           DNSKEY_Z_1

    new DS               revoke DNSKEY        DNSKEY removal
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_K_2 ------------------------------------------------------>
    RRSIG_par(DS_K_2) ------------------------------------------->

    -------------------> 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)
Top   ToC   RFC6781 - Page 66
    RRSIGs removal





                 Figure 13: RFC 5011 Style Algorithm Roll

   Also see Section

    initial              new RRSIGs           new DNSKEY
    SOA_0 -------------------------------------------------------->
    RRSIG_par(SOA) ----------------------------------------------->
    DS_S_1 ------------------------------------------------------->
    RRSIG_par(DS_S_1) -------------------------------------------->

    SOA_0                SOA_1                SOA_2
    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
                         RRSIG_S_2(DNSKEY)    RRSIG_S_2(DNSKEY)
Top   ToC   RFC6781 - Page 67
    new DS               revoke DNSKEY        DNSKEY removal
    SOA_1 ------------------------------------------------------->
    RRSIG_par(SOA) ---------------------------------------------->
    DS_S_2 ------------------------------------------------------>
    RRSIG_par(DS_S_2) ------------------------------------------->

    -------------------> 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





            Figure 14: RFC 5011 Algorithm Roll in a Single-Type
                        Signing Scheme Environment

   Also see Section
Top   ToC   RFC6781 - Page 68

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
Top   ToC   RFC6781 - Page 69
    new DS             |        pre-publish                    |
     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)

     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_B(DNSKEY)  RRSIG_K_B(DNSKEY)

          re-delegation                |   post-migration      |
              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)

     DNSKEY_Z_A         DNSKEY_Z_A
     DNSKEY_Z_B         DNSKEY_Z_B            DNSKEY_Z_B
     DNSKEY_K_A         DNSKEY_K_B            DNSKEY_K_B

   Figure 15: An Alternative Rollover Approach for Cooperating Operators
Top   ToC   RFC6781 - Page 70

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 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.
Top   ToC   RFC6781 - Page 71

Authors' Addresses

Olaf M. Kolkman NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands EMail: URI: W. (Matthijs) Mekking NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands EMail: URI: R. (Miek) Gieben SIDN Labs Meander 501 Arnhem 6825 MD The Netherlands EMail: URI: