draft-ietf-dnsext-dnssec-trans-02.txt

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

DNS Extensions Working Group                                   R. Arends
Internet-Draft                                      Telematica Instituut
Expires: August 25, 2005                                         P. Koch
                                                                DENIC eG
                                                             J. Schlyter
                                                                  NIC-SE
                                                       February 21, 2005


                Evaluating DNSSEC Transition Mechanisms
                 draft-ietf-dnsext-dnssec-trans-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document collects and summarizes different proposals for
   alternative and additional strategies for authenticated denial in DNS
   responses, evaluates these proposals and gives a recommendation for a



Arends, et al.           Expires August 25, 2005                [Page 1]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


   way forward.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15

























Arends, et al.           Expires August 25, 2005                [Page 2]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


1.  Introduction

   This report shall document the process of dealing with the NSEC
   walking problem late in the Last Call for
   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
   that took place in the DNSEXT WG during the first half of June 2004
   as well as some additional ideas that came up subsequently.

   This is an edited excerpt of the chairs' mail to the WG:
      The working group consents on not including NSEC-alt in the
      DNSSEC-bis documents.  The working group considers to take up
      "prevention of zone enumeration" as a work item.
      There may be multiple mechanisms to allow for co-existence with
      DNSSEC-bis.  The chairs allow the working group a little over a
      week (up to June 12, 2004) to come to consensus on a possible
      modification to the document to enable gentle rollover.  If that
      consensus cannot be reached the DNSSEC-bis documents will go out
      as-is.

   To ease the process of getting consensus, a summary of the proposed
   solutions and analysis of the pros and cons were written during the
   weekend.

   This summary includes:

      An inventory of the proposed mechanisms to make a transition to
      future work on authenticated denial of existence.
      List the known Pros and Cons, possibly provide new arguments, and
      possible security considerations of these mechanisms.
      Provide a recommendation on a way forward that is least disruptive
      to the DNSSEC-bis specifications as they stand and keep an open
      path to other methods for authenticated denial of existence.

   The descriptions of the proposals in this document are coarse and do
   not cover every detail necessary for implementation.  In any case,
   documentation and further study is needed before implementaion and/or
   deployment, including those which seem to be solely operational in
   nature.

2.  Transition Mechanisms

   In the light of recent discussions and past proposals, we have found
   several ways to allow for transition to future expansion of
   authenticated denial.  We tried to illuminate the paths and pitfalls
   in these ways forward.  Some proposals lead to a versioning of
   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
   proposals are 'clean' but may cause delay, while again others may be



Arends, et al.           Expires August 25, 2005                [Page 3]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


   plain hacks.

   Some paths do not introduce versioning, and might require the current
   DNSSEC-bis documents to be fully updated to allow for extensions to
   authenticated denial mechanisms.  Other paths introduce versioning
   and do not (or minimally) require DNSSEC-bis documents to be updated,
   allowing DNSSEC-bis to be deployed, while future versions can be
   drafted independent from or partially depending on DNSSEC-bis.

2.1  Mechanisms With Need of Updating DNSSEC-bis

   Mechanisms in this category demand updates to the DNSSEC-bis document
   set.

2.1.1  Dynamic NSEC Synthesis

   This proposal assumes that NSEC RRs and the authenticating RRSIG will
   be generated dynamically to just cover the (non existent) query name.
   The owner name is (the) one preceding the name queried for, the Next
   Owner Name Field has the value of the Query Name Field + 1 (first
   successor in canonical ordering).  A separate key (the normal ZSK or
   a separate ZSK per authoritative server) would be used for RRSIGs on
   NSEC RRs.  This is a defense against enumeration, though it has the
   presumption of online signing.

2.1.1.1  Coexistence and Migration

   There is no change in interpretation other then that the next owner
   name might or might not exist.

2.1.1.2  Limitations

   This introduces an unbalanced cost between query and response
   generation due to dynamic generation of signatures.

2.1.1.3  Amendments to DNSSEC-bis

   The current DNSSEC-bis documents might need to be updated to indicate
   that the next owner name might not be an existing name in the zone.
   This is not a real change to the spec since implementers have been
   warned not to synthesize with previously cached NSEC records.  A
   specific bit to identify the dynamic signature generating key might
   be useful as well, to prevent it from being used to fake positive
   data.

2.1.1.4  Cons

   Unbalanced cost is a ground for DDoS.  Though this protects against



Arends, et al.           Expires August 25, 2005                [Page 4]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


   enumeration, it is not really a path for versioning.

2.1.1.5  Pros

   Hardly any amendments to DNSSEC-bis.

2.1.2  Add Versioning/Subtyping to Current NSEC

   This proposal introduces versioning for the NSEC RR type (a.k.a.
   subtyping) by adding a (one octet) version field to the NSEC RDATA.
   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
   making this an 'Must Be Zero' (MBZ) for the to be published docset.

2.1.2.1  Coexistence and Migration

   Since the versioning is done inside the NSEC RR, different versions
   may coexist.  However, depending on future methods, that may or may
   not be useful inside a single zone.  Resolvers cannot ask for
   specific NSEC versions but may be able to indicate version support by
   means of a to be defined EDNS option bit.

