rfc3130.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 3130              DNSSEC Status Meeting Report             June 2001


   associated with the project) are the use of split keys, self-signed
   zone (keys), and multiple signing algorithms.  A goal is the
   establishment of signed infrastructure zones, facilitating the
   creation of a distributed CA for activities like IPSEC and FreeSwan.

3.0 Taxonomy of efforts and What is missing

   The efforts being undertaken appear to cover a broad range of work
   areas, from large domain registries to domain name consumers.  Work
   has been progressing in the production of zones (signing, key
   management), and is starting in the use (resolver) of DNSSEC secured
   data.

   From the discussion, there were no apparent areas lacking attention.
   Additional input in some areas is needed however, particularly in
   making use (applications and IT department) of DNSSEC.

4.0 Questions facing DNSSEC

   By the 49th IETF meeting, the most pressing question on DNSSEC is "is
   it deployable?"  From just the emphasis placed on this question, the
   meeting generated a list of questions and made sure that either the
   answer was known, or work was being done to address the question.

4.1 Is it deployable?  When?

   The usual answer to this has been "not now."  When is always off into
   the future - "about a year."  To get to a deployable point, a series
   of workshops have been held since the spring of 1999.

   At this point, it is becoming clearer that longer term workshops are
   needed.  In going through the motions of any workshop, the number of
   issues raised that impact the protocol's specification is
   diminishing, as well as implementation issues.  As such, one or two
   day workshops have been helping less and less in reaching deployment.

   What is needed is to run longer term test configurations, possibly
   workshops that are help in conjunction with other events and that
   assume continuity.  This will allow a better assessment of the issues
   that involve the passage of time - expirations on key validations,
   etc.

   As was noted in section 1.1, and touched on in section 2, one
   component of DNSSEC, TSIG, is more advanced that the others.  Use of
   TSIG to protect zone transfers is already matured to the "really good
   idea to do stage" even if other elements of DNSSEC are not.  Using
   TSIG to protect traffic between local resolver and their "default"
   recursive name server still needs more work, however.



Lewis                        Informational                      [Page 6]

RFC 3130              DNSSEC Status Meeting Report             June 2001


4.2 Does DNSSEC work?  Is it the right approach?

   Currently there is a lot of effort into making the specification as
   proposed work.  There is some effort in assessing the specification
   at this point, particularly the value of the NXT records and possible
   replacements of it.

   There seems little question on value of the KEY and SIG records.
   There is some research still needed on KEY validation across zone
   boundaries.  Such work is at least scheduled.

4.3 How will client software make use of DNSSEC?

   There are a number of efforts to take existing applications and have
   them make direct use of DNSSEC to carry out their functions.  One
   such example is secure shell.

   When or whether DNSSEC will be understood in the (using POSIX-like
   terms) operating systems "gethostbyname" and similar routines has not
   been addressed.

4.4 What are the remaining issues?

   There are still a few protocol issues.  The NXT resource record is
   designed to provide a means to authentically deny data exists.  The
   problem is that the solution proposed may be worse than the problem,
   in the eyes of some.  There is an alternative proposal, the NO
   resource record, under consideration in the DNSEXT working group.  At
   the present time, the DNSEXT working is considering the following
   question: Is there a need to authentically deny existence of data, if
   so, which is better, NXT (being incumbent) or NO?

   Another less defined issue is the mechanism for parent validation of
   children signatures.  Although the protocol elements of this are
   becoming settled, the operational considerations are not, as
   evidenced by work mentioned in section 2.  DNSSEC interactions have
   also been referenced in discussions over a standard registry-
   registrar protocol.

5.0 Progressing to Draft Standard

   The IETF goal for DNSSEC is to progress the documents through the
   standards track [RFC 2026].  Currently, RFC 2535 is the second
   iteration at the Proposed standard level.  There is a need to cycle
   through Proposed once more.  Following this, the next goal is Draft.






Lewis                        Informational                      [Page 7]

RFC 3130              DNSSEC Status Meeting Report             June 2001


   To pass to the Draft Standard level, two main requirements must be
   met.  There must be two or more interoperable implementations.  There
   must also be sufficient successful operational experience.

5.1 Revision of RFC 2535 via DNSEXT

   DNSEXT will soon begin a rewrite of the RFC 2535 specification (and
   its support documents), rolling in updates and clarifications based
   upon implementation and testing experience.

5.2 Operations document(s) via DNSOP

   DNSOP will continue to be the forum for operations documents based
   upon DNSSEC activity.  There is a need for the community to provide
   more documents to this group.

5.3 Interoperability

   Demonstrating interoperability of DNSSEC, meaning the interaction of
   two different implementations when performing DNSSEC work, poses an
   issue because, to date, only BIND is seriously being fitted with
   DNSSEC.  There are other partial implementations of DNSSEC
   functionality, so the potential for partial interoperability
   demonstrations may exist.

   During the meeting, it was realized that given goals stated, a second
   DNSSEC implementation is needed in 18 months.  Various folks in the
   room mentioned that they would begin see what could be done about
   this.

6.0 Acknowledgements

   The following people attended the meeting and/or provided text for
   this report (in no particular order): Mark Kosters (Network
   Solutions), Patrik Faltstrom (Cisco), Ted Lindgreen and Miek Gieben
   (NLnet Labs), Jaap Akerhuis (SIDN), Olaf Kolkmann (RIPE NCC), Bill
   Manning and Dan Massey (ISI), Martin Fredriksson, Hakan Olsson and
   Jakob Schlyter (Carlstedt Research & Technology), Doug Montgomery and
   Scott Rose (NIST), Johan Ihren and Lars-Johan Liman (Autonomica),
   Brian Wellington (Nominum), Kevin Meynell (CENTR), Ed Lewis and
   Olafur Gudmundsson (NAI Labs).

7.0 IANA Considerations

   This document does not involve assigned numbers in any way.






Lewis                        Informational                      [Page 8]

RFC 3130              DNSSEC Status Meeting Report             June 2001


8.0 Security Considerations

   This document, although a discussion of security enhancements to the
   DNS, does not itself impact security.  Where security issues arise,
   they will be discussed in the Security Considerations of the
   appropriate document.

9.0 References

   The text of any RFC may be retrieved by a web browser by requesting
   the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is
   the number of the RFC.

   [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

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

   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
              March 1999.

   [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
              the Domain Name System", March 1999.

   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", May 2000.

   [RFC 3007] Wellington, B., "Secure Domain Name System Dynamic
              Update", November 2000.

   [RFC 3008] Wellington, B., "Domain Name System Security Signing
              Authority", November 2000.

10.0 Editor's Address

   Edward Lewis
   3060 Washington Rd (Rte 97)
   Glenwood, MD 21738

   Phone: [phone]
   EMail: [e-mail]








Lewis                        Informational                      [Page 9]

RFC 3130              DNSSEC Status Meeting Report             June 2001


11.0 Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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 assigns.

   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
   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.



















Lewis                        Informational                     [Page 10]