draft-ietf-dnsext-nsec3-04.txt

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

Network Working Group                                          B. Laurie
Internet-Draft                                                 G. Sisson
Expires: August 5, 2006                                        R. Arends
                                                                 Nominet
                                                           February 2006


             DNSSEC Hash Authenticated Denial of Existence
                       draft-ietf-dnsext-nsec3-04

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The DNS Security Extensions introduces the NSEC resource record for
   authenticated denial of existence.  This document introduces a new
   resource record as an alternative to NSEC that provides measures
   against zone enumeration and allows for gradual expansion of
   delegation-centric zones.





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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36



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


     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
   Intellectual Property and Copyright Statements . . . . . . . . . . 42















































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


1.  Introduction

1.1.  Rationale

   The DNS Security Extensions included the NSEC RR to provide
   authenticated denial of existence.  Though the NSEC RR meets the
   requirements for authenticated denial of existence, it introduced a
   side-effect in that the contents of a zone can be enumerated.  This
   property introduces undesired policy issues.

   An enumerated zone can be used either directly as a source of
   probable e-mail addresses for spam, or indirectly as a key for
   multiple WHOIS queries to reveal registrant data which many
   registries may be under strict legal obligations to protect.  Many
   registries therefore prohibit copying of their zone file; however the
   use of NSEC RRs renders these policies unenforceable.

   A second problem was the requirement that the existence of all record
   types in a zone - including unsigned delegation points - must be
   accounted for, despite the fact that unsigned delegation point
   records are not signed.  This requirement has a side-effect that the
   overhead of signed zones is not related to the increase in security
   of subzones.  This requirement does not allow the zones' size to grow
   in relation to the growth of signed subzones.

   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
   proposed as a measure against these side effects but at the time were
   regarded as secondary over the need to have a stable DNSSEC
   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
   transition path to future enhancements is introduced, while current
   DNSSEC deployment can continue.  This document presents the NSEC3
   Resource Record which mitigates these issues with the NSEC RR.

   The reader is assumed to be familiar with the basic DNS and DNSSEC
   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
   [6], RFC2181 [7] and RFC2308 [8].

1.2.  Reserved Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [9].

1.3.  Terminology

   The practice of discovering the contents of a zone, i.e. enumerating
   the domains within a zone, is known as "zone enumeration".  Zone



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


   enumeration was not practical prior to the introduction of DNSSEC.

   In this document the term "original ownername" refers to a standard
   ownername.  Because this proposal uses the result of a hash function
   over the original (unmodified) ownername, this result is referred to
   as "hashed ownername".

   "Hash order" means the order in which hashed ownernames are arranged
   according to their numerical value, treating the leftmost (lowest
   numbered) octet as the most significant octet.  Note that this is the
   same as the canonical ordering specified in RFC 4034 [4].

   An "empty non-terminal" is a domain name that owns no resource
   records but has subdomains that do.

   The "closest encloser" of a (nonexistent) domain name is the longest
   domain name, including empty non-terminals, that matches the
   rightmost part of the nonexistent domain name.

   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
   specified in RFC 3548bis [15].


2.  NSEC versus NSEC3

   This document does NOT obsolete the NSEC record, but gives an
   alternative for authenticated denial of existence.  NSEC and NSEC3
   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
   a signaling mechanism to allow for graceful transition towards NSEC3.


3.  The NSEC3 Resource Record

   The NSEC3 RR provides Authenticated Denial of Existence for DNS
   Resource Record Sets.

   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
   RR's original ownername.  It includes the next hashed ownername in
   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
   indicates which RRsets exist for the original ownername of the RRset
   and form a chain of hashed ownernames in the zone.  This information
   is used to provide authenticated denial of existence for DNS data, as
   described in RFC 4035 [5].  To provide protection against zone
   enumeration, the ownernames used in the NSEC3 RR are cryptographic
   hashes of the original ownername prepended to the name of the zone.
   The NSEC3 RR indicates which hash function is used to construct the
   hash, which salt is used, and how many iterations of the hash
   function are performed over the original ownername.  The hashing



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


   technique is described fully in Section 5.

   Hashed ownernames of unsigned delegations may be excluded from the
   chain.  An NSEC3 record which span covers the hash of an unsigned
   delegation's ownername is referred to as an Opt-In NSEC3 record and
   is indicated by the presence of a flag.

   The ownername for the NSEC3 RR is the base32 encoding of the hashed
   ownername prepended to the name of the zone..

   The type value for the NSEC3 RR is XX.

   The NSEC3 RR RDATA format is class independent and is described
   below.

   The class MUST be the same as the original ownername's class.

   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
   field.  This is in the spirit of negative caching [8].

3.1.  NSEC3 RDATA Wire Format

   The RDATA of the NSEC3 RR is as shown below:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Hash Function |O|                Iterations                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Salt Length  |                     Salt                      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+