2.1.2.2  Limitations

   There are no technical limitations, though it will cause delay to
   allow testing of the (currently unknown) new NSEC interpretation.

   Since the versioning and signaling is done inside the NSEC RR, future
   methods will likely be restricted to a single RR type authenticated
   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
   RR types).

2.1.2.3  Amendments to DNSSEC-bis

   Full Update of the current DNSSEC-bis documents to provide for new
   fields in NSEC, while specifying behavior in case of unknown field
   values.

2.1.2.4  Cons

   Though this is a clean and clear path without versioning DNSSEC, it
   takes some time to design, gain consensus, update the current
   dnssec-bis document, test and implement a new authenticated denial
   record.

2.1.2.5  Pros

   Does not introduce an iteration to DNSSEC while providing a clear and
   clean migration strategy.



Arends, et al.           Expires August 25, 2005                [Page 5]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


2.1.3  Type Bit Map NSEC Indicator

   Bits in the type-bit-map are reused or allocated to signify the
   interpretation of NSEC.

   This proposal assumes that future extensions make use of the existing
   NSEC RDATA syntax, while it may need to change the interpretation of
   the RDATA or introduce an alternative denial mechanism, invoked by
   the specific type-bit-map-bits.

2.1.3.1  Coexistence and migration

   Old and new NSEC meaning could coexist, depending how the signaling
   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
   types are available  as well as those covering meta/query types or
   types to be specifically allocated.

2.1.3.2  Limitations

   This mechanism uses an NSEC field that was not designed for that
   purpose.  Similar methods were discussed during the Opt-In discussion
   and the Silly-State discussion.

2.1.3.3  Amendments to DNSSEC-bis

   The specific type-bit-map-bits must be allocated and they need to be
   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
   interpretation.  Also, behaviour of the resolver and validator must
   be documented in case unknown values are encountered for the MBZ
   field.  Currently the protocol document specifies that the validator
   MUST ignore the setting of the NSEC and the RRSIG bits, while other
   bits are only used for the specific purpose of the type-bit-map field

2.1.3.4  Cons

   The type-bit-map was not designed for this purpose.  It is a
   straightforward hack.  Text in protocol section 5.4 was put in
   specially to defend against this usage.

2.1.3.5  Pros

   No change needed to the on-the-wire protocol as specified in the
   current docset.

2.1.4  New Apex Type

   This introduces a new Apex type (parallel to the zone's SOA)
   indicating the DNSSEC version (or authenticated denial) used in or



Arends, et al.           Expires August 25, 2005                [Page 6]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


   for this zone.

2.1.4.1  Coexistence and Migration

   Depending on the design of this new RR type multiple denial
   mechanisms may coexist in a zone.  Old validators will not understand
   and thus ignore the new type, so interpretation of the new NSEC
   scheme may fail, negative responses may appear 'bogus'.

2.1.4.2  Limitations

   A record of this kind is likely to carry additional
   feature/versioning indications unrelated to the current question of
   authenticated denial.

2.1.4.3  Amendments to DNSSEC-bis

   The current DNSSEC-bis documents need to be updated to indicate that
   the absence of this type indicates dnssec-bis, and that the (mere)
   presence of this type indicated unknown versions.

2.1.4.4  Cons

   The only other 'zone' or 'apex' record is the SOA record.  Though
   this proposal is not new, it is yet unknown how it might fulfill
   authenticated denial extensions.  This new RR type would only provide
   for a generalized signaling mechanism, not the new authenticated
   denial scheme.  Since it is likely to be general in nature, due to
   this generality consensus is not to be reached soon.

2.1.4.5  Pros

   This approach would allow for a lot of other per zone information to
   be transported or signaled to both (slave) servers and resolvers.

2.1.5  NSEC White Lies

   This proposal disables one part of NSEC (the pointer part) by means
   of a special target (root, apex, owner, ...), leaving intact only the
   ability to authenticate denial of existence of RR sets, not denial of
   existence of domain names (NXDOMAIN).  It may be necessary to have
   one working NSEC to prove the absence of a wildcard.

2.1.5.1  Coexistence and Migration

   The NSEC target can be specified per RR, so standard NSEC and 'white
   lie' NSEC can coexist in a zone.  There is no need for migration
   because no versioning is introduced or intended.



Arends, et al.           Expires August 25, 2005                [Page 7]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005


2.1.5.2  Limitations

   This proposal breaks the protocol and is applicable to certain types
   of zones only (no wildcard, no deep names, delegation only).  Most of
   the burden is put on the resolver side and operational consequences
   are yet to be studied.

2.1.5.3  Amendments to DNSSEC-bis

   The current DNSSEC-bis documents need to be updated to indicate that
   the NXDOMAIN responses may be insecure.

2.1.5.4  Cons

   Strictly speaking this breaks the protocol and doesn't fully fulfill
   the requirements for authenticated denial of existence.  Security
   implications need to be carefully documented: search path problems
   (forged denial of existence may lead to wrong expansion of non-FQDNs
   [RFC1535]) and replay attacks to deny existence of records.

2.1.5.5  Pros

   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
   available anyway.

2.1.6  NSEC Optional via DNSSKEY Flag