rfc3090_域名系統(tǒng)在區(qū)域狀況下的安全擴展聲明

1、<p>　　組織：中國互動出版網(wǎng)（http://www.china-pub.com/）</p><p>　　RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）</p><p>　　E-mail：ouyang@china-pub.com</p><p>　　譯者：王順（zhe

2、nm2000 wangs97@263.net）</p><p>　　譯文發(fā)布時間：2001-4-9</p><p>　　版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須保留本文檔的翻譯及版權(quán)信息。</p><p>　　Network Working Group

3、 E. Lewis</p><p>　　Request for Comments: 3090 NAI Labs</p><p>　　Category: Standards Track March 2001</p><

4、;p>　　RFC3090域名系統(tǒng)在區(qū)域狀況下的安全擴展聲明</p><p>　?。≧FC3090 DNS Security Extension Clarification on Zone Status）</p><p><b>　　本備忘錄狀態(tài)</b></p><p>　　This memo provides information fo

5、r the Internet community. It does</p><p>　　not specify an Internet standard of any kind. Distribution of this</p><p>　　memo is unlimited.</p><p><b>　　版權(quán)聲明</b></p>

6、;<p>　　Copyright (C) The Internet Society (1999). All Rights Reserved.</p><p><b>　　摘要：</b></p><p>　　本文提出了安全區(qū)域的定義，闡明和更新了RFC2535的部分文檔。RFC2535定義了以每個算法為基礎(chǔ)的安全區(qū)域。如一個區(qū)域?qū)SA（公開密鑰算法）密

7、鑰是安全的，對DSA(數(shù)字簽名算法)密鑰并不是安全的。本文改變了這個定義，一個區(qū)域的安全與否與是否使用密鑰算法是無關(guān)的。為了更加簡化對區(qū)域狀態(tài)的限定，本文反對實驗性安全狀態(tài)。</p><p><b>　　1．介紹</b></p><p>　　一個DNS區(qū)域是否安全是一個至少在四種情況下都會被問到的問題：一個區(qū)域管理員在用DNSSEC配置一個區(qū)域時，會問到這個問題；當一

8、個可能需要DESSEC過程的新請求到達時，動態(tài)更新服務器會問這個問題；當父區(qū)域加入數(shù)據(jù)說明子區(qū)域的狀態(tài)時，一個授權(quán)的區(qū)域會考慮子區(qū)域的安全問題；一個解釋器在接受屬于這個區(qū)域的數(shù)據(jù)時會問該問題。</p><p>　　1．1當區(qū)域的狀態(tài)重要時</p><p>　　一個域管理員要能夠決定通過哪些步驟使區(qū)域盡可能的安全。認識到由于DNS和它的管理的自然分布，任何單獨的區(qū)域都在其他區(qū)域的掌管之中，當

9、它顯得安全時。本文將定義如何使一個區(qū)域真正的安全。</p><p>　　一個動態(tài)更新的名字服務器應該知道一個正在被更新的區(qū)域是否在更新數(shù)據(jù)上添加簽名、是否應用NXT記錄和其他需要的處理。在這種情況下，可以想象：名字服務器以知識配置，但“能夠通過檢測日期決定區(qū)域的狀態(tài)”對配置參數(shù)來說是一個可取的選擇。</p><p>　　一個授權(quán)的區(qū)域需要說明子區(qū)域是否安全，有這種要求的原因在于，通過這種方

10、法一個解釋器可對一個區(qū)域做出自己的決定（見下一段）?？s短這個長的理由即，父區(qū)域需要知道子區(qū)域是否有安全性考慮。這兒有兩部分問題：在哪些狀況下，父區(qū)域會考慮子區(qū)域的安全性？如果一個子區(qū)域是安全的，父區(qū)域如何知道？</p><p>　　一個解釋器在處理一個區(qū)域的數(shù)據(jù)時，要知道這個區(qū)域是否安全。根本地，一個解釋器需要知道是否會預期到一個覆蓋于數(shù)據(jù)的可用的簽名。如何去實施這個決定則超出了本文檔的范圍。除了在有些情況下，解

