draft-ietf-dnsext-nsec3-02.txt

bind 源码 最新实现 linux/unix/windows平台

Laurie, et al.          Expires December 3, 2005                [Page 6]

Internet-Draft                    nsec3                        june 2005


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

2.1.4  The Salt Length Field

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

2.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 prepended to the original ownername before hashing
   in order to defend against precalculated dictionary attacks.

   The salt is also prepended during iterations of the hash function.

   Note that although it is theoretically possible to cover the entire
   possible ownername space with different salt values, it is
   computationally infeasible to do so, and so there MUST be at least
   one salt which is the same for all NSEC3 records.  This means that no
   matter what name is asked for in a query, it is guaranteed to be
   possible to find a covering NSEC3 record.  Note that this does not
   preclude the use of two different salts at the same time - indeed
   this may well occur naturally, due to rolling the salt value
   periodically.

   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.

2.1.6  The Next Hashed Ownername Field

   The Next Hashed Ownername field contains the hash of the ownername of
   the next RR in the canonical ordering of the hashed ownernames of the
   zone.  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 canonical order.

   Hashed ownernames of RRsets not authoritative for the given zone
   (such as glue records) MUST NOT be listed in the Next Hashed
   Ownername unless at least one authoritative RRset exists at the same
   ownername.




Laurie, et al.          Expires December 3, 2005                [Page 7]

Internet-Draft                    nsec3                        june 2005


   Note that the Next Hashed Ownername field is not encoded, unlike the
   NSEC3 RR's ownername.  It is the unmodified binary hash value.

2.1.7  The list of Type Bit Map(s) Field

   The Type Bit Maps field identifies the RRset types which exist at the
   NSEC3 RR's 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 ) +

   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.

   The RR type 2 (NS) is authoritative at the apex of a zone and is not
   authoritative at delegation points.  If the Authoritative Only Flag
   is set to 1, the delegation point NS RR type MUST NOT be included in
   the type bit maps.  If the Authoritative Only Flag is set to 0, the
   NS RR type at a delegation point MUST be included in the type bit
   maps.

   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
   [RFC2929] (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



Laurie, et al.          Expires December 3, 2005                [Page 8]

Internet-Draft                    nsec3                        june 2005


   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.

2.2  The NSEC3 RR Presentation Format

   The presentation format of the RDATA portion is as follows:

   The Authoritative Only Field is represented as an unsigned decimal
   integer.  The value are either 0 or 1.

   The Hash field is presented as the name 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 00 when the Salt Length field has
   value 0.

   The Next Hashed Ownername field is represented as a sequence of case-
   insensitive base32 digits.  Whitespace is allowed within the
   sequence.

   The List of Type Bit Map(s) Field is represented as a sequence of RR
   type mnemonics.  When the mnemonic is not known, the TYPE
   representation as described in RFC 3597 [RFC3597] (section 5) MUST be
   used.

3.  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 synthesized which cover every existing
   intermediate label level.  Additional NSEC3 RRs are identical in
   format to NSEC3 RRs that cover existing RRs in the zone.  The
   difference is that the type-bit-maps only indicate the existence of



Laurie, et al.          Expires December 3, 2005                [Page 9]

Internet-Draft                    nsec3                        june 2005


   an NSEC3 RR type and an RRSIG RR type.

4.  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);

5.  Including NSEC3 RRs in a Zone

   Each owner name in the zone which has authoritative data or a secured
   delegation point NS RRset MUST have an NSEC3 resource record.

   An unsecured delegation point NS RRset MAY have an NSEC3 resource
   record.  This is different from NSEC records where an unsecured
   delegation point NS RRset MUST have an NSEC record.

   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
   value field in the zone SOA RR.

   The type bitmap of every NSEC3 resource record in a signed zone MUST
   indicate the presence of both the NSEC3 RR type itself and its
   corresponding RRSIG RR type.

   The bitmap for the NSEC3 RR at a delegation point requires special
   attention.  Bits corresponding to the delegation NS RRset and any
   RRsets for which the parent zone has authoritative data MUST be set;
   bits corresponding to any non-NS RRset for which the parent is not
   authoritative MUST be clear.

   The following steps describe the proper construction of NSEC3



