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

1、<p>　　組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）</p><p>　　RFC文檔中文翻譯計(jì)劃（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ā)布時(shí)間：2001-4-9</p><p>　　版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(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ū)域狀況下的安全擴(kuò)展聲明</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定義了以每個(gè)算法為基礎(chǔ)的安全區(qū)域。如一個(gè)區(qū)域?qū)SA（公開(kāi)密鑰算法）密

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

37、><p>　　對(duì)全域安全、局部安全和不安全的指定只不過(guò)是適用于以其內(nèi)容為基礎(chǔ)的區(qū)域的標(biāo)簽。當(dāng)決定一個(gè)簽名是否為預(yù)期時(shí)，解釋器只會(huì)看區(qū)域是不是安全的。</p><p>　　遵從最多約束DNSSEC確定規(guī)則的解釋器只會(huì)將全域安全的區(qū)域視為安全的。包括局部安全在內(nèi)的所有其它區(qū)域均被視為不安全的。諸如對(duì)實(shí)現(xiàn)算法（除強(qiáng)制性的實(shí)現(xiàn)算法以外）沒(méi)有約束的解釋器將會(huì)認(rèn)為局部安全的區(qū)域?yàn)榘踩摹?lt;/p>

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

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

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

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

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

43、gt;<p><b>　　7．參考文獻(xiàn)</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