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

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

   A new DNSKEY may be defined to declare NSEC optional per zone.

2.1.6.1  Coexistence and Migration

   Current resolvers/validators will not understand the Flag bit and
   will have to treat negative responses as bogus.  Otherwise, no
   migration path is needed since NSEC is simply turned off.

2.1.6.2  Limitations

   NSEC can only be made completely optional at the cost of being unable
   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
   to this approach would just disable authenticated denial for
   non-existence of nodes.

2.1.6.3  Amendments to DNSSEC-bis

   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
   be specified in the light of absence of authenticated denial.





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


2.1.6.4  Cons

   Doesn't fully meet requirements.  Operational consequences to be
   studied.

2.1.6.5  Pros

   Official version of the "trick" presented in (8).  Operational
   problems can be addressed during future work on validators.

2.1.7  New Answer Pseudo RR Type

   A new pseudo RR type may be defined that will be dynamically created
   (and signed) by the responding authoritative server.  The RR in the
   response will cover the QNAME, QCLASS and QTYPE and will authenticate
   both denial of existence of name (NXDOMAIN) or RRset.

2.1.7.1  Coexistence and Migration

   Current resolvers/validators will not understand the pseudo RR and
   will thus not be able to process negative responses so testified.  A
   signaling or solicitation method would have to be specified.

2.1.7.2  Limitations

   This method can only be used with online keys and online signing
   capacity.

2.1.7.3  Amendments to DNSSEC-bis

   Signaling method needs to be defined.

2.1.7.4  Cons

   Keys have to be held and processed online with all security
   implications.  An additional flag for those keys identifying them as
   online or negative answer only keys should be considered.

2.1.7.5  Pros

   Expands DNSSEC authentication to the RCODE.

2.1.8  SIG(0) Based Authenticated Denial


2.1.8.1  Coexistence and Migration





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


2.1.8.2  Limitations


2.1.8.3  Amendments to DNSSEC-bis


2.1.8.4  Cons


2.1.8.5  Pros


2.2  Mechanisms Without Need of Updating DNSSEC-bis

2.2.1  Partial Type-code and Signal Rollover

   Carefully crafted type code/signal rollover to define a new
   authenticated denial space that extends/replaces DNSSEC-bis
   authenticated denial space.  This particular path is illuminated by
   Paul Vixie in a Message-Id <[e-mail]>
   posted to <[e-mail]> 2004-06-02.

2.2.1.1  Coexistence and Migration

   To protect the current resolver for future versions, a new DNSSEC-OK
   bit must be allocated to make clear it does or does not understand
   the future version.  Also, a new DS type needs to be allocated to
   allow differentiation between a current signed delegation and a
   'future' signed delegation.  Also, current NSEC needs to be rolled
   into a new authenticated denial type.

2.2.1.2  Limitations

   None.

2.2.1.3  Amendments to DNSSEC-bis

   None.

2.2.1.4  Cons

   It is cumbersome to carefully craft an TCR that 'just fits'.  The
   DNSSEC-bis protocol has many 'borderline' cases that needs special
   consideration.  It might be easier to do a full TCR, since a few of
   the types and signals need upgrading anyway.






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


2.2.1.5  Pros

   Graceful adoption of future versions of NSEC, while there are no
   amendments to DNSSEC-bis.

2.2.2  A Complete Type-code and Signal Rollover

   A new DNSSEC space is defined which can exist independent of current
   DNSSEC-bis space.

   This proposal assumes that all current DNSSEC type-codes
   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
   future versions of DNSSEC.  Any future version of DNSSEC has its own
   types to allow for keys, signatures, authenticated denial, etcetera.

2.2.2.1  Coexistence and Migration

   Both spaces can co-exist.  They can be made completely orthogonal.

2.2.2.2  Limitations

   None.

2.2.2.3  Amendments to DNSSEC-bis

   None.

