draft-ietf-dnsext-dnssec-experiments-01.txt

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

5.  Defining an Experiment

   The DNSSEC experiment must define the particular set of (previously
   unknown) algorithms that identify the experiment, and define what
   each unknown algorithm identifier means.  Typically, unless the
   experiment is actually experimenting with a new DNSSEC algorithm,
   this will be a mapping of private algorithm identifiers to existing,
   known algorithms.

   Normally the experiment will choose a DNS name as the algorithm
   identifier base.  This DNS name SHOULD be under the control of the
   authors of the experiment.  Then the experiment will define a mapping
   between known mandatory and optional algorithms into this private
   algorithm identifier space.  Alternately, the experiment MAY use the
   OID private algorithm space instead (using algorithm number 254), or
   may choose non-private algorithm numbers, although this would require
   an IANA allocation (see below (Section 9).)

   For example, an experiment might specify in its description the DNS
   name "dnssec-experiment-a.example.com" as the base name, and provide
   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
   an alias of DNSSEC algorithm 5 (RSASHA1).

   Resolvers MUST then only recognize the experiment's semantics when
   present in a zone signed by one or more of these private algorithms.

   In general, however, resolvers involved in the experiment are
   expected to understand both standard DNSSEC and the defined
   experimental DNSSEC protocol, although this isn't required.





















Blacka                  Expires January 19, 2006                [Page 8]

Internet-Draft             DNSSEC Experiments                  July 2005


6.  Considerations

   There are a number of considerations with using this methodology.

   1.  Under some circumstances, it may be that the experiment will not
       be sufficiently masked by this technique and may cause resolution
       problem for resolvers not aware of the experiment.  For instance,
       the resolver may look at the not validatable response and
       conclude that the response is bogus, either due to local policy
       or implementation details.  This is not expected to be the common
       case, however.

   2.  In general, it will not be possible for DNSSEC-aware resolvers
       not aware of the experiment to build a chain of trust through an
       experimental zone.




































Blacka                  Expires January 19, 2006                [Page 9]

Internet-Draft             DNSSEC Experiments                  July 2005


7.  Transitions

   If an experiment is successful, there may be a desire to move the
   experiment to a standards-track extension.  One way to do so would be
   to move from private algorithm numbers to IANA allocated algorithm
   numbers, with otherwise the same meaning.  This would still leave a
   divide between resolvers that understood the extension versus
   resolvers that did not.  It would, in essence, create an additional
   version of DNSSEC.

   An alternate technique might be to do a typecode rollover, thus
   actually creating a definitive new version of DNSSEC.  There may be
   other transition techniques available, as well.






































Blacka                  Expires January 19, 2006               [Page 10]

Internet-Draft             DNSSEC Experiments                  July 2005


8.  Security Considerations

   Zones using this methodology will be considered insecure by all
   resolvers except those aware of the experiment.  It is not generally
   possible to create a secure delegation from an experimental zone that
   will be followed by resolvers unaware of the experiment.













































Blacka                  Expires January 19, 2006               [Page 11]

Internet-Draft             DNSSEC Experiments                  July 2005


9.  IANA Considerations

   IANA may need to allocate new DNSSEC algorithm numbers if that
   transition approach is taken, or the experiment decides to use
   allocated numbers to begin with.  No IANA action is required to
   deploy an experiment using private algorithm identifiers.













































Blacka                  Expires January 19, 2006               [Page 12]

Internet-Draft             DNSSEC Experiments                  July 2005


10.  References

10.1  Normative References

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

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

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

10.2  Informative References

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

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

   [6]  Weiler, S., "Clarifications and Implementation Notes for
        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
        progress), March 2005.


Author's Address

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

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











Blacka                  Expires January 19, 2006               [Page 13]

Internet-Draft             DNSSEC Experiments                  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.




Blacka                  Expires January 19, 2006               [Page 14]