組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：boniter（boniter@etang.com）
譯文發(fā)布時(shí)間：2001-11-7
版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。


Network Working Group                                          D. Eastlake
Request for Comments: 2541                                             IBM
Category: Informational                                         March 1999

                              DNS安全操作考慮
本備忘錄的狀態(tài)
    本備忘錄為Internet社會(huì)提供了信息。它并沒(méi)有詳細(xì)說(shuō)明任何一種Internet標(biāo)準(zhǔn)。發(fā)
布此備忘錄是無(wú)約束的。

版權(quán)公告
Copyright (C) The Internet Society (1999).  All Rights Reserved.

目錄
概要	2
感謝	2
1. 導(dǎo)論	2
2. 公共/私有密鑰產(chǎn)生	2
3. 公共/私有密鑰壽命	2
4. 公共/私有密鑰長(zhǎng)度的考慮	3
4.1 RSA 密鑰長(zhǎng)度	3
4.2  DSS密鑰長(zhǎng)度	3
5. 私有密鑰存儲(chǔ)	3
6. 高級(jí)別區(qū)域,根區(qū)域和Meta-Root密鑰	4
7. 安全考慮	4
參考書(shū)目	4
作者地址	5
全部版權(quán)陳述	5

概要
    安全的DNS是基于密碼技術(shù)的。這些技術(shù)必須的一部分就是對(duì)密鑰和簽名的產(chǎn)生，壽命，
長(zhǎng)度和存儲(chǔ)的操作方面的仔細(xì)關(guān)注。額外的，對(duì)高級(jí)別區(qū)域和獨(dú)特的源區(qū)域的安全性必須更
加關(guān)注。這篇文檔討論了帶有KEY和SIG DNS資源記錄連接中使用密鑰和簽名的操作方面的
問(wèn)題。

感謝
    以下人的貢獻(xiàn)和建議是公認(rèn)的應(yīng)受到感謝的（按照字母順序排列）
        John Gilmore
         Olafur Gudmundsson
         Charlie Kaufman
1. 導(dǎo)論
    這篇文檔描述了在KEY和SIG資源使用中的DNS密鑰和簽名的產(chǎn)生，壽命，長(zhǎng)度和存儲(chǔ)
的操作考慮[RFC 2535]。特別注意高級(jí)別區(qū)域和源區(qū)域。

2. 公共/私有密鑰產(chǎn)生
    所有密鑰的精心產(chǎn)生有時(shí)會(huì)被忽視，但在任何密碼安全系統(tǒng)中絕對(duì)是必不可少的元素。
如果對(duì)手能夠縮短可能的密鑰空間而使得它能被用盡一切手段破解，那么在足夠長(zhǎng)的密鑰中
使用的強(qiáng)大的運(yùn)算法則仍然派不上用場(chǎng)。在[RFC 1750]中有針對(duì)產(chǎn)生隨機(jī)密鑰的技術(shù)建議。
    長(zhǎng)期限的密鑰有獨(dú)特的敏銳性，它將會(huì)扮演一個(gè)更重要的角色，而且被攻擊時(shí)比短期限
的密鑰需要更長(zhǎng)的時(shí)間。強(qiáng)烈推薦長(zhǎng)期限的密鑰必須通過(guò)間隙以獨(dú)立于網(wǎng)絡(luò)的掉線方式在最
小的高級(jí)別的可靠硬件上產(chǎn)生。

3. 公共/私有密鑰壽命
    沒(méi)有永久性的密鑰。使用中的密鑰時(shí)間越長(zhǎng)，它由于疏忽，意外，偵測(cè)或密碼破譯而被
破解的可能性就越大。此外，如果密鑰的變更幾乎沒(méi)有，就會(huì)存在一個(gè)很大的風(fēng)險(xiǎn)，當(dāng)要改
變密鑰時(shí)，在場(chǎng)沒(méi)有人知道怎樣做，或是在密鑰變更程序中的操作問(wèn)題已經(jīng)發(fā)展了。
    如果公共密鑰壽命是本地策略中的事件，這些考慮意味著，除非有特殊的情況，長(zhǎng)期限