2.2.2.4  Cons

   With this path we abandon the current DNSSEC-bis.  Though it is easy
   to role specific well-known and well-tested parts into the re-write,
   once deployment has started this path is very expensive for
   implementers, registries, registrars and registrants as well as
   resolvers/users.  A TCR is not to be expected to occur frequently, so
   while a next generation authenticated denial may be enabled by a TCR,
   it is likely that that TCR will only be agreed upon if it serves a
   whole basket of changes or additions.  A quick introduction of
   NSEC-ng should not be expected from this path.

2.2.2.5  Pros

   No amendments/changes to current DNSSEC-bis docset needed.  It is
   always there as last resort.

2.2.3  Unknown Algorithm in RRSIG

   This proposal assumes that future extensions make use of the existing
   NSEC RDATA syntax, while it may need to change the interpretation of



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


   the RDATA or introduce an alternative denial mechanism, invoked by
   the specific unknown signing algorithm.  The different interpretation
   would be signaled by use of different signature algorithms in the
   RRSIG records covering the NSEC RRs.

   When an entire zone is signed with a single unknown algorithm, it
   will cause implementations that follow current dnssec-bis documents
   to treat individual RRsets as unsigned.

2.2.3.1  Coexistence and migration

   Old and new NSEC RDATA interpretation or known and unknown Signatures
   can NOT coexist in a zone since signatures cover complete (NSEC)
   RRSets.

2.2.3.2  Limitations

   Validating resolvers agnostic of new interpretation will treat the
   NSEC RRset as "not signed".  This affects wildcard and non-existence
   proof, as well as proof for (un)secured delegations.  Also, all
   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
   insecure/bogus to an old validator.

   The algorithm version space is split for each future version of
   DNSSEC.  Violation of the 'modular components' concept.  We use the
   'validator' to protect the 'resolver' from unknown interpretations.

2.2.3.3  Amendments to DNSSEC-bis

   None.

2.2.3.4  Cons

   The algorithm field was not designed for this purpose.  This is a
   straightforward hack.

2.2.3.5  Pros

   No amendments/changes to current DNSSEC-bis docset needed.

3.  Recommendation

   The authors recommend that the working group commits to and starts
   work on a partial TCR, allowing graceful transition towards a future
   version of NSEC.  Meanwhile, to accomodate the need for an
   immediately, temporary, solution against zone-traversal, we recommend
   On-Demand NSEC synthesis.




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


   This approach does not require any mandatory changes to DNSSEC-bis,
   does not violate the protocol and fulfills the requirements.  As a
   side effect, it moves the cost of implementation and deployment to
   the users (zone owners) of this mechanism.

4.  Acknowledgements

   The authors would like to thank Sam Weiler and Mark Andrews for their
   input and constructive comments.

5.  References

5.1  Normative References

   [I-D.ietf-dnsext-dnssec-intro]
              Arends, R., Austein, R., Massey, D., Larson, M. and S.
              Rose, "DNS Security Introduction and Requirements",
              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
              2004.

   [I-D.ietf-dnsext-dnssec-protocol]
              Arends, R., "Protocol Modifications for the DNS Security
              Extensions",
              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
              October 2004.

   [I-D.ietf-dnsext-dnssec-records]
              Arends, R., "Resource Records for the DNS Security
              Extensions",
              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
              October 2004.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
              SIG(0)s)", RFC 2931, September 2000.

5.2  Informative References

   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
              With Widely Deployed DNS Software", RFC 1535, October
              1993.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",



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


              RFC 2535, March 1999.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
              (RR)", RFC 3658, December 2003.


Authors' Addresses

   Roy Arends
   Telematica Instituut
   Brouwerijstraat 1
   Enschede  7523 XC
   The Netherlands

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


   Peter Koch
   DENIC eG
   Wiesenh"uttenplatz 26
   Frankfurt  60329
   Germany

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


   Jakob Schlyter
   NIC-SE
   Box 5774
   Stockholm  SE-114 87
   Sweden

   Email: [e-mail]
   URI:   http://www.nic.se/












Arends, et al.           Expires August 25, 2005               [Page 14]

Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 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 August 25, 2005               [Page 15]