11、釋器需要連接到父區(qū)域以了解父區(qū)域是否聲明子區(qū)域狀態(tài)是安全的。</p><p><b>　　1．2 安全島</b></p><p>　　DNSSEC的目標是保證包括從根區(qū)域和最頂層的域到葉子區(qū)域各層內(nèi)的每個區(qū)域的安全。我們知道，從一個不安全的域名系統(tǒng)到一個完全安全的或者說是盡可能安全的樹域需要花費一段時間。在這段時間內(nèi)，DNSSEC將會被應用到樹中的各種位置，并不一定要

12、自上而下。</p><p>　　例如，在某個特殊的時刻，根區(qū)域和“test.”TLD(頂層的域)是安全的，但region1.test.可能不安全。（作為參考，我們不妨設(shè)region2.test.是安全的。）然而，subarea1.region1.test.可能已經(jīng)和它的授權(quán)一起通過了安全處理過程。這兒就出現(xiàn)了兩難的狀況：子域subarea1不能適當?shù)牡玫剿母赣騬egion1（不安全的）所設(shè)的區(qū)域密鑰。</

13、p><p>　　通常描述位于“subarea1.region1.test.”或“subarea1.region1.test.”以下的連續(xù)安全的區(qū)域集的短語是“安全島（island of security）”。使一個DNSSEC解釋器能夠信任這個安全島的唯一途徑是解釋器已經(jīng)預配置了安全島的根部“subarea1.region1.test.”的區(qū)域密鑰。其他解釋器（未做過這種配置的）將認為該島是不安全的。</p&g

14、t;<p>　　一個安全島開始于一個公開密鑰已經(jīng)在解釋器中預配置的區(qū)域。在這個島內(nèi)的子區(qū)域都是安全的。安全島的下面被授權(quán)定義為不安全的區(qū)域。一個安全島也可以位于另一個之上，就意味著至少有一個不安全的區(qū)域介于上面一個島的底部和下面的安全島的根部之間。</p><p>　　盡管subarea1.region1.test.和region2.test.都被適當?shù)呐渲脼榘踩珷顟B(tài)，只有后者才是真正“全部地”安全

15、——在這種情況下，所有的DNSSEC解釋器都可以確定他的數(shù)據(jù)。前者suarea1只會被那些解釋器的一個子集，即做過適當?shù)呐渲玫慕忉屍?，認為是安全的。本文將這種區(qū)域看作是局部安全的。</p><p>　　在RFC2535，又一個對“授予權(quán)力”實體的規(guī)定，它會為subarea1這樣的區(qū)域分配公共密鑰。另一個文檔RFC3008廢止了這種規(guī)定。不受其它文檔的影響，解釋器仍將需要適當?shù)呐渲靡阅軌蚶谩笆谟铏?quán)力”去確定sub

16、area1島的數(shù)據(jù)。</p><p>　　1．2．1決定最接近的安全根部</p><p>　　給定一個域，為了決定它是否安全，第一步要決定最接近的安全根部。最接近的安全根部就是名字與給定域標簽最匹配（按照從根部朝下的順序）的安全島的頂部。</p><p>　　例如，給定一個名為“sub.domain.testing.signed.exp.test.”的域，再給出下列

17、安全根部“exp.test.”、“testing.signed.exp.test.”和“not-the-same.xy.”，中間的一個是最接近的。因為第一個安全根部共享2個標簽，中間的是4個，最后的是0個。</p><p>　　最接近的為所要求的原因在于可除去由于NULL密鑰形成的不安全的錯誤觀念。繼續(xù)上面的例子，“testing…”和“exp.test.”都被列為安全根部也許是因為“signed.exp.tes

18、t.”是不安全的（有NULL密鑰），如果我們從“exp.test.”出發(fā)到我們給定的域（sub…），我們會由于遇到一個NULL密鑰而斷定sub…是未簽名的。然而，如果我們從“testing…”出發(fā)就會因發(fā)現(xiàn)“domain…”密鑰而得出“sub…”是安全的結(jié)論。</p><p>　　注意到這個例子假定為一個標簽深的區(qū)域，也沒有配置重復的安全島。需要澄清，給出的定義應該從與“short.xy.”最接近的安全根部中排除

19、“short.xy.test.”，盡管有兩個標簽匹配。</p><p>　　安全島的重復給出了非概念性的有趣的想法，在任何情況下對本協(xié)議均無影響。然而，建議協(xié)議的履行者們要確認他們的代碼沒有因重復而陷入環(huán)路。重復必然是在安全島增大至包含更大范圍的名字空間時產(chǎn)生的配置問題。</p><p>　　1．3父區(qū)域?qū)ψ訁^(qū)域安全的聲明</p><p>　　在本文的1.1節(jié)中出現(xiàn)

20、這樣的一句話“父區(qū)域聲明子區(qū)域是安全的”，這已經(jīng)產(chǎn)生了些許的疑惑。</p><p>　　父區(qū)域聲明子區(qū)域的狀態(tài)的需求可由下面的觀察得來：如果你想知道一個回答是不是安全的，該回答來自一個安全島并經(jīng)過適當?shù)暮灻敲茨惚仨殢脑摪踩珝u的根部開始察看。</p><p>　　要察看你正在檢查的回答，你可能需要自上而下的通過安全島的區(qū)域。從可信任的島的根部出發(fā)，下降至下一個區(qū)域。只要你信任上一個區(qū)域，

21、你需要從那里得到有關(guān)下一個區(qū)域的數(shù)據(jù)，否則該區(qū)域就有不安全的脆弱點。當（如果）你從一個安全區(qū)域到達一個不安全的脆弱點，你就已經(jīng)離開了安全島并將得出該回答是不安全的結(jié)論。</p><p>　　然而在RFC 2535 2.3.4節(jié)中，這些說法看上去和父區(qū)域聲明子區(qū)域的狀態(tài)的需要有矛盾：</p><p>　　對于超區(qū)域是安全的每個子區(qū)域來說，必須（MUST）是一個被超區(qū)域以KEY RR簽名的子區(qū)

22、域。這個一般會在子區(qū)域出現(xiàn)，也會包含在超區(qū)域中。但是，在一個不安全子區(qū)域不能或不會被修改以增加任何安全資源紀錄（RRs）時，一個聲明該子區(qū)域為不安全的KEY必須（MUST）在超區(qū)域的簽名中出現(xiàn)，當然前提為：超區(qū)域是安全的。</p><p>　　令人迷惑的是，在RFC 2535中，一個安全的父區(qū)域通過SAYING NOTHING(“may also be（可能是）”對比于“MUST also be（一定是）”)聲明

23、一個子區(qū)域是安全的。數(shù)據(jù)的缺乏意味著某些事物的安全只是個直覺的回答。這個觀點在理論環(huán)境被接受的同時，在操作中卻遇到了一些不適。然而，在這種情況下，用“沉默”來聲明某些事情是確實存在的。所以，沒有為了改變定義被證明的足夠的必要性。</p><p>　　1．4對RFC 2535的影響</p><p>　　本文更新了RFC 2535的部分內(nèi)容。安全區(qū)域的定義是對該RFC 3.4節(jié)的一個更新。更新

24、后的3.4節(jié)取消了實驗性密鑰的定義，并說明了一個方法，該方法能夠?qū)崿F(xiàn)那些它們原本被設(shè)計用來提供的功能。3.1.3節(jié)通過具體指定區(qū)域密鑰中的協(xié)議字節(jié)的值而被更新。</p><p>　　1．5“MUST”和其他關(guān)鍵字</p><p>　　本文中出現(xiàn)的關(guān)鍵字“MUST”、“REQUIRED”、“SHOULD”、“RECOMMENDED”和“MAY”的說明在RFC 2119中有描述。目前為止，本文

25、中僅出現(xiàn)“MUST”關(guān)鍵字。</p><p><b>　　2．區(qū)域狀態(tài)</b></p><p>　　在本節(jié)將描述管理一個區(qū)域DNSSEC狀態(tài)的規(guī)則。共有以下三層安全定義：全域、局部和不安全。當一個區(qū)域遵從最嚴格的DNSSEC處理規(guī)則集時，該區(qū)域是全域安全的。經(jīng)過某種程度的配置后，只能被經(jīng)過適當配置的解釋器認為是安全的，這種區(qū)域是局部安全的。除此以外的區(qū)域都是不安全的。

26、</p><p>　　注意：當前并沒有完整地定義DNSSEC的確定規(guī)則的文檔。為了這篇文檔的目的，假設(shè)最嚴格的規(guī)則集聲明：區(qū)域密鑰的確定鏈平行于授權(quán)樹升到根區(qū)域（參閱下面的2.b）。這并不意味著不允許選擇確定的路徑，只是為了正好建立底線定義。</p><p>　　在下面的規(guī)則中，為了避免重復，定義下列術(shù)語：</p><p>　　2.a KEY RR簽名區(qū)域——密鑰資

27、源記錄的標記域中，名字類型（標識一個區(qū)域的密鑰）具有值01。密鑰類型（說明一個允許鑒定數(shù)據(jù)的密鑰）值為00或01（參閱RFC 2535,3.1.2節(jié)）。KEY RR也有一個協(xié)議字節(jié)值DNSSEC(3)或ALL(255)。</p><p>　　這個定義更新了RFC 2535中對區(qū)域密鑰的定義，要求協(xié)議字段必須為DNSSEC或ALL是新增的（對3.1.3節(jié)做了更改）。</p><p>　　2.

28、b On-tree確認——只能通過父區(qū)域提供DNSSEC-meaningful簽名的授權(quán)模式，解釋器用它來設(shè)立一個從子區(qū)域的密鑰到一個公認的安全根部的信任鏈。術(shù)語“On-tree”指隨著域名系統(tǒng)域的等級（向上地）到達一個可信賴的密鑰。如果沒有其它有效的密鑰，可能就是根密鑰。術(shù)語“確認（validation）”指通過父區(qū)域提供的數(shù)字簽名來驗證子區(qū)域密鑰的完整性、確定性和公認性，以標記子區(qū)域的數(shù)據(jù)。</p><p>

29、　　2.c Off-tree確認——任何允許和父區(qū)域不同的域名提供對子區(qū)域密鑰簽名的授權(quán)模式，它能夠使解釋器信任這些密鑰。</p><p><b>　　2．1全域安全</b></p><p>　　一個全域安全區(qū)域，在一個“堅果外殼”中，是一個通過強制性執(zhí)行算法（RFC 2535,3.2節(jié)）和依賴于一個平行于授權(quán)樹（On-tree validation）的密鑰確認鏈的區(qū)

30、域。全域安全區(qū)域通過下列規(guī)則定義：</p><p>　　2.1.a 區(qū)域的末端必須具有一個KEY RR集，必須至少有一個區(qū)域為強制性的KEY RR（2.a）簽名實現(xiàn)這個集中的算法。</p><p>　　2.1.b區(qū)域的末端必須為屬于父區(qū)域的私鑰簽名。私鑰的公共伙伴必須是一個強制性實現(xiàn)算法并屬于父區(qū)域末端的KEY RR簽名的區(qū)域。</p><p>　　如果一個區(qū)域不能

31、從父區(qū)域得到一個一致的簽名，子區(qū)域不能被看成全域安全的，唯一的例外就是根區(qū)域，因為根區(qū)域沒有父區(qū)域。</p><p>　　2.1.c NXT記錄必須要散開以遍歷整個區(qū)域（闡明RFC 2535,2.3.2節(jié)）。注：對當前的NXT記錄有一些操作上的不適合，這要求修改為開放的，此時會發(fā)生兩種情況。第一，對NXT的選擇機制被定義；第二，作為區(qū)域聲明它用可選擇機制的手段。</p><p>　　2.1

32、.d 每個具備區(qū)域成員資格的RR集，必須用KEY RR集的末端中的密鑰簽名，并且使用強制性執(zhí)行算法的KEY RR簽名的區(qū)域。</p><p>　　回顧前面，根區(qū)域為一個特殊情況。規(guī)定如果適合局部安全的規(guī)則集，除規(guī)則2.1.a也被執(zhí)行（強制性執(zhí)行要求）外，根區(qū)域?qū)⒈豢紤]為全域安全的。</p><p><b>　　2．2局部安全</b></p><p&

33、gt;　　術(shù)語“局部（locally）”起源于漂亮的頭巾，被配置用于特殊區(qū)域的解釋器將會是局限于一個組織的的解釋器。</p><p>　　一個局部安全區(qū)域就是具有類似于全域安全區(qū)域的規(guī)則集的區(qū)域，除了以下例外。簽名密鑰可以是非強制性執(zhí)行的一個算法，使用中的區(qū)域密鑰的確定可以依賴于一個沒有與授權(quán)樹平行的確定鏈（Off-tree validation）。</p><p>　　2.2.a 區(qū)域的

34、末端必須有一個KEY RR集，其中必須至少有一個區(qū)域為KEY RR簽名。</p><p>　　2.2.b 區(qū)域末端的KEY RR集必須被一個私鑰簽名，而且下面的兩個子句必須保證正確。</p><p>　　2.2.b.1 私鑰的公共伙伴必須在所有感興趣的解釋器中預配置。</p><p>　　2.2.b.2 私鑰的公共伙伴必須是一個簽名授權(quán)提供區(qū)域末端密鑰資源記錄集確認

35、KEY RR的區(qū)域，可以被感興趣的解釋器承認。</p><p>　　上面的句子試圖表達對提供密鑰確認的第三方的信任的觀點。如果擁有確認密鑰的域名不是父區(qū)域，那么域名必須使解釋器信任以提供確認。</p><p>　　2.2.c NXT記錄必須散開以遍歷整個區(qū)域。注：參閱2.1.C的討論。</p><p>　　2.2.d 具有區(qū)域成員資格的每個RR集，必須被末端KEY

36、RR集中的一個密鑰簽名，并且是一個可簽名KEY RR的區(qū)域（更新RFC 2535 2.3.1節(jié)）。</p><p><b>　　2．3不安全</b></p><p>　　所有其它區(qū)域都不是安全的。這兒包括那些設(shè)計為實驗性安全的區(qū)域，它會在后面相關(guān)主體的小節(jié)中定義。</p><p><b>　　2．4綜述</b></p

37、><p>　　對全域安全、局部安全和不安全的指定只不過是適用于以其內(nèi)容為基礎(chǔ)的區(qū)域的標簽。當決定一個簽名是否為預期時，解釋器只會看區(qū)域是不是安全的。</p><p>　　遵從最多約束DNSSEC確定規(guī)則的解釋器只會將全域安全的區(qū)域視為安全的。包括局部安全在內(nèi)的所有其它區(qū)域均被視為不安全的。諸如對實現(xiàn)算法（除強制性的實現(xiàn)算法以外）沒有約束的解釋器將會認為局部安全的區(qū)域為安全的。</p>

38、;<p>　　標簽“全域”和“局部”的目的是標識一個區(qū)域具體的屬性。選擇這些單詞來幫助書寫推薦區(qū)域管理員接受利用域名系統(tǒng)安全擴展的行為的文檔。這些單詞沒有明確地打算表達服從域名系統(tǒng)安全標準的狀態(tài)。</p><p><b>　　3．實驗性狀態(tài)</b></p><p>　　引入一個實驗性安全區(qū)域的目的是促進從非安全區(qū)域到安全區(qū)域的遷移，這個特征已被刪去。&l

39、t;/p><p>　　沒有對實驗性安全狀態(tài)的特殊設(shè)計同樣可以實現(xiàn)促進遷移的目標。實驗性安全只是局部性安全的一種特殊情況。一個區(qū)域主管可以通過發(fā)布一個簽名區(qū)域和配置一套帶有相應的公開密鑰的測試解釋器來實現(xiàn)它。雖然公開密鑰以KEY RR公開，只要不存在父區(qū)域簽名，解釋器仍需要做一些配置，以了解如何處理這些簽名。這種使一個區(qū)域在實驗環(huán)繞下達到安全的方法被證明在正式的Internet下是不安全的。</p>&l

40、t;p><b>　　4．IANA考慮</b></p><p>　　本文件不需要任何來自于已分配的數(shù)字權(quán)力的影響，也不推薦任何行為。</p><p><b>　　5．安全性考慮</b></p><p>　　這并不意味著極力主張順從特定的協(xié)議或推薦的行為，聲稱一個DNS區(qū)域是“完全” 安全的仍是不可能的。雖然如此，假設(shè)一

41、個萬能的DNS，可以聲稱一個區(qū)域經(jīng)過對安全性的嚴格設(shè)置，所有的區(qū)域也都達到根部。一個錯誤的解析能夠欺騙你去相信壞的數(shù)據(jù)。如果一個區(qū)域和解釋器遵從它，一個未應允的或被破壞的父區(qū)域會中斷操作?？梢云谕淖詈们闆r就是所有的參與者都做好判斷安全的準備，安全事件能被追溯到短序的原因。</p><p><b>　　6．致謝</b></p><p>　　在由NIC-SE和CAIRN

42、主辦的兩個DNSSEC專題討論會、及其它專題討論會的參與者的共同努力下，精確給出安全區(qū)域的定義的要求已經(jīng)變得很明顯了。包括Olafur Gudmundsson，Russ Mundy，Robert Watson(羅伯特?沃森)和Brian Wellington（布賴恩?韋林頓）參與的進一步討論，導致了本文檔的產(chǎn)生。Roy Arends，Ted Lindgreen和其他人也通過namedroppers郵件列表貢獻了重大的輸入。</p&

43、gt;<p><b>　　7．參考文獻</b></p><p>　　[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",</p><p>　　STD 13, RFC 1034, November 1987.</p><p>　　

44、[RFC1035] Mockapetris, P., "Domain Names - Implementation and</p><p>　　Specification", STD 13, RFC 1035, November 1987.</p><p>　　[RFC2119] Bradner, S., "Key words for use in RFCs

45、to Indicate</p><p>　　Requirement Levels", BCP 14, RFC 2119, March 1997.</p><p>　　[RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,</p><p>　　"Dynamic Updat

46、es in the Domain Name System", RFC 2136,</p><p>　　April 1997.</p><p>　　[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC</p><p>　　2535, March 1999

47、.</p><p>　　[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)</p><p>　　Dynamic Update", RFC 3007, November 2000.</p><p>　　[RFC3008] Wellington, B., "Do

48、main Name System Security (DNSSEC)</p><p>　　Signing Authority", RFC 3008, November 2000.</p><p><b>　　作者地址</b></p><p>　　Edward Lewis</p><p><b>　　N

49、AI Labs</b></p><p>　　3060 Washington Road Glenwood</p><p><b>　　MD 21738</b></p><p>　　Phone: +1 443 259 2352</p><p>　　EMail: lewis@tislabs.com</p>

50、;<p><b>　　完整版權(quán)聲明</b></p><p>　　Copyright (C) The Internet Society (2001). All Rights Reserved.</p><p>　　This document and translations of it may be copied and furnished to<

51、/p><p>　　others, and derivative works that comment on or otherwise explain it</p><p>　　or assist in its implementation may be prepared, copied, published</p><p>　　and distributed, in w

52、hole or in part, without restriction of any</p><p>　　kind, provided that the above copyright notice and this paragraph are</p><p>　　included on all such copies and derivative works. However, th

53、is</p><p>　　document itself may not be modified in any way, such as by removing</p><p>　　the copyright notice or references to the Internet Society or other</p><p>　　Internet organi

54、zations, except as needed for the purpose of</p><p>　　developing Internet standards in which case the procedures for</p><p>　　copyrights defined in the Internet Standards process must be</p&g

55、t;<p>　　followed, or as required to translate it into languages other than</p><p><b>　　English.</b></p><p>　　The limited permissions granted above are perpetual and will not b

56、e revoked by the Internet Society or its successors or assigns.</p><p>　　This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET

57、 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 MERCHANTABI

58、LITY OR FITNESS FOR A PARTICULAR PURPOSE.</p><p><b>　　致謝</b></p><p>　　Funding for the RFC Editor function is currently provided by the</p><p>　　Internet Society.</p&g