密鑰不應(yīng)該有比4年更長(zhǎng)的壽命。實(shí)際上，對(duì)于長(zhǎng)期限秘要的一個(gè)更合理的策略就是在預(yù)期
的13個(gè)月壽命中保持離機(jī)狀態(tài)并謹(jǐn)慎監(jiān)督，而且每一年必須替換。對(duì)于在貿(mào)易安全或是同
類(lèi)事物中使用的密鑰的最長(zhǎng)壽命預(yù)期是在線的36天，它們每個(gè)月都要被更換或是更頻繁。
在許多情況下，密鑰的壽命稍微超過(guò)一天可能更加合理。
    另一方面，壽命太短的公共密鑰可能會(huì)導(dǎo)致在重新標(biāo)記數(shù)據(jù)和回收最新的消息方面造成
嚴(yán)重的資源消耗，因?yàn)榫彺娴男畔⒆兊煤荜惻f。在Internet環(huán)境中，幾乎所有的公共密鑰
壽命都不得短于3分鐘，這是在特殊情況下最大信息包延時(shí)的合理估計(jì)。

4. 公共/私有密鑰長(zhǎng)度的考慮
    在DNS安全擴(kuò)展中公共密鑰長(zhǎng)度的選擇有一定的要素。不幸的是，這些要素常常不在同
一說(shuō)明書(shū)中指出。區(qū)域密鑰長(zhǎng)度的選擇通常是由域管理員依靠本地的條件制定的。
    在大多數(shù)方案中，長(zhǎng)的密鑰更安全但是速度更慢。另外，長(zhǎng)的密鑰增加了KEY和SIG RRs
的長(zhǎng)度。這就增加了DNS UDP包的溢出可能在響應(yīng)中使用更高花費(fèi)的TCP的可能。

4.1 RSA 密鑰長(zhǎng)度
    給出一個(gè)小的公共典型，MD5/RSA運(yùn)算法則中的確認(rèn)（最普通的操作）將會(huì)被模長(zhǎng)的平
方粗略地改變，標(biāo)記會(huì)被模長(zhǎng)的立方改變，而且密鑰的產(chǎn)生（最小的普通操作）將會(huì)被模長(zhǎng)
的四次方所改變。提取模的公因子常用的最好和打破RSA安全的運(yùn)算法則是粗略地改變模本
身的1.6次方。因此，從640bit的模到1280bit的模只通過(guò)4個(gè)要素增加了確認(rèn)時(shí)間，但
是也可能增加了超過(guò)2^900的打破密鑰的工作要素。
    建議的最小RSA運(yùn)算法則模的長(zhǎng)度是704bit，在此時(shí)被創(chuàng)造者認(rèn)為是安全可靠的。但
在DNS樹(shù)中的高級(jí)別區(qū)域可能為了安全考慮，需要設(shè)置一個(gè)更大的最小長(zhǎng)度，也許是
1000bit。（自從United States National Security Agency允許使用高于512bitRSA模的
編密碼系統(tǒng)的輸出，使用小的模數(shù)，i.e.n，必須認(rèn)為是不可靠的。）
    只用于安全數(shù)據(jù)而不對(duì)于其它安全密鑰的RSA密鑰，704bit在此時(shí)顯得更合適。

4.2  DSS密鑰長(zhǎng)度
    DSS密鑰在相同的長(zhǎng)度下可能與RSA密鑰有相同的安全性，但是DSS運(yùn)算法制更小。

5. 私有密鑰存儲(chǔ)
    建議那里可能的話，區(qū)域私有密鑰和區(qū)域原版拷貝文件必須只在脫機(jī)，無(wú)網(wǎng)絡(luò)連接，本
身絕對(duì)可靠的機(jī)器上保留和使用。周期性的，一個(gè)應(yīng)用程序可以通過(guò)對(duì)分區(qū)/運(yùn)算法則增加
SIG與NXT RRs并增加無(wú)密鑰類(lèi)型的KEY RR用來(lái)增強(qiáng)驗(yàn)證，在這些地方帶有這種運(yùn)算法則
的分區(qū)的確切的KEY RR并不被提供。那樣擴(kuò)展文件就能被傳輸，也許通過(guò)暗網(wǎng)，到達(dá)初級(jí)
服務(wù)機(jī)的網(wǎng)絡(luò)區(qū)域。
    這個(gè)想法對(duì)于網(wǎng)絡(luò)來(lái)說(shuō)是避免來(lái)自網(wǎng)絡(luò)的損害的一種信息流。在網(wǎng)絡(luò)上在線保留區(qū)域原
