draft-ietf-dnsext-nsec3-04.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 1,567 行 · 第 1/5 页

   /                     Next Hashed Ownername                     /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                         Type Bit Maps                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   "O" is the Opt-In Flag field.

3.1.1.  The Hash Function Field

   The Hash Function field identifies the cryptographic hash function
   used to construct the hash-value.

   The values are as defined for the DS record (see RFC 3658 [10]).

   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
   function value.




Laurie, et al.           Expires August 5, 2006                 [Page 6]

Internet-Draft                    nsec3                    February 2006


3.1.2.  The Opt-In Flag Field

   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
   delegations.

   In DNSSEC, NS RRsets at delegation points are not signed, and may be
   accompanied by a DS record.  The security status of the subzone is
   determined by the presence or absence of the DS RRset,
   cryptographically proven by the NSEC record or the signed DS RRset.
   The presence of the Opt-In flag expands this definition by allowing
   insecure delegations to exist within an otherwise signed zone without
   the corresponding NSEC3 record at the delegation's (hashed) owner
   name.  These delegations are proven insecure by using a covering
   NSEC3 record.

   Resolvers must be able to distinguish between NSEC3 records and
   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
   flag of the NSEC3 records that cover (or potentially cover) insecure
   delegation nodes.

   An Opt-In NSEC3 record does not assert the existence or non-existence
   of the insecure delegations that it covers.  This allows for the
   addition or removal of these delegations without recalculating or
   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
   do assert the (non)existence of other, authoritative RRsets.

   An Opt-In NSEC3 record MAY have the same original owner name as an
   insecure delegation.  In this case, the delegation is proven insecure
   by the lack of a DS bit in type map and the signed NSEC3 record does
   assert the existence of the delegation.

   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
   MUST NOT be any hashed ownernames of insecure delegations (nor any
   other records) between it and the RRsets indicated by the 'Next
   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
   only be hashed ownernames of insecure delegations between it and the
   next node indicated by the 'Next Hashed Ownername' in the NSEC3
   RDATA.

   In summary,
   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
      of 1.
   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
      value of 0.
   and,





Laurie, et al.           Expires August 5, 2006                 [Page 7]

Internet-Draft                    nsec3                    February 2006


   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
      ownername between its ownername and next hashed ownername,
      although it does assert that any hashed name in this span MUST be
      of an insecure delegation.
   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
      with the same hashed owner name.

3.1.3.  The Iterations Field

   The Iterations field defines the number of times the hash has been
   iterated.  More iterations results in greater resiliency of the hash
   value against dictionary attacks, but at a higher cost for both the
   server and resolver.  See Section 5 for details of this field's use.

   Iterations make an attack more costly by making the hash computation
   more computationally intensive, e.g. by iterating the hash function a
   number of times.

   When generating a few hashes this performance loss will not be a
   problem, as a validator can handle a delay of a few milliseconds.
   But when doing a dictionary attack it will also multiply the attack
   workload by a factor, which is a problem for the attacker.

3.1.4.  The Salt Length Field

   The salt length field defines the length of the salt in octets.

3.1.5.  The Salt Field

   The Salt field is not present when the Salt Length Field has a value
   of 0.

   The Salt field is appended to the original ownername before hashing
   in order to defend against precalculated dictionary attacks.  See
   Section 5 for details on how the salt is used.

   Salt is used to make dictionary attacks using precomputation more
   costly.  A dictionary can only be computed after the attacker has the
   salt, hence a new salt means that the dictionary has to be
   regenerated with the new salt.

   There MUST be a complete set of NSEC3 records covering the entire
   zone that use the same salt value.  The requirement exists so that,
   given any qname within a zone, at least one covering NSEC3 RRset may
   be found.  While it may be theoretically possible to produce a set of
   NSEC3s that use different salts that cover the entire zone, it is
   computationally infeasible to generate such a set.  See Section 8.2
   for further discussion.



Laurie, et al.           Expires August 5, 2006                 [Page 8]

Internet-Draft                    nsec3                    February 2006


   The salt value SHOULD be changed from time to time - this is to
   prevent the use of a precomputed dictionary to reduce the cost of
   enumeration.

3.1.6.  The Next Hashed Ownername Field

   The Next Hashed Ownername field contains the next hashed ownername in
   hash order.  That is, given the set of all hashed owernames, the Next
   Hashed Ownername contains the hash value that immediately follows the
   owner hash value for the given NSEC3 record.  The value of the Next
   Hashed Ownername Field in the last NSEC3 record in the zone is the
   same as the ownername of the first NSEC3 RR in the zone in hash
   order.

   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
   Hashed Ownername unless at least one authoritative RRset exists at
   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
   be listed if the Opt-In bit is clear.

   Note that the Next Hashed Ownername field is not encoded, unlike the
   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
   does not include the name of the containing zone.

   The length of this field is the length of the hash value produced by
   the hash function selected by the Hash Function field.

