draft-ietf-dnsext-nsec3-02.txt

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

Network Working Group                                          B. Laurie
Internet-Draft                                                 G. Sisson
Expires: December 3, 2005                                        Nominet
                                                               R. Arends
                                                    Telematica Instituut
                                                               june 2005


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

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 December 3, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
   used to provide authenticated denial of existence of DNS ownernames
   and types; however, it permits any user to traverse a zone and obtain
   a listing of all ownernames.

   A complete zone file can be used either directly as a source of



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


   probable e-mail addresses for spam, or indirectly as a key for
   multiple WHOIS queries to reveal registrant data which many
   registries (particularly in Europe) may be under strict legal
   obligations to protect.  Many registries therefore prohibit copying
   of their zone file; however the use of NSEC RRs renders policies
   unenforceable.

   This document proposes a scheme which obscures original ownernames
   while permitting authenticated denial of existence of non-existent
   names.  Non-authoritative delegation point NS RR types may be
   excluded.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2   Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
     1.3   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
     2.1   NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  5
       2.1.1   The Authoritative Only Flag Field  . . . . . . . . . .  6
       2.1.2   The Hash Function Field  . . . . . . . . . . . . . . .  6
       2.1.3   The Iterations Field . . . . . . . . . . . . . . . . .  7
       2.1.4   The Salt Length Field  . . . . . . . . . . . . . . . .  7
       2.1.5   The Salt Field . . . . . . . . . . . . . . . . . . . .  7
       2.1.6   The Next Hashed Ownername Field  . . . . . . . . . . .  7
       2.1.7   The list of Type Bit Map(s) Field  . . . . . . . . . .  8
     2.2   The NSEC3 RR Presentation Format . . . . . . . . . . . . .  9
   3.  Creating Additional NSEC3 RRs for Empty Non Terminals  . . . .  9
   4.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 10
   5.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 10
   6.  Special Considerations . . . . . . . . . . . . . . . . . . . . 11
     6.1   Delegation Points  . . . . . . . . . . . . . . . . . . . . 11
       6.1.1   Unsigned Delegations . . . . . . . . . . . . . . . . . 11
     6.2   Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
     6.3   Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.4   Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
       6.4.1   Avoiding Hash Collisions during generation . . . . . . 14
       6.4.2   Second Preimage Requirement Analysis . . . . . . . . . 14
       6.4.3   Possible Hash Value Truncation Method  . . . . . . . . 14
   7.  Performance Considerations . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2  Informative References . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
   A.  Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18



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


   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 23
     B.1   answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       B.1.1   Authenticating the Example DNSKEY RRset  . . . . . . . 25
     B.2   Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
     B.3   No Data Error  . . . . . . . . . . . . . . . . . . . . . . 28
       B.3.1   No Data Error, Empty Non-Terminal  . . . . . . . . . . 29
     B.4   Referral to Signed Zone  . . . . . . . . . . . . . . . . . 30
     B.5   Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
     B.6   Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
     B.7   Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
     B.8   DS Child Zone No Data Error  . . . . . . . . . . . . . . . 35
       Intellectual Property and Copyright Statements . . . . . . . . 37







































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


1.  Introduction

   The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
   Record (RR) for authenticated denial of existence.  This document
   introduces a new RR as an alternative to NSEC that provides measures
   against zone traversal and allows for gradual expansion of
   delegation-centric zones.

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.

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

   In the past, solutions 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)
   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 concepts
   described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
   that update them:  RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
   [RFC2308].

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

1.3  Terminology

   In this document the term "original ownername" refers to a standard
   ownername.  Because this proposal uses the result of a hash function



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


   over the original (unmodified) ownername, this result is referred to
   as "hashed ownername".

   "Canonical ordering of the zone" means the order in which hashed
   ownernames are arranged according to their numerical value, treating
   the leftmost (lowest numbered) byte as the most significant byte.

2.  The NSEC3 Resource Record

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

   The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
   original ownername.  It includes the next hashed ownername in the
   canonical ordering 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 [RFC4035].  Unsigned delegation
   point NS RRsets can optionally be excluded.  To provide protection
   against zone traversal, 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 ownername for the NSEC3 RR is the base32 encoding of the hashed
   ownername.

   The type value for the NSEC3 RR is XX.

   The NSEC3 RR RDATA format is class independent.

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

2.1  NSEC3 RDATA Wire Format

   The RDATA of the NSEC3 RR is as shown below:












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


                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|Hash Function|                  Iterations                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Salt Length  |                     Salt                      /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                     Next Hashed Ownername                     /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                         Type Bit Maps                         /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.1.1  The Authoritative Only Flag Field

   The Authoritative Only Flag field indicates whether the Type Bit Maps
   include delegation point NS record types.

   If the flag is set to 1, the NS RR type bit for a delegation point
   ownername SHOULD be clear when the NSEC3 RR is generated.  The NS RR
   type bit MUST be ignored during processing of the NSEC3 RR.  The NS
   RR type bit has no meaning in this context (it is not authoritative),
   hence the NSEC3 does not contest the existence of a NS RRset for this
   ownername.  When a delegation is not secured, there exist no DS RR
   type nor any other authoritative types for this delegation, hence the
   unsecured delegation has no NSEC3 record associated.  Please see the
   Special Consideration section for implications for unsigned
   delegations.

   If the flag is set to 0, the NS RR type bit for a delegation point
   ownername MUST be set if the NSEC3 covers a delegation, even though
   the NS RR itself is not authoritative.  This implies that all
   delegations, signed or unsigned, have an NSEC3 record associated.
   This behaviour is identical to NSEC behaviour.

2.1.2  The Hash Function Field

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

   This document defines Value 1 for SHA-1 and Value 127 for
   experimental.  All other values are reserved.

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