draft-ietf-dnsext-dnssec-opt-in-07.txt

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

   In particular, this means that a malicious entity may be able to
   insert or delete records with unsigned names.  These records are
   normally NS records, but this also includes signed wildcard
   expansions (while the wildcard record itself is signed, its expanded
   name is an unsigned name).

   For example, if a resolver received the following response from the
   example zone above:







Arends, et al.          Expires January 19, 2006               [Page 11]

Internet-Draft                DNSSEC Opt-In                    July 2005


   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A

         RCODE=NOERROR

         Answer Section:

         Authority Section:
         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
                                        RRSIG DNSKEY
         EXAMPLE.                RRSIG  NSEC ...

         Additional Section:


   The resolver would have no choice but to believe that the referral to
   NS.FORGED. is valid.  If a wildcard existed that would have been
   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
   have undetectably removed it and replaced it with the forged
   delegation.

   Note that being able to add a delegation is functionally equivalent
   to being able to add any record type: an attacker merely has to forge
   a delegation to nameserver under his/her control and place whatever
   records needed at the subzone apex.

   While in particular cases, this issue may not present a significant
   security problem, in general it should not be lightly dismissed.
   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
   In particular, zone signing tools SHOULD NOT default to Opt-In, and
   MAY choose to not support Opt-In at all.

9.  IANA Considerations

   None.

10.  Acknowledgments

   The contributions, suggestions and remarks of the following persons
   (in alphabetic order) to this draft are acknowledged:

      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
      Wellington.

11.  References




Arends, et al.          Expires January 19, 2006               [Page 12]

Internet-Draft                DNSSEC Opt-In                    July 2005


11.1  Normative References

   [1]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
        Authenticated Data (AD) bit", RFC 3655, November 2003.

   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "DNS Security Introduction and Requirements", RFC 4033,
        March 2005.

   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Resource Records for the DNS Security Extensions", RFC 4034,
        March 2005.

   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Protocol Modifications for the DNS Security Extensions",
        RFC 4035, March 2005.

   [6]  Blacka, D., "DNSSEC Experiments",
        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
        July 2005.

11.2  Informative References

   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
         RFC 2137, April 1997.

   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
         Status", RFC 3090, March 2001.

   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
         December 2001.

   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
         System (DNS)", RFC 3833, August 2004.








Arends, et al.          Expires January 19, 2006               [Page 13]

Internet-Draft                DNSSEC Opt-In                    July 2005


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Drienerlolaan 5
   7522 NB  Enschede
   NL

   Email: [e-mail]


   Mark Kosters
   Verisign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

   Phone: [phone]
   Email: [e-mail]
   URI:   http://www.verisignlabs.com


   David Blacka
   Verisign, Inc.
   21355 Ridgetop Circle
   Dulles, VA  20166
   US

   Phone: [phone]
   Email: [e-mail]
   URI:   http://www.verisignlabs.com

Appendix A.  Implementing Opt-In using "Views"

   In many cases, it may be convenient to implement an Opt-In zone by
   combining two separately maintained "views" of a zone at request
   time.  In this context, "view" refers to a particular version of a
   zone, not to any specific DNS implementation feature.

   In this scenario, one view is the secure view, the other is the
   insecure (or legacy) view.  The secure view consists of an entirely
   signed zone using Opt-In tagged NSEC records.  The insecure view
   contains no DNSSEC information.  It is helpful, although not
   necessary, for the secure view to be a subset (minus DNSSEC records)
   of the insecure view.

   In addition, the only RRsets that may solely exist in the insecure
   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and



Arends, et al.          Expires January 19, 2006               [Page 14]

Internet-Draft                DNSSEC Opt-In                    July 2005


   the zone apex NS RRset) MUST be signed and in the secure view.

   These two views may be combined at request time to provide a virtual,
   single Opt-In zone.  The following algorithm is used when responding
   to each query:
      V_A is the secure view as described above.
      V_B is the insecure view as described above.
      R_A is a response generated from V_A, following RFC 2535bis.
      R_B is a response generated from V_B, following DNS resolution as
      per RFC 1035 [1].
      R_C is the response generated by combining R_A with R_B, as
      described below.
      A query is DNSSEC-aware if it either has the DO bit [11] turned
      on, or is for a DNSSEC-specific record type.



   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
       generate and return R_B, otherwise
   2.  Generate R_A.
   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
   4.  Generate R_B and combine it with R_A to form R_C:
          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
          record, if R_B's RCODE = NOERROR.
   5.  Return R_C.

























Arends, et al.          Expires January 19, 2006               [Page 15]

Internet-Draft                DNSSEC Opt-In                    July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Arends, et al.          Expires January 19, 2006               [Page 16]