3.1.7.  The Type Bit Maps Field

   The Type Bit Maps field identifies the RRset types which exist at the
   NSEC3 RR's original ownername.

   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
   generation, and MUST be ignored during processing.

   The RR type space is split into 256 window blocks, each representing
   the low-order 8 bits of the 16-bit RR type space.  Each block that
   has at least one active RR type is encoded using a single octet
   window number (from 0 to 255), a single octet bitmap length (from 1
   to 32) indicating the number of octets used for the window block's
   bitmap, and up to 32 octets (256 bits) of bitmap.

   Blocks are present in the NSEC3 RR RDATA in increasing numerical
   order.

   "|" denotes concatenation

   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +




Laurie, et al.           Expires August 5, 2006                 [Page 9]

Internet-Draft                    nsec3                    February 2006


   Each bitmap encodes the low-order 8 bits of RR types within the
   window block, in network bit order.  The first bit is bit 0.  For
   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
   to RR type 2 (NS), and so forth.  For window block 1, bit 1
   corresponds to RR type 257, bit 2 to RR type 258.  If a bit is set to
   1, it indicates that an RRset of that type is present for the NSEC3
   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
   that type is present for the NSEC3 RR's ownername.

   Since bit 0 in window block 0 refers to the non-existing RR type 0,
   it MUST be set to 0.  After verification, the validator MUST ignore
   the value of bit 0 in window block 0.

   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
   (section 3.1) or within the range reserved for assignment only to
   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
   zone data.  If encountered, they must be ignored upon reading.

   Blocks with no types present MUST NOT be included.  Trailing zero
   octets in the bitmap MUST be omitted.  The length of each block's
   bitmap is determined by the type code with the largest numerical
   value, within that block, among the set of RR types present at the
   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
   be interpreted as zero octets.

3.2.  The NSEC3 RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Opt-In Flag Field is represented as an unsigned decimal integer.
   The value is either 0 or 1.

   The Hash field is presented as a mnemonic of the hash or as an
   unsigned decimal integer.  The value has a maximum of 127.

   The Iterations field is presented as an unsigned decimal integer.

   The Salt Length field is not presented.

   The Salt field is represented as a sequence of case-insensitive
   hexadecimal digits.  Whitespace is not allowed within the sequence.
   The Salt Field is represented as "-" (without the quotes) when the
   Salt Length field has value 0.

   The Next Hashed Ownername field is represented as a sequence of case-
   insensitive base32 digits, without whitespace.

   The Type Bit Maps Field is represented as a sequence of RR type



Laurie, et al.           Expires August 5, 2006                [Page 10]

Internet-Draft                    nsec3                    February 2006


   mnemonics.  When the mnemonic is not known, the TYPE representation
   as described in RFC 3597 [12] (section 5) MUST be used.


4.  Creating Additional NSEC3 RRs for Empty Non-Terminals

   In order to prove the non-existence of a record that might be covered
   by a wildcard, it is necessary to prove the existence of its closest
   encloser.  A closest encloser might be an empty non-terminal.

   Additional NSEC3 RRs are generated for empty non-terminals.  These
   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
   existing RRs in the zone except that their type-maps only indicated
   the existence of an NSEC3 RRset and an RRSIG RRset.

   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
   not appear at names that did not exist before the zone was signed.
   [Comment.1]


5.  Calculation of the Hash

   Define H(x) to be the hash of x using the hash function selected by
   the NSEC3 record and || to indicate concatenation.  Then define:

   IH(salt,x,0)=H(x || salt)

   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0

   Then the calculated hash of an ownername is
   IH(salt,ownername,iterations-1), where the ownername is the canonical
   form.

   The canonical form of the ownername is the wire format of the
   ownername where:
   1.  The ownername is fully expanded (no DNS name compression) and
       fully qualified;
   2.  All uppercase US-ASCII letters are replaced by the corresponding
       lowercase US-ASCII letters;
   3.  If the ownername is a wildcard name, the ownername is in its
       original unexpanded form, including the "*" label (no wildcard
       substitution);
   This form is as defined in section 6.2 of RFC 4034 ([4]).


6.  Including NSEC3 RRs in a Zone

   Each ownername within the zone that owns authoritative RRsets MUST



Laurie, et al.           Expires August 5, 2006                [Page 11]

Internet-Draft                    nsec3                    February 2006


   have a corresponding NSEC3 RR.  Ownernames that correspond to
   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
   set to 1.  Other non-authoritative RRs are not included in the set of
   NSEC3 RRs.

   Each empty non-terminal MUST have an NSEC3 record.

   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL