rfc3090.txt

RFC中文技术文档

2.2.c NXT记录必须散开以遍历整个区域。注：参阅2.1.C的讨论。
2.2.d 具有区域成员资格的每个RR集，必须被末端KEY RR集中的一个密钥签名，并且是一个可签名KEY RR的区域（更新RFC 2535 2.3.1节）。
2．3不安全
所有其它区域都不是安全的。这儿包括那些设计为实验性安全的区域，它会在后面相关主体的小节中定义。
2．4综述
对全域安全、局部安全和不安全的指定只不过是适用于以其内容为基础的区域的标签。当决定一个签名是否为预期时，解释器只会看区域是不是安全的。
遵从最多约束DNSSEC确定规则的解释器只会将全域安全的区域视为安全的。包括局部安全在内的所有其它区域均被视为不安全的。诸如对实现算法（除强制性的实现算法以外）没有约束的解释器将会认为局部安全的区域为安全的。
标签“全域”和“局部”的目的是标识一个区域具体的属性。选择这些单词来帮助书写推荐区域管理员接受利用域名系统安全扩展的行为的文档。这些单词没有明确地打算表达服从域名系统安全标准的状态。
3．实验性状态
引入一个实验性安全区域的目的是促进从非安全区域到安全区域的迁移，这个特征已被删去。
没有对实验性安全状态的特殊设计同样可以实现促进迁移的目标。实验性安全只是局部性安全的一种特殊情况。一个区域主管可以通过发布一个签名区域和配置一套带有相应的公开密钥的测试解释器来实现它。虽然公开密钥以KEY RR公开，只要不存在父区域签名，解释器仍需要做一些配置，以了解如何处理这些签名。这种使一个区域在实验环绕下达到安全的方法被证明在正式的Internet下是不安全的。
4．IANA考虑
本文件不需要任何来自于已分配的数字权力的影响，也不推荐任何行为。
5．安全性考虑
这并不意味着极力主张顺从特定的协议或推荐的行为，声称一个DNS区域是“完全” 安全的仍是不可能的。虽然如此，假设一个万能的DNS，可以声称一个区域经过对安全性的严格设置，所有的区域也都达到根部。一个错误的解析能够欺骗你去相信坏的数据。如果一个区域和解释器遵从它，一个未应允的或被破坏的父区域会中断操作。可以期望的最好情况就是所有的参与者都做好判断安全的准备，安全事件能被追溯到短序的原因。
6．致谢
在由NIC-SE和CAIRN主办的两个DNSSEC专题讨论会、及其它专题讨论会的参与者的共同努力下，精确给出安全区域的定义的要求已经变得很明显了。包括Olafur Gudmundsson，Russ Mundy，Robert Watson(罗伯特?沃森)和Brian Wellington（布赖恩?韦林顿）参与的进一步讨论，导致了本文档的产生。Roy Arends，Ted Lindgreen和其他人也通过namedroppers邮件列表贡献了重大的输入。
7．参考文献
   [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.
作者地址
Edward Lewis
  NAI Labs
  3060 Washington Road Glenwood
  MD 21738

  Phone: [phone]
  EMail: [e-mail]
完整版权声明

   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.
致谢
Funding for the RFC Editor function is currently provided by the
   Internet Society.


RFC3090 DNS Security Extension Clarification on Zone Status  

1


1
ＲＦＣ文档中文翻译计划