DNS安全操作考慮

概要
安全的DNS是基于密碼技術的。這些技術必須的一部分就是對密鑰和簽名的產生，壽命，
長度和存儲的操作方面的仔細關注。額外的，對高級別區域和獨特的源區域的安全性必須更
加關注。這篇文檔討論了帶有KEY和SIGDNS資源記錄連接中使用密鑰和簽名的操作方面的
問題。

感謝
以下人的貢獻和建議是公認的應受到感謝的（按照字母順序排列）
JohnGilmore
OlafurGudmundsson
CharlieKaufman
1.導論
這篇文檔描述了在KEY和SIG資源使用中的DNS密鑰和簽名的產生，壽命，長度和存儲
的操作考慮[RFC2535]。特別注意高級別區域和源區域。

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

3.公共/私有密鑰壽命
沒有永久性的密鑰。使用中的密鑰時間越長，它由于疏忽，意外，偵測或密碼破譯而被
破解的可能性就越大。此外，如果密鑰的變更幾乎沒有，就會存在一個很大的風險，當要改
變密鑰時，在場沒有人知道怎樣做，或是在密鑰變更程序中的操作問題已經發展了。
如果公共密鑰壽命是本地策略中的事件，這些考慮意味著，除非有特殊的情況，長期限
密鑰不應該有比4年更長的壽命。實際上，對于長期限秘要的一個更合理的策略就是在預期
的13個月壽命中保持離機狀態并謹慎監督，而且每一年必須替換。對于在貿易安全或是同
類事物中使用的密鑰的最長壽命預期是在線的36天，它們每個月都要被更換或是更頻繁。
在許多情況下，密鑰的壽命稍微超過一天可能更加合理。
另一方面，壽命太短的公共密鑰可能會導致在重新標記數據和回收最新的消息方面造成
嚴重的資源消耗，因為緩存的信息變得很陳舊。在Inte.net環境中，幾乎所有的公共密鑰
壽命都不得短于3分鐘，這是在特殊情況下最大信息包延時的合理估計。

4.公共/私有密鑰長度的考慮
在DNS安全擴展中公共密鑰長度的選擇有一定的要素。不幸的是，這些要素常常不在同
一說明書中指出。區域密鑰長度的選擇通常是由域管理員依靠本地的條件制定的。
在大多數方案中，長的密鑰更安全但是速度更慢。另外，長的密鑰增加了KEY和SIGRRs
的長度。這就增加了DNSUDP包的溢出可能在響應中使用更高花費的TCP的可能。

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

4.2DSS密鑰長度
DSS密鑰在相同的長度下可能與RSA密鑰有相同的安全性，但是DSS運算法制更小。

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

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

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

參考書目
[RFC1034]Mockapetris,P.,"DomainNames-Conceptsand
Facilities",STD13,RFC1034,November1987.

[RFC1035]Mockapetris,P.,"DomainNames-Implementationand
Specifications",STD13,RFC1035,November1987.

[RFC1750]Eastlake,D.,Crocker,S.andJ.Schiller,"Randomness
RequirementsforSecurity",RFC1750,December1994.

[RFC2065]Eastlake,D.andC.Kaufman,"DomainNameSystem
SecurityExtensions",RFC2065,January1997.

[RFC2137]Eastlake,D.,"SecureDomainNameSystemDynamic
Update",RFC2137,April1997.

[RFC2535]Eastlake,D.,"DomainNameSystemSecurityExtensions",
RFC2535,March1999.

[RSAFAQ]RSADSIFrequentlyAskedQuestionsperiodicposting.

作者地址
DonaldE.Eastlake3rd
IBM
65ShindeganHillRoad,RR#1
Carmel,NY10512

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

全部版權陳述
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.