tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6781

 
 
 

DNSSEC Operational Practices, Version 2

Part 3 of 4, p. 39 to 54
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 39 
4.3.  Parent Policies

4.3.1.  Initial Key Exchanges and Parental Policies Considerations

   The initial key exchange is always subject to the policies set by the
   parent.  It is specifically important in a registry-registrar-
   registrant model where a registry maintains the parent zone, and the
   registrant (the user of the child-domain name) deals with the
   registry through an intermediary called a registrar (see [RFC3375]
   for a comprehensive definition).  The key material is to be passed
   from the DNS operator to the parent via a registrar, where both the
   DNS operator and registrar are selected by the registrant and might
   be different organizations.  When designing a key exchange policy,
   one should take into account that the authentication and
   authorization mechanisms used during a key exchange should be as
   strong as the authentication and authorization mechanisms used for
   the exchange of delegation information between the parent and child.
   That is, there is no implicit need in DNSSEC to make the
   authentication process stronger than it is for regular DNS.

   Using the DNS itself as the source for the actual DNSKEY material has
   the benefit that it reduces the chances of user error.  A DNSKEY
   query tool can make use of the SEP bit [RFC4035] to select the proper
   key(s) 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 that
   the child is secure.

   Note: Out-of-band verification is still needed when the key material
   is fetched for the first time, even via DNS.  The parent can never be
   sure whether or not the DNSKEY RRs have been spoofed.

   With some types of key rollovers, the DNSKEY is not pre-published,
   and a DNSKEY query tool is not able to retrieve the successor key.
   In this case, the out-of-band method is required.  This also allows
   the child to determine the digest algorithm of the DS record.