Laurie, et al.          Expires December 3, 2005               [Page 10]

Internet-Draft                    nsec3                        june 2005


   records.
   1.  For each unique original owner name in the zone, add an NSEC3
       RRset.  This includes NSEC3 RRsets for unsigned delegation point
       NS RRsets, unless the policy is to have Authoritative Only NSEC3
       RRsets.  The ownername of the NSEC3 RR is the hashed equivalent
       of the original owner name, prepended to the zone name.
   2.  For each RRset at the original owner, set the corresponding bit
       in the type bit map.
   3.  If the difference in number of labels between the apex and the
       original ownername is greater then 1, additional NSEC3s need to
       be added for every empty non-terminal between the apex and the
       original ownername.
   4.  Sort the set of NSEC3 RRs.
   5.  In each NSEC3 RR, insert the Next Hashed Ownername.  The Next
       Hashed Ownername of the last NSEC3 in the zone contains the value
       of the hashed ownername of the first NSEC3 in the zone.
   6.  If the policy is to have authoritative only, set the
       Authoritative Only bit in those NSEC3 RRs that cover unsecured
       delegation points.

6.  Special Considerations

   The following paragraphs clarify specific behaviour explain special
   considerations for implementations.

6.1  Delegation Points

   This proposal introduces the Authoritative Only Flag which indicates
   whether non authoritative delegation point NS records are included in
   the type bit Maps.  As discussed in paragraph 2.1.1, a flag value of
   0 indicates that the interpretation of the type bit maps is identical
   to NSEC records.

   The following subsections describe behaviour when the flag value is
   1.

6.1.1  Unsigned Delegations

   Delegation point NS records are not authoritative.  They are
   authoritative in the delegated zone.  No other data exists at the
   ownername of an unsigned delegation point.

   Since no authoritative data exist at this ownername, it is excluded
   from the NSEC3 chain.  This is an optimization, since it relieves the
   zone of including an NSEC3 record and its associated signature for
   this name.

   An NSEC3 that denies existence of ownernames between X and X' with



Laurie, et al.          Expires December 3, 2005               [Page 11]

Internet-Draft                    nsec3                        june 2005


   the Authoritative Only Flag set to 1 can not be used to prove the
   presence or the absence of delegation point NS records for unsigned
   delegations in the interval (X, X').  The Authoritative Only Flag
   effectively states No Contest on the presence of delegation point NS
   resource records.

   Since proof is absent, there exists a new attack vector.  Unsigned
   delegation point NS records can be deleted during a man in the middle
   attack, effectively denying existence of the delegation.  This is a
   form of Denial of Service, where the victim has no information it is
   under attack, since all signatures are valid and the fabricated
   response form is a known type of response.

   The only possible mitigation is to either not use this method, hence
   proving existence or absence of unsigned delegations, or to sign all
   delegations, regardless of whether the delegated zone is signed or
   not.

   A second attack vector exists in that an adversary is able to
   successfully fabricate an (unsigned) response claiming a nonexistent
   delegation exists.

   The only possible mitigation is to mandate the signing of all
   delegations.

6.2  Proving Nonexistence

   If a wildcard resource record appears in a zone, its asterisk label
   is treated as a literal symbol and is treated in the same way as any
   other ownername for purposes of generating NSEC3 RRs.  RFC 4035
   [RFC4035] describes the impact of wildcards on authenticated denial
   of existence.

   In order to prove there exist no RRs for a domain, as well as no
   source of synthesis, an RR must be shown for the closest encloser,
   and non-existence must be shown for all closer labels and for the
   wildcard at the closest encloser.

   This can be done as follows.  If the QNAME in the query is
   omega.alfa.beta.example, and the closest encloser is beta.example
   (the nearest ancestor to omega.alfa.beta.example), then the server
   should return an NSEC3 that demonstrates the nonexistence of
   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
   *.beta.example, and an NSEC3 that demonstrates the existence of
   beta.example.  This takes between one and three NSEC3 records, since