RFC3090.docVIP

RFC3090 组织：中国互动出版网（/） RFC文档中文翻译计划（/compters/emook/aboutemook.htm） E-mail：ouyang@ 译者：王顺（zhenm2000 wangs97@263.net） 译文发布时间：2001-4-9 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。 Network Working Group E. Lewis Request for Comments: 3090 NAI Labs Category: Standards Track March 2001 RFC3090域名系统在区域状况下的安全扩展声明 （RFC3090 DNS Security Extension Clarification on Zone Status） 本备忘录状态 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要： 本文提出了安全区域的定义，阐明和更新了RFC2535的部分文档。RFC2535定义了以每个算法为基础的安全区域。如一个区域对RSA（公开密钥算法）密钥是安全的，对DSA(数字签名算法)密钥并不是安全的。本文改变了这个定义，一个区域的安全与否与是否使用密钥算法是无关的。为了更加简化对区域状态的限定，本文反对实验性安全状态。 1．介绍 一个DNS区域是否安全是一个至少在四种情况下都会被问到的问题：一个区域管理员在用DNSSEC配置一个区域时，会问到这个问题；当一个可能需要DESSEC过程的新请求到达时，动态更新服务器会问这个问题；当父区域加入数据说明子区域的状态时，一个授权的区域会考虑子区域的安全问题；一个解释器在接受属于这个区域的数据时会问该问题。 1．1当区域的状态重要时 一个域管理员要能够决定通过哪些步骤使区域尽可能的安全。认识到由于DNS和它的管理的自然分布，任何单独的区域都在其他区域的掌管之中，当它显得安全时。本文将定义如何使一个区域真正的安全。 一个动态更新的名字服务器应该知道一个正在被更新的区域是否在更新数据上添加签名、是否应用NXT记录和其他需要的处理。在这种情况下，可以想象：名字服务器以知识配置，但“能够通过检测日期决定区域的状态”对配置参数来说是一个可取的选择。 一个授权的区域需要说明子区域是否安全，有这种要求的原因在于，通过这种方法一个解释器可对一个区域做出自己的决定（见下一段）。缩短这个长的理由即，父区域需要知道子区域是否有安全性考虑。这儿有两部分问题：在哪些状况下，父区域会考虑子区域的安全性？如果一个子区域是安全的，父区域如何知道？ 一个解释器在处理一个区域的数据时，要知道这个区域是否安全。根本地，一个解释器需要知道是否会预期到一个覆盖于数据的可用的签名。如何去实施这个决定则超出了本文档的范围。除了在有些情况下，解释器需要连接到父区域以了解父区域是否声明子区域状态是安全的。 1．2 安全岛 DNSSEC的目标是保证包括从根区域和最顶层的域到叶子区域各层内的每个区域的安全。我们知道，从一个不安全的域名系统到一个完全安全的或者说是尽可能安全的树域需要花费一段时间。在这段时间内，DNSSEC将会被应用到树中的各种位置，并不一定要自上而下。 例如，在某个特殊的时刻，根区域和“test.”TLD(顶层的域)是安全的，但region1.test.可能不安全。（作为参考，我们不妨设region2.test.是安全的。）然而，subarea1.region1.test.可能已经和它的授权一起通过了安全处理过程。这儿就出现了两难的状况：子域subarea1不能适当的得到他的父域region1（不安全的）所设的区域密钥。 通常描述位于“subarea1.region1.test.”或“subarea1.region1.test.”以下的连续安全的区域集的短语是“安全岛（island of security）”。使一个DNSSEC解释器能够信任这个安