Top      Up      ToC       Page 40 
4.3.2.  Storing Keys or Hashes?

   When designing a registry system, one should consider whether to
   store the DNSKEYs and/or the corresponding DSs.  Since a child zone
   might wish to have a DS published using a message digest algorithm
   not yet understood by the registry, the registry can't count on being
   able to generate the DS record from a raw DNSKEY.  Thus, we suggest
   that registry systems should be able to store DS RRs, even if they
   also store DNSKEYs (see also "DNSSEC Trust Anchor Configuration and
   Maintenance" [DNSSEC-TRUST-ANCHOR]).

   The storage considerations also relate to the design of the customer
   interface and the method by which data is transferred between the
   registrant and registry: Will the child-zone administrator be able to
   upload DS RRs with unknown hash algorithms, or does the interface
   only allow DNSKEYs?  When registries support the Extensible
   Provisioning Protocol (EPP) [RFC5910], that can be used for
   registrar-registry interactions, since that protocol allows the
   transfer of both DS and, optionally, DNSKEY RRs.  There is no
   standardized way to move the data between the customer and the
   registrar.  Different registrars have different mechanisms, ranging
   from simple web interfaces to various APIs.  In some cases, the use
   of the DNSSEC extensions to EPP may be applicable.

   Having an out-of-band mechanism such as a registry directory (e.g.,
   Whois) to find out which keys are used to generate DS Resource
   Records for specific owners and/or zones may also help with
   troubleshooting.

4.3.3.  Security Lameness

   Security lameness is defined as the state whereby the parent has a DS
   RR pointing to a nonexistent DNSKEY RR.  Security lameness may occur
   temporarily during a Double-DS rollover scheme.  However, care should
   be taken that not all DS RRs are pointing to a nonexistent DNSKEY RR,
   which will cause the child's zone to be marked Bogus by verifying DNS
   clients.

   As part of a comprehensive delegation check, the parent could, at key
   exchange time, verify that the child's key is actually configured in
   the DNS.  However, if a parent does not understand the hashing
   algorithm used by the child, the parental checks are limited to only
   comparing the key id.

Top      Up      ToC       Page 41 
   Child zones should be very careful in removing DNSKEY material --
   specifically, SEP keys -- for which a DS RR exists.

   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
   take time to propagate through the DNS.

4.3.4.  DS Signature Validity Period

   Since the DS can be replayed as long as it has a valid signature, a
   short signature validity period for the DS RRSIG minimizes the time
   that a child is vulnerable in the case of a compromise of the child's
   KSK(s).  A signature validity period that is too short introduces the
   possibility that a zone is marked Bogus in the case of a
   configuration error in the signer.  There may not be enough time to
   fix the problems before signatures expire (this is a generic
   argument; also see Section 4.4.2).  Something as mundane as zone
   administrator unavailability during weekends shows the need for DS
   signature validity periods longer than two days.  Just like any
   signature validity period, we suggest an absolute minimum for the DS
   signature validity period of a few days.

   The maximum signature validity period of the DS record depends on how
   long child zones are willing to be vulnerable after a key compromise.
   On the other hand, shortening the DS signature validity period
   increases the operational risk for the parent.  Therefore, the parent
   may have a policy to use a signature validity period that is
   considerably longer than the child would hope for.

   A compromise between the policy/operational constraints of the parent
   and minimizing damage for the child may result in a DS signature
   validity period somewhere between a week and several months.

   In addition to the signature validity period, which sets a lower
   bound on the number of times the zone administrator will need to sign
   the zone data and an upper bound on the time that a child is
   vulnerable after key compromise, there is the TTL value on the DS
   RRs.  Shortening the TTL reduces the damage of a successful replay
   attack.  It does mean that the authoritative servers will see more
   queries.  But on the other hand, a short TTL lowers the persistence
   of DS RRsets in caches, thereby increasing the speed with which
   updated DS RRsets propagate through the DNS.

Top      Up      ToC       Page 42 
4.3.5.  Changing DNS Operators

   The parent-child relationship is often described in terms of a
   registry-registrar-registrant model, where a registry maintains the
   parent zone and the registrant (the user of the child-domain name)
   deals with the registry through an intermediary called a registrar
   [RFC3375].  Registrants may outsource the maintenance of their DNS
   system, including the maintenance of DNSSEC key material, to the
   registrar or to another third party, referred to here as the DNS
   operator.

   For various reasons, a registrant may want to move between DNS
   operators.  How easy this move will be depends principally on the DNS
   operator from which the registrant is moving (the losing operator),
   as the losing operator has control over the DNS zone and its keys.
   The following sections describe the two cases: where the losing
   operator cooperates with the new operator (the gaining operator), and
   where the two do not cooperate.

4.3.5.1.  Cooperating DNS Operators

   In this scenario, it is assumed that the losing operator will not
   pass any private key material to the gaining operator (that would
   constitute a trivial case) but is otherwise fully cooperative.

   In this environment, the change could be made with a Pre-Publish ZSK
   rollover, whereby the losing operator pre-publishes the ZSK of the
   gaining operator, combined with a Double-Signature KSK rollover where
   the two registrars exchange public keys and independently generate a
   signature over those key sets that they combine and both publish in
   their copy of the zone.  Once that is done, they can use their own
   private keys to sign any of their zone content during the transfer.

Top      Up      ToC       Page 43 
    ------------------------------------------------------------
    initial            |        pre-publish                    |
    ------------------------------------------------------------
    Parent:
     NS_A                            NS_A
     DS_A                            DS_A
    ------------------------------------------------------------
    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_A
                            DNSKEY_K_B         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_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_A
     DNSKEY_K_B         DNSKEY_K_B            DNSKEY_K_B
     RRSIG_K_A(DNSKEY)  RRSIG_K_A(DNSKEY)
     RRSIG_K_B(DNSKEY)  RRSIG_K_B(DNSKEY)     RRSIG_K_B(DNSKEY)
    ------------------------------------------------------------

               Figure 10: Rollover for Cooperating Operators

Top      Up      ToC       Page 44 
   In this figure, A denotes the losing operator and B the gaining
   operator.  RRSIG_Z is the RRSIG produced by a ZSK, RRSIG_K is
   produced with a KSK, and the appended A or B indicates the producers
   of the key pair.  "Child at A" is how the zone content is represented
   by the losing DNS operator, and "Child at B" is how the zone content
   is represented by the gaining DNS operator.

   The zone is initially delegated from the parent to the name servers
   of operator A.  Operator A uses his own ZSK and KSK to sign the zone.
   The cooperating operator A will pre-publish the new NS record and the
   ZSK and KSK of operator B, including the RRSIG over the DNSKEY RRset
   generated by the KSK of operator B.  Operator B needs to publish the
   same DNSKEY RRset.  When that DNSKEY RRset has populated the caches,
   the re-delegation can be made, which involves adjusting the NS and DS
   records in the parent zone to point to operator B.  And after all
   DNSSEC records related to operator A have expired from the caches,
   operator B can stop publishing the keys and signatures belonging to
   operator A, and vice versa.

   The requirement to exchange signatures has a couple of drawbacks.  It
   requires more operational overhead, because not only do the operators
   have to exchange public keys but they also have to exchange the
   signatures of the new DNSKEY RRset.  This drawback does not exist if
   the Double-Signature KSK rollover is replaced with a Double-DS KSK
   rollover.  See Figure 15 in Appendix D for the diagram.

   Thus, if the registry and registrars allow DS records to be published
   that do not point to a published DNSKEY in the child zone, the
   Double-DS KSK rollover is preferred (see Figure 5), in combination
   with the Pre-Publish ZSK rollover.  This does not require sharing the
   KSK signatures between the operators, but both operators still have
   to publish each other's ZSKs.

4.3.5.2.  Non-Cooperating DNS Operators

   In the non-cooperating case, matters are more complicated.  The
   losing operator may not cooperate and leave the data in the DNS as
   is.  In extreme cases, the losing operator may become obstructive and
   publish a DNSKEY RR with a high TTL and corresponding signature
   validity period so that registrar A's DNSKEY could end up in caches
   for (in theory at least) decades.

   The problem arises when a validator tries to validate with the losing
   operator's key and there is no signature material produced with the
   losing operator available in the delegation path after re-delegation
   from the losing operator to the gaining operator has taken place.
   One could imagine a rollover scenario where the gaining operator
   takes a copy of all RRSIGs created by the losing operator and

Top      Up      ToC       Page 45 
   publishes those in conjunction with its own signatures, but that
   would not allow any changes in the zone content.  Since a
   re-delegation took place, the NS RRset has by definition changed, so
   such a rollover scenario will not work.  Besides, if zone transfers
   are not allowed by the losing operator and NSEC3 is deployed in the
   losing operator's zone, then the gaining operator's zone will not
   have certainty that all of the losing operator's RRSIGs have been
   copied.

   The only viable operation for the registrant is to have his zone go
   Insecure for the duration of the change.  The registry should be
   asked to remove the DS RR pointing to the losing operator's DNSKEY
   and to change the NS RRset to point to the gaining operator.  Once
   this has propagated through the DNS, the registry should be asked to
   insert the DS record pointing to the (newly signed) zone at
   operator B.

   Note that some behaviors of resolver implementations may aid in the
   process of changing DNS operators:

   o  TTL sanity checking, as described in RFC 2308 [RFC2308], will
      limit the impact of the actions of an obstructive losing operator.
      Resolvers that implement TTL sanity checking will use an upper
      limit for TTLs on RRsets in responses.

   o  If RRsets at the zone cut (are about to) expire, the resolver
      restarts its search above the zone cut.  Otherwise, the resolver
      risks continuing to use a name server that might be un-delegated
      by the parent.

   o  Limiting the time that DNSKEYs that seem to be unable to validate
      signatures are cached and/or trying to recover from cases where
      DNSKEYs do not seem to be able to validate data also reduce the
      effects of the problem of non-cooperating registrars.

   However, there is no operational methodology to work around this
   business issue, and proper contractual relationships between all
   involved parties seem to be the only solution to cope with these
   problems.  It should be noted that in many cases, the problem with
   temporary broken delegations already exists when a zone changes from
   one DNS operator to another.  Besides, it is often the case that when
   operators are changed, the services that are referenced by that zone
   also change operators, possibly involving some downtime.

   In any case, to minimize such problems, the classic configuration is
   to have relatively short TTLs on all involved Resource Records.  That
   will solve many of the problems regarding changes to a zone,
   regardless of whether DNSSEC is used.

Top      Up      ToC       Page 46 
4.4.  Time in DNSSEC

   Without DNSSEC, all times in the DNS are relative.  The SOA fields
   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
   that has elapsed after a slave server synchronized with a master
   server.  The TTL value and the SOA RR minimum TTL parameter [RFC2308]
   are used to determine how long a forwarder should cache data (or
   negative responses) 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.

   The considerations in this section are all qualitative and focused on
   the operational and managerial issues.  A more thorough quantitative
   analysis of rollover timing parameters can be found in "DNSSEC Key
   Timing Considerations" [DNSSEC-KEY-TIMING].

4.4.1.  Time Considerations

   Because of the expiration of signatures, one should consider the
   following:

   o  We suggest that the Maximum Zone TTL value of your zone data be
      smaller than your signature validity period.

         If the TTL duration was similar to that of the signature
         validity period, then all RRsets fetched during the validity
         period would be cached until the signature expiration time.
         Section 8.1 of RFC 4033 [RFC4033] 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, the query load on authoritative servers
         would peak at the signature expiration time, as this is also
         the time at which records simultaneously expire from caches.

         Having a TTL that is at least a few times smaller than your
         signature validity period avoids query load peaks.

   o  We suggest that the signature publication period end at least one
      Maximum Zone TTL duration (but preferably a minimum of a few days)
      before the end of the signature validity period.

         Re-signing a zone shortly before the end of the signature
         validity period may cause the simultaneous expiration of data
         from caches.  This in turn may lead to peaks in the load on
         authoritative servers.  To avoid this, schemes are deployed

Top      Up      ToC       Page 47 
         whereby the zone is periodically visited for a re-signing
         operation, and those signatures that are within a so-called
         Refresh Period from signature expiration are recreated.  Also
         see Section 4.4.2 below.

         In the case of an operational error, you would have one Maximum
         Zone TTL duration to resolve the problem.  Re-signing a zone a
         few days before the end of the signature validity period
         ensures that the signatures will survive at least a (long)
         weekend in case of such operational havoc.  This is called the
         Refresh Period (see Section 4.4.2).

   o  We suggest that the Minimum Zone TTL be long enough to both fetch
      and verify all the RRs in the trust chain.  In workshop
      environments, it has been demonstrated [NIST-Workshop] 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: DS, DNSKEY, RRSIG, and the final
          answers, i.e., the RRset that is returned for the initial
          query.

      2.  Frequent verification causes load on recursive name servers.
          Data at delegation points, DS, DNSKEY, and RRSIG RRs benefits
          from caching.  The TTL on those should be relatively long.
          Data at the leaves in the DNS tree has less impact on
          recursive name servers.

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

Top      Up      ToC       Page 48 
         If the server serves a DNSSEC-secured zone, then it may happen
         that the signatures expire well before the SOA expiration timer
         counts down to zero.  It is not possible to completely prevent
         this by modifying the SOA parameters.

         However, the effects can be minimized where the SOA expiration
         time is equal to or shorter than the Refresh Period (see
         Section 4.4.2).

         The consequence of an authoritative server not being able to
         update a zone for an extended period of time is that signatures
         may expire.  In this case, 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 that the SOA expiration timer be approximately one
         third or a quarter of the signature validity period.  It will
         allow problems with transfers from the master server to be
         noticed before signatures time out.

         We also suggest that operators of name servers that supply
         secondary services develop systems to identify upcoming
         signature expirations in zones they slave and take appropriate
         action where such an event is detected.

         When determining the value for the expiration parameter, one
         has to take the following into account: What are the chances
         that all secondaries expire the zone?  How quickly can the
         administrators of the secondary servers be reached to load a
         valid zone?  These questions are not DNSSEC-specific but may
         influence the choice of your signature validity periods.

4.4.2.  Signature Validity Periods

4.4.2.1.  Maximum Value

   The first consideration for choosing a maximum signature validity
   period is the risk of a replay attack.  For low-value, long-term
   stable resources, the risks may be minimal, and the signature
   validity period may be several months.  Although signature validity
   periods of many years are allowed, the same "operational habit"
   arguments as those given in Section 3.2.2 play a role: When a zone is
   re-signed with some regularity, then zone administrators remain
   conscious of the operational necessity of re-signing.

Top      Up      ToC       Page 49 
4.4.2.2.  Minimum Value

   The minimum value of the signature validity period is set for the
   time by which one would like to survive operational failure in
   provisioning: At what time will a failure be noticed, and at what
   time is action expected to be taken?  By answering these questions,
   availability of zone administrators during (long) weekends or time
   taken to access backup media can be taken into account.  The result
   could easily suggest a minimum signature validity period of a few
   days.

   Note, however, that the argument above is assuming that zone data has
   just been signed and published when the problem occurred.  In
   practice, it may be that a zone is signed according to a frequency
   set by the Re-Sign Period, whereby the signer visits the zone content
   and only refreshes signatures that are within a given amount of time
   (the Refresh Period) of expiration.  The Re-Sign Period must be
   smaller than the Refresh Period in order for zone data to be signed
   in a timely fashion.

   If an operational problem occurs during re-signing, then the
   signatures in the zone to expire first are the ones that have been
   generated longest ago.  In the worst case, these signatures are the
   Refresh Period minus the Re-Sign Period away from signature
   expiration.

   To make matters slightly more complicated, some signers vary the
   signature validity period over a small range (the jitter interval) so
   that not all signatures expire at the same time.

   In other words, the minimum signature validity period is set by first
   choosing the Refresh Period (usually a few days), then defining the
   Re-Sign Period in such a way that the Refresh Period minus the
   Re-Sign Period, minus the maximum jitter sets the time in which
   operational havoc can be resolved.

Top      Up      ToC       Page 50 
   The relationship between signature times is illustrated in Figure 11.

   Inception          Signing                                 Expiration
   time               time                                    time
   |                  |                                 |     |     |
   |------------------|---------------------------------|.....|.....|
   |                  |                                 |     |     |
                                                          +/-jitter

   | Inception offset |                                       |
   |<---------------->|            Validity Period            |
   |               |<---------------------------------------->|


   Inception          Signing Reuse   Reuse   Reuse   New     Expiration
   time               time                            RRSIG   time
   |                  |       |       |       |       |       |
   |------------------|-------------------------------|-------|
   |                  |       |       |       |       |       |
                       <-----> <-----> <-----> <----->
                     Re-Sign Period

                                                |   Refresh   |
                                                |<----------->|
                                                |   Period    |

                  Figure 11: Signature Timing Parameters

   Note that in the figure the validity of the signature starts shortly
   before the signing time.  That is done to deal with validators that
   might have some clock skew.  This is called the inception offset, and
   it should be chosen so that false negatives are minimized to a
   reasonable level.

4.4.2.3.  Differentiation between RRsets

   It is possible to vary signature validity periods between signatures
   over different RRsets in the zone.  In practice, this could be done
   when zones contain highly volatile data (which may be the case in
   dynamic-update environments).  Note, however, that the risk of replay
   (e.g., by stale secondary servers) should be the leading factor in
   determining the signature validity period, since the TTLs on the data
   itself are still the primary parameter for cache expiry.

   In some cases, the risk of replaying existing data might be different
   from the risk of replaying the denial of data.  In those cases, the
   signature validity period on NSEC or NSEC3 records may be tweaked
   accordingly.

Top      Up      ToC       Page 51 
   When a zone contains secure delegations, then a relatively short
   signature validity period protects the child against replay attacks
   in the case where the child's key is compromised (see Section 4.3.4).
   Since there is a higher operational risk for the parent registry when
   choosing a short validity period and a higher operational risk for
   the child when choosing a long validity period, some (price)
   differentiation may occur for validity periods between individual DS
   RRs in a single zone.

   There seem to be no other arguments for differentiation in validity
   periods.

5.  "Next Record" Types

   One of the design tradeoffs made during the development of DNSSEC was
   to separate the signing and serving operations instead of performing
   cryptographic operations as DNS requests are being serviced.  It is
   therefore necessary to create records that cover the very large
   number of nonexistent names that lie between the names that do exist.

   There are two mechanisms to provide authenticated proof of
   nonexistence of domain names in DNSSEC: a clear-text one and an
   obfuscated-data one.  Each mechanism:

   o  includes a list of all the RRTYPEs present, which can be used to
      prove the nonexistence of RRTYPEs at a certain name;

   o  stores only the name for which the zone is authoritative (that is,
      glue in the zone is omitted); and

   o  uses a specific RRTYPE to store information about the RRTYPEs
      present at the name: The clear-text mechanism uses NSEC, and the
      obfuscated-data mechanism uses NSEC3.

5.1.  Differences between NSEC and NSEC3

   The clear-text mechanism (NSEC) is implemented using a sorted linked
   list of names in the zone.  The obfuscated-data mechanism (NSEC3) is
   similar but first hashes the names using a one-way hash function,
   before creating a sorted linked list of the resulting (hashed)
   strings.

   The NSEC record requires no cryptographic operations aside from the
   validation of its associated signature record.  It is human readable
   and can be used in manual queries to determine correct operation.
   The disadvantage is that it allows for "zone walking", where one can
   request all the entries of a zone by following the linked list of
   NSEC RRs via the "Next Domain Name" field.  Though all agree that DNS

Top      Up      ToC       Page 52 
   data is accessible through query mechanisms, for some zone
   administrators this behavior is undesirable for policy, regulatory,
   or other reasons.

   Furthermore, NSEC requires a signature over every RR in the zone
   file, thereby ensuring that any denial of existence is
   cryptographically signed.  However, in a large zone file containing
   many delegations, very few of which are to signed zones, this may
   produce unacceptable additional overhead, especially where insecure
   delegations are subject to frequent updates (a typical example might
   be a TLD operator with few registrants using secure delegations).
   NSEC3 allows intervals between two secure delegations to "opt out",
   in which case they may contain one or more insecure delegations, thus
   reducing the size and cryptographic complexity of the zone at the
   expense of the ability to cryptographically deny the existence of
   names in a specific span.

   The NSEC3 record uses a hashing method of the requested name.  To
   increase the workload required to guess entries in the zone, the
   number of hashing iterations can be specified in the NSEC3 record.
   Additionally, a salt can be specified that also modifies the hashes.
   Note that NSEC3 does not give full protection against information
   leakage from the zone (you can still derive the size of the zone,
   which RRTYPEs are in there, etc.).

5.2.  NSEC or NSEC3

   The first motivation to deploy NSEC3 -- prevention of zone
   enumeration -- only makes sense when zone content is not highly
   structured or trivially guessable.  Highly structured zones, such as
   in-addr.arpa., ip6.arpa., and e164.arpa., can be trivially enumerated
   using ordinary DNS properties, while for small zones that only
   contain records in the apex of the zone and a few common names such
   as "www" or "mail", guessing zone content and proving completeness is
   also trivial when using NSEC3.  In these cases, the use of NSEC is
   preferred to ease the work required by signers and validating
   resolvers.

   For large zones where there is an implication of "not readily
   available" names, such as those where one has to sign a
   non-disclosure agreement before obtaining it, NSEC3 is preferred.
   The second reason to consider NSEC3 is "Opt-Out", which can reduce
   the number of NSEC3 records required.  This is discussed further
   below (Section 5.3.4).

Top      Up      ToC       Page 53 
5.3.  NSEC3 Parameters

   NSEC3 is controlled by a number of parameters, some of which can be
   varied: This section discusses the choice of those parameters.

5.3.1.  NSEC3 Algorithm

   The NSEC3 hashing algorithm is performed on the Fully Qualified
   Domain Name (FQDN) in its uncompressed form.  This ensures that brute
   force work done by an attacker for one FQDN cannot be reused for
   another FQDN attack, as these entries are by definition unique.

   At the time of this writing, there is only one NSEC3 hash algorithm
   defined.  [RFC5155] specifically states: "When specifying a new hash
   algorithm for use with NSEC3, a transition mechanism MUST also be
   defined".  Therefore, this document does not consider NSEC3 hash
   algorithm transition.

5.3.2.  NSEC3 Iterations

   One of the concerns with NSEC3 is that a pre-calculated dictionary
   attack could be performed in order to assess whether or not certain
   domain names exist within a zone.  Two mechanisms are introduced in
   the NSEC3 specification to increase the costs of such dictionary
   attacks: iterations and salt.

   The iterations parameter defines the number of additional times the
   hash function has been performed.  A higher value results in greater
   resiliency against dictionary attacks, at a higher computational cost
   for both the server and resolver.

   RFC 5155 Section 10.3 [RFC5155] considers the tradeoffs between
   incurring cost during the signing process and imposing costs to the
   validating name server, while still providing a reasonable barrier
   against dictionary attacks.  It provides useful limits of iterations
   for a given RSA key size.  These are 150 iterations for 1024-bit
   keys, 500 iterations for 2048-bit keys, and 2,500 iterations for
   4096-bit keys.  Choosing a value of 100 iterations is deemed to be a
   sufficiently costly, yet not excessive, value: In the worst-case
   scenario, the performance of name servers would be halved, regardless
   of key size [NSEC3-HASH-PERF].

Top      Up      ToC       Page 54 
5.3.3.  NSEC3 Salt

   While the NSEC3 iterations parameter increases the cost of hashing a
   dictionary word, the NSEC3 salt reduces the lifetime for which that
   calculated hash can be used.  A change of the salt value by the zone
   administrator would cause an attacker to lose all pre-calculated work
   for that zone.

   There must be a complete NSEC3 chain using the same salt value, that
   matches the salt value in the NSEC3PARAM record.  NSEC3 salt changes
   do not need special rollover procedures.  Since changing the salt
   requires that all the NSEC3 records be regenerated and thus requires
   generating new RRSIGs over these NSEC3 records, it makes sense to
   align the change of the salt with a change of the Zone Signing Key,
   as that process in itself already usually requires that all RRSIGs be
   regenerated.  If there is no critical dependency on incremental
   signing and the zone can be signed with little effort, there is no
   need for such alignment.

5.3.4.  Opt-Out

   The Opt-Out mechanism was introduced to allow for a gradual
   introduction of signed records in zones that contain mostly
   delegation records.  The use of the Opt-Out flag changes the meaning
   of the NSEC3 span from authoritative denial of the existence of names
   within the span to proof that DNSSEC is not available for the
   delegations within the span.  This allows for the addition or removal
   of the delegations covered by the span without recalculating or
   re-signing RRs in the NSEC3 RR chain.

   Opt-Out is specified to be used only over delegation points and will
   therefore only bring relief to zones with a large number of insecure
   delegations.  This consideration typically holds for large TLDs and
   similar zones; in most other circumstances, Opt-Out should not be
   deployed.  Further considerations can be found in Section 12.2 of
   RFC 5155 [RFC5155].



(page 54 continued on part 4)

Next RFC Part