版文件并簡(jiǎn)單地通過(guò)立憲的簽名人回收并不像以上所說(shuō)的那樣。如果主機(jī)寄居的環(huán)境是是危
險(xiǎn)的話，這種再現(xiàn)的譯本仍然會(huì)被損害。為了最大的安全考慮，區(qū)域的原版拷貝文件應(yīng)該離
線并不應(yīng)該在基于以通信為媒介的不可靠網(wǎng)絡(luò)上被升級(jí)。
    區(qū)域的動(dòng)態(tài)安全更新是不可能的[RFC 2137]。在這種情況下，私有密鑰的更新SOA和
NXT系列至少必須是在線的。
    安全問(wèn)題的解決者必須用一些可信的在線公共密鑰信息（或是對(duì)解決者來(lái)說(shuō)的一個(gè)安全
路徑）來(lái)完成配置，否則他們不能進(jìn)行鑒別。盡管在線，這種公共密鑰信息必須被保護(hù)，否
則它就能被改變，以致騙取DNS數(shù)據(jù)成為可信的。
    無(wú)區(qū)域私有密鑰，例如主機(jī)或者用戶的密鑰，一般必須保持在線，用于像DNS事務(wù)安全
方面的實(shí)際目的。

6. 高級(jí)別區(qū)域,根區(qū)域和Meta-Root密鑰
    高級(jí)別區(qū)域通常比的級(jí)別區(qū)域更敏感。任何控制或是破壞一個(gè)區(qū)域安全的人能獲取它的
子域的所有權(quán)力（除非解決問(wèn)題的人在本地配置了子域的公共密鑰）。因此，對(duì)于高級(jí)別區(qū)
域必須特別地小心并使用強(qiáng)大的密鑰。
    根區(qū)域是所有區(qū)域中最危急的。某個(gè)控制或危機(jī)根區(qū)域安全的人將控制使用根區(qū)域的所
有用戶的完全DNS名稱(chēng)空間（除非解決問(wèn)題的人在本地配置了子域的公共密鑰）。因此，根
區(qū)域必須盡最大可能的小心。必須使用最強(qiáng)大和最小心的密鑰。根區(qū)域私有密鑰應(yīng)該一直處
于離線狀態(tài)。
    許多問(wèn)題的解決者將會(huì)在原服務(wù)器開(kāi)始使用和驗(yàn)證DNS數(shù)據(jù)。全世界龐大的問(wèn)題解決人
員的安全升級(jí)將會(huì)變得相當(dāng)?shù)睦щy。盡管在上面第3節(jié)的指導(dǎo)政策暗示根區(qū)域密鑰一年改變
一次或是更頻繁，如果它在所有問(wèn)題解決這種實(shí)行靜態(tài)配置，它將會(huì)在改變的時(shí)候被更新。
    允許根區(qū)域密鑰的相關(guān)頻繁改變使得DNS樹(shù)的最終密鑰的暴露減為最小，將會(huì)有一個(gè)使
用很少的“meta-root”密鑰，只用來(lái)標(biāo)記帶有重疊時(shí)間有效性的滾動(dòng)周期的常規(guī)根密鑰RR
的次序。根區(qū)域包含meta-root和通用常規(guī)的根KEY RR(s)，在meta-root和其它根私有密
鑰自身下被SIG RRs標(biāo)記。
    在存儲(chǔ)和使用meta-root密鑰中使用盡可能強(qiáng)的安全機(jī)制是很有必要的。用于防范的精
確技術(shù)的使用不在這篇文章的討論范圍。由于它的特殊地位，它也許最好是由對(duì)于擴(kuò)展時(shí)段，
例如5到10年，的相同meta-root密鑰來(lái)延續(xù)。

7. 安全考慮
    整篇文章是出于公共/私有密鑰這一對(duì)DNS安全性的可操作考慮的。

參考書(shū)目
   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
                Facilities", STD 13, RFC 1034, November 1987.

   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
                Specifications", STD 13, RFC 1035, November 1987.

   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
                Requirements for Security", RFC 1750, December 1994.

   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
                Security Extensions", RFC 2065, January 1997.

   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
                Update", RFC 2137, April 1997.

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

   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.

作者地址
   Donald E. Eastlake 3rd
   IBM
   65 Shindegan Hill Road, RR #1
   Carmel, NY 10512

   Phone:   +1-914-276-2668(h)
            +1-914-784-7913(w)
   Fax:     +1-914-784-3833(w)
   EMail:   dee3@us.ibm.com

全部版權(quán)陳述
  Copyright (C) The Internet Society (1999).  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.
RFC2541——DNS Security Operational Consideration                          DNS安全操作考慮


2
RFC文檔中文翻譯計(jì)劃