rfc3090.txt

RFC 的详细文档！

   belonging to the parent zone.  The private key's public companion
   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
   algorithm and owned by the parent's apex.

   If a zone cannot get a conforming signature from the parent zone, the
   child zone cannot be considered globally secured.  The only exception
   to this is the root zone, for which there is no parent zone.

   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
   with the current NXT record.  This requirement is open to
   modification when two things happen.  First, an alternate mechanism
   to the NXT is defined and second, a means by which a zone can
   indicate that it is using an alternate method.

   2.1.d. Each RR set that qualifies for zone membership MUST be signed
   by a key that is in the apex's KEY RR set and is a zone signing KEY
   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
   section 2.3.1.)

   Mentioned earlier, the root zone is a special case.  The root zone
   will be considered to be globally secured provided that if conforms
   to the rules for locally secured, with the exception that rule 2.1.a.
   be also met (mandatory to implement requirement).



Lewis                       Standards Track                     [Page 6]

RFC 3090         DNS Security Extension on Zone Status        March 2001


2.2 Locally Secured

   The term "locally" stems from the likely hood that the only resolvers
   to be configured for a particular zone will be resolvers "local" to
   an organization.

   A locally secured zone is a zone that complies with rules like those
   for a globally secured zone with the following exceptions.  The
   signing keys may be of an algorithm that is not mandatory to
   implement and/or the verification of the zone keys in use may rely on
   a verification chain that is not parallel to the delegation tree
   (off-tree validation).

   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
   least one zone signing KEY RR (2.a) in the set.

   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
   one of the following two subclauses MUST hold true.

   2.2.b.1 The private key's public companion MUST be pre-configured in
   all the resolvers of interest.

   2.2.b.2 The private key's public companion MUST be a zone signing KEY
   RR (2.a) authorized to provide validation of the zone's apex KEY RR
   set, as recognized by resolvers of interest.

   The previous sentence is trying to convey the notion of using a
   trusted third party to provide validation of keys.  If the domain
   name owning the validating key is not the parent zone, the domain
   name must represent someone the resolver trusts to provide
   validation.

   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
   the discussion following 2.1.c.

   2.2.d. Each RR set that qualifies for zone membership MUST be signed
   by a key that is in the apex's KEY RR set and is a zone signing KEY
   RR (2.a).  (Updates 2535, section 2.3.1.)

2.3 Unsecured

   All other zones qualify as unsecured.  This includes zones that are
   designed to be experimentally secure, as defined in a later section
   on that topic.







Lewis                       Standards Track                     [Page 7]

RFC 3090         DNS Security Extension on Zone Status        March 2001


2.4 Wrap up

   The designation of globally secured, locally secured, and unsecured
   are merely labels to apply to zones, based on their contents.
   Resolvers, when determining whether a signature is expected or not,
   will only see a zone as secured or unsecured.

   Resolvers that follow the most restrictive DNSSEC verification rules
   will only see globally secured zones as secured, and all others as
   unsecured, including zones which are locally secured.  Resolvers that
   are not as restrictive, such as those that implement algorithms in
   addition to the mandatory to implement algorithms, will see some
   locally secured zones as secured.

   The intent of the labels "global" and "local" is to identify the
   specific attributes of a zone.  The words are chosen to assist in the
   writing of a document recommending the actions a zone administrator
   take in making use of the DNS security extensions.  The words are
   explicitly not intended to convey a state of compliance with DNS
   security standards.

3 Experimental Status

   The purpose of an experimentally secured zone is to facilitate the
   migration from an unsecured zone to a secured zone.  This distinction
   is dropped.

   The objective of facilitating the migration can be achieved without a
   special designation of an experimentally secure status.
   Experimentally secured is a special case of locally secured.  A zone
   administrator can achieve this by publishing a zone with signatures
   and configuring a set of test resolvers with the corresponding public
   keys.  Even if the public key is published in a KEY RR, as long as
   there is no parent signature, the resolvers will need some pre-
   configuration to know to process the signatures.  This allows a zone
   to be secured with in the sphere of the experiment, yet still be
   registered as unsecured in the general Internet.

4 IANA Considerations

   This document does not request any action from an assigned number
   authority nor recommends any actions.









Lewis                       Standards Track                     [Page 8]

RFC 3090         DNS Security Extension on Zone Status        March 2001


5 Security Considerations

   Without a means to enforce compliance with specified protocols or
   recommended actions, declaring a DNS zone to be "completely" secured
   is impossible.  Even if, assuming an omnipotent view of DNS, one can
   declare a zone to be properly configured for security, and all of the
   zones up to the root too, a misbehaving resolver could be duped into
   believing bad data.  If a zone and resolver comply, a non-compliant
   or subverted parent could interrupt operations.  The best that can be
   hoped for is that all parties are prepared to be judged secure and
   that security incidents can be traced to the cause in short order.

6 Acknowledgements

   The need to refine the definition of a secured zone has become
   apparent through the efforts of the participants at two DNSSEC
   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
   funded research network), and other workshops.  Further discussions
   leading to the document include Olafur Gudmundsson, Russ Mundy,
   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
   others have contributed significant input via the namedroppers
   mailing list.

7 References

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

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

   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
             "Dynamic Updates in the Domain Name System", RFC 2136,
             April 1997.

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

   [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
             Dynamic Update", RFC 3007, November 2000.

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





Lewis                       Standards Track                     [Page 9]

RFC 3090         DNS Security Extension on Zone Status        March 2001


10 Author's Address

   Edward Lewis
   NAI Labs
   3060 Washington Road Glenwood
   MD 21738

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










































Lewis                       Standards Track                    [Page 10]

RFC 3090         DNS Security Extension on Zone Status        March 2001


11 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                       Standards Track                    [Page 11]