tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6781

 
 
 

DNSSEC Operational Practices, Version 2

Part 4 of 4, p. 54 to 71
Prev RFC Part

 


prevText      Top      Up      ToC       Page 54 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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.

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

Top      Up      ToC       Page 58 
   [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.

Top      Up      ToC       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      Up      ToC       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      Up      ToC       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
      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".

Top      Up      ToC       Page 62 
   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

Top      Up      ToC       Page 63 
          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.

Top      Up      ToC       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 4.1.4.1.

Top      Up      ToC       Page 65 
   ----------------------------------------------------------------
    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)

Top      Up      ToC       Page 66 
   ----------------------------------------------------------------
    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)

Top      Up      ToC       Page 67 
   ----------------------------------------------------------------
    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.

Top      Up      ToC       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 4.3.5.1.

Top      Up      ToC       Page 69 
    ------------------------------------------------------------
    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

Top      Up      ToC       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
      <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.

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