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

bind-3.2.

Arends, et al.          Expires August 28, 2003                [Page 18]

Internet-Draft               DNSSEC Opt-In                 February 2003


Informative References

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

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

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

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

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

   [10]  Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
         System", draft-ietf-dnsext-dns-threats-02 (work in progress),
         November 2002.


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









Arends, et al.          Expires August 28, 2003                [Page 19]

Internet-Draft               DNSSEC Opt-In                 February 2003


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

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










































Arends, et al.          Expires August 28, 2003                [Page 20]

Internet-Draft               DNSSEC Opt-In                 February 2003


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 NXT 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 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 2535 [2].

      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 [9] 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:



Arends, et al.          Expires August 28, 2003                [Page 21]

Internet-Draft               DNSSEC Opt-In                 February 2003


          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 August 28, 2003                [Page 22]

Internet-Draft               DNSSEC Opt-In                 February 2003


Appendix B. Changes from Prior Versions

   Changes from version 04:

      Added definitions for "signed name" and "unsigned name".

      Added text to make it clear that insecure delegations may have
      Opt-In NXT records of the same name.  Updated the example to have
      one of these.

      Changed Server-side requirements from MUST NOT to SHOULD NOT and
      added some basic description of what action to take in the face of
      violating the delegation-only restriction.

      Relaxed requirement that servers drop negative wildcard proof from
      MUST to MAY, reiterated the client requirement.

      Added section on Dynamic Update declaring it to be undefined wrt
      Opt-In.

      Essentially rewrote the "Security Considerations" section. It does
      not actually say anything different, but hopefully it says it in a
      clearer fashion.

      Split references into Normative and Informative.

      Fixed the example zone and responses to match Delegation Signer.

   Changes from version 03:

      Editorial changes for clarification only.

   Changes from version 02:

      Added text on changes to validation process, use of the AD bit,
      and interactions with wildcards.  Added wildcard caveats to the
      "Security Considerations" section.  Added "Transition Issues"
      section.

   Changes from version 01:

      Changed to "delegation only". Strengthened "Security
      Considerations" section. Added "Server Considerations" and "Client
      Considerations" sections.  Added AD bit requirement.

   Changes from version 00:

      Complete rewrite, altering approach from "views" to tagged NXT



Arends, et al.          Expires August 28, 2003                [Page 23]

Internet-Draft               DNSSEC Opt-In                 February 2003


      records


















































Arends, et al.          Expires August 28, 2003                [Page 24]

Internet-Draft               DNSSEC Opt-In                 February 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Arends, et al.          Expires August 28, 2003                [Page 25]

Internet-Draft               DNSSEC Opt-In                 February 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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











































Arends, et al.          Expires August 28, 2003                [Page 26]