組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：王安鵬（anpengwang    anpengwang@263.net）
譯文發(fā)布時間：2001-5-8
版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉載，但必
須保留本文檔的翻譯及版權信息。


Network Working Group                                      B. Wellington
Request for Comments: 3007                                       Nominum
Updates: 2535, 2136                                        November 2000
Obsoletes: 2137
Category: Standards Track


安全的域名系統(tǒng)動態(tài)更新
(RFC 3007 Secure Domain Name System (DNS) Dynamic Update)


本備忘錄的狀態(tài)

本文為Internet社區(qū)描述了一種Internet標準跟蹤協(xié)議，還需要討論和建議進行改善。
請查看“Internet正式協(xié)議標準”（STD 1）了解本協(xié)議的便準化進程和狀態(tài)。本備忘錄的傳
播不受限制。

版權公告
   Copyright (C) The Internet Society (2000).  All Rights Reserved.

摘要

本文提出了一種安全地動態(tài)更新域名系統(tǒng)的方法。該方法的意圖在于保證靈活性和可用
性，同時盡可能少地改變當前的協(xié)議。在最新的DNSSEC中動態(tài)更新消息的驗證已經(jīng)從數(shù)據(jù)確認
中分離出來。基于請求和事務驗證的安全通信用來提供授權。

本文所用關鍵字“必須”、“不得”、“要求”、“應”、“不應”、“需”、“不
可”、“推薦”、“可以”和“可選”參見RFC 2119的解釋。

目錄
1 簡介	2
1.1 DNS動態(tài)更新概述	2
1.2 – DNS事務安全概述	2
1.3 – 數(shù)據(jù)驗證和消息驗證的比較	2
1.4 – 數(shù)據(jù)和消息簽名	3
1.5 – 簽名長度	3
2 – 驗證（Authentication）	3
3 – 策略	3
3.1 – 標準策略Standard policies	4
3.1.1 – 用戶類型（User types）	4
3.2 – 其他策略（Additional policies）	4
4 – 與DNSSEC之間的相互影響	4
4.1 – 增加 SIGs	4
4.2 – 刪除 SIGs	4
4.3 –對SIGs的模糊更新	5
4.4 – 對區(qū)域的影響	5
5. 安全考慮	5
6.鳴謝	5
7.引用	5
8. 作者地址	6
9.  版權聲明	6

1 簡介
本文定義了一種動態(tài)更新域名系統(tǒng)的安全方法，只有經(jīng)過授權的資源才被允許修改域的內
容。當前存在的不安全的動態(tài)更新工程了本文的主要內容。
熟悉DNS系統(tǒng)[RFC1034, RFC1035]和動態(tài)更新[RFC2136]是很有用的，本文假定讀者已經(jīng)
熟悉這些內容。另外，建議了解DNS安全擴展[RFC2535]、SIG(0)事務安全[RFC2535, RFC2931]
和TSIG事務安全[RFC2845]。
本文更新了RFC2535，特別是節(jié)3.1.2，還有RFC 2136。根據(jù)應用實踐，本文廢止了
RFC2137，那是另一個安全動態(tài)更新的提議。   

1.1 DNS動態(tài)更新概述
DNS動態(tài)更新定義了新的DNS操作碼和對該操作碼的DNS消息的解釋器。更新可以指明插入或
者刪除數(shù)據(jù)，先要條件是進行更新的必要性。DNS更新請求的全部測試和修改全部限定在一個
單獨的域，在該域的主服務器上進行。動態(tài)域的主服務器在執(zhí)行更新時或者下一次訪問SOA前
增加域SOA序列號。

1.2 – DNS事務安全概述
包含TSIG或者SIG（0）記錄的DNS消息交換允許兩個DNS實體驗證彼此發(fā)出的DNS請求
和響應。TSIG MAC（消息驗證碼）源于共享加密，而SIG（0）則出自私有密鑰，其公共部分保
存在DNS中。這兩種情況下，DNS消息都包括一個含有消息簽名/MAC的記錄作為源記錄的最后
部分。TSIG使用的帶鍵散列表計算和校驗成本低廉。SIG（0）使用的公共密鑰加密，由于公共
密鑰保存在DNS中因而伸縮性更大。

1.3 – 數(shù)據(jù)驗證和消息驗證的比較
使用TSIG或者SIG（0）的基于驗證的消息，通過單個的簽名或者單個的校驗對整個消息
提供保護，其中TSIG使用了創(chuàng)建和檢查相對便宜的MAC。對于更新請求，可以由管理人員基于
一定的策略或者密碼協(xié)商來建立簽名。
域所有者的管理人員可以利用DNSSEC SIG記錄保護DNS消息中單個RRs或者Rrsets的完
整性。但是這樣不能保護動態(tài)更新請求。
如下所述，使用SIG記錄在更新請求中保護RRsets 與更新的設計相矛盾，而且無論如何
都需要昂貴的多重公共密鑰簽名和校驗。
由于SIG記錄沒有覆蓋包含記錄長度的消息頭，因此更新請求被惡意增加或者刪除了
RRsets也可能不會產生校驗錯誤。如果使用SIG記錄保護首要的小節(jié)，就無法分辨SIG本身是
首要的節(jié)還是僅僅用來校驗。
    如[RFC2535]所述，在更新請求的更新小節(jié)增加一個RRset實現(xiàn)對請求的簽名是很簡單的，
而且這個簽名可以用來永久的保護數(shù)據(jù)。但是如果刪除了一個RRset，SIG就沒有保護的數(shù)據(jù)
了。

1.4 – 數(shù)據(jù)和消息簽名
[RFC3008]指出，執(zhí)行DNSSEC驗證的分析器不得處理非信任區(qū)的密碼，除非本地的安全策
略另有規(guī)定。執(zhí)行安全動態(tài)更新時，在一個標志區(qū)內更新的所有信任區(qū)數(shù)據(jù)必須使用相應的區(qū)
域密碼標志。這樣可以實現(xiàn)更新請求的驗證和數(shù)據(jù)本身的驗證完全分離。
對于DNSSEC，主機密碼和用戶密碼主要用于消息驗證，其中包括動態(tài)更新消息驗證。因
此，主機密碼和用戶密碼可以用來生成更新驗證的SIG（0）記錄，或者在TKEY[RFC2930]過程
中生成TSIG共享加密。這兩種情況都不會使用非信任區(qū)密碼生成的SIG記錄進行DNSSEC驗
證，除非本地的安全策略另有規(guī)定。
出現(xiàn)在DNSSEC中的數(shù)據(jù)驗證僅僅包括DNSSEC信任區(qū)密碼和由此生成的簽名。

1.5 – 簽名長度
   [RFC2535, 節(jié)3.1.2]把密碼的簽名者字段定義為標志字段的最后4位，但沒有指明該域的
值。 本建議沒有定義該字段。作為對[RFC2535]的修正，密碼記錄中的該字段應設為0，而且
必須被忽略。
2 – 驗證（Authentication）
所有的動態(tài)更新消息都必須包含TSIG或者SIG（0）記錄，這樣服務器才能證實消息的發(fā)
出方。如果消息包含有SIG（0）形式的驗證信息，發(fā)送方（主體）的身份就是生成SIG（0）的
KEY RR的所有者。如果消息包含了靜態(tài)配置共享加密生成的TSIG驗證信息，主體就與進行
TKEY驗證的主體相同；如果沒有驗證TKEY，就無法了解主體的信息，這樣的TSIG共享加密就
不能用于安全動態(tài)更新。
SIG（0）簽名不應由區(qū)域密碼產生，因為初始化事務的是主機和用戶而不是安全區(qū)。
更新消息可以包含DNSSEC SIG記錄（不是SIG（0）），但該記錄不能用于更新請求驗
證。
如果由于使用未授權的密碼造成更新失敗，服務器需返回RCODE REFUSED消息通知更新失
敗。其他的TSIG、SIG（0）或者動態(tài)更新錯誤根據(jù)相應的協(xié)議規(guī)定返回提示。
3 – 策略
區(qū)域管理員設置所有的安全策略，由區(qū)域的主名服務器執(zhí)行。安全策略規(guī)定了授權主體可
以執(zhí)行的授權活動。策略檢查取決于授權主體和需要的授權行為，主體來自消息簽署密碼并用
于使用該密碼簽字的動態(tài)更新消息。
服務器的安全策略定義了密碼確認的標準，決定請求的更新能否執(zhí)行。缺省條件下，不允
許主體改變區(qū)域數(shù)據(jù)，否則必須在配置中設定。
策略僅僅在主域服務器的配置中完全實現(xiàn)有幾個理由。首先避免了把策略編成固定長度的
碼的限制；其次策略僅與應用它的服務器有關，避免了泄漏；最后，策略改變或者啟用新類型
的策略不會影響DNS協(xié)議和數(shù)據(jù)格式，因而不會引起協(xié)同工作的問題。

3.1 – 標準策略Standard policies
具體運用應允許訪問控制策略把主體作為授權信令使用，也可以允許策略授權許可帶有簽
字的消息而不考略主體。
限制對域名主體的許可是一項通用的慣例。這些許可包括追加、刪除和修改與一個或者多
個域名對應的項。具體實現(xiàn)應允許針對名的訪問控制，并且應該提供關于主體的所有名、子域
和區(qū)域內全部名的精確表示。
另外，服務器應該允許對RR類型更新的限制，這樣主體就可以追加、刪除和更新特定名的
指定記錄類型。實現(xiàn)中應允許針對類型的訪問控制，并且應該提供對全部類型和“用戶”類型
的精確表示，其中用戶類型被定義為不會影響DNS操作本身。
3.1.1 – 用戶類型（User types）
用戶類型包括除SOA、NS、SIG和NXT之外的所有類型。SOA和NA記錄用于創(chuàng)建和修改授
權點，因而普通用戶不應修改這些類型。追加SIG記錄將增加分析器的工作量并可能導致攻
擊，刪除SIG記錄會給刪除區(qū)域SIG的服務器帶來額外的工作。注意，盡管不是強制性的，這
些記錄建議不要提供給普通用戶。
動態(tài)更新不得創(chuàng)建、修改或者刪除NXT記錄，因為這樣的更新會導致協(xié)議內的不穩(wěn)定。這
一點是對RFC2136的改進。
關于KEY記錄的更新在安全考慮一節(jié)討論。
3.2 – 其他策略（Additional policies）
用戶可以自由地使用任何策略。策略既可以根據(jù)需要或詳盡和簡略，也可以根據(jù)需要非常
復雜，這取決于主體或者簽名消息的其它特性。
4 – 與DNSSEC之間的相互影響
盡管本協(xié)議沒有改變安全區(qū)域的更新方式，還有幾點需要澄清。

4.1 – 增加 SIGs
授權的更新請求可能在每個RRset中都包含SIG記錄。由于SIG記錄（不包括SIG（0）記
錄）不能用于更新消息的驗證因而是不需要的。
如果主體被授權可以更新SIG記錄而且更新中存在SIG記錄，這些SIG記錄就會在未經(jīng)驗
證的情況下追加。服務器可以檢查SIG記錄并刪除以前的具有臨時有效期的SIG記錄。
4.2 – 刪除 SIGs
如果一個主體被授權更新SIG記錄，而且更新要求刪除SIG記錄，服務器可以推翻這一授
權并拒絕更新。比如，服務器可以允許刪除所有非區(qū)域碼生成的SIG記錄。
4.3 –對SIGs的模糊更新
如果更新的區(qū)域是可靠的，受到更新操作影響的RRset必須在更新完成時根據(jù)區(qū)域的簽名
策略進行簽名。這樣通常會由一個或者多個區(qū)域碼——其私有成分必須是在線的[RFC3008]——
生成一個或者多個SIG記錄。
如果改變了RRset的內容，服務器可以刪除所有相關的SIG記錄，因為它們不再有效了。
4.4 – 對區(qū)域的影響
如果需要，無論作了什么樣的改變服務器都必須產生新的SOA記錄和新的NXT記錄，并把
這些記錄簽署給相應的區(qū)域碼。安全的動態(tài)更新對NXT記錄的改變是明確禁止的。SOA更新是
允許的，因為SOA參數(shù)的維護是在DNS協(xié)議的范圍之外。
5. 安全考慮
本文要求應在一臺在線的聯(lián)網(wǎng)主機——最可能是一個名服務器——上保存區(qū)域密碼以及其
他可能的經(jīng)過加密的機密資料。這些資料的機密性完全取決于主機的安全性。如果泄露了這一
秘密將會使DNS數(shù)據(jù)面臨冒名攻擊的危險。該機器以及由該機器授權的機器所服務的區(qū)域的數(shù)
據(jù)都會受到威脅。
6.鳴謝
作者感謝下列人士對本文的審閱和有價值的建議（按字母順序）：
   Harald Alvestrand
   Donald Eastlake
   Olafur Gudmundsson
   Andreas Gustafsson
   Bob Halley
   Stuart Kwan
   Ed Lewis

7.引用

   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

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

   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
              "Dynamic Updates in the Domain Name System", RFC 2136,
              April 1997.

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

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

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
              Wellington, "Secret Key Transaction Signatures for DNS
              (TSIG)", RFC 2845, May 2000.

   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
              RR)", RFC 2930, September 2000.

   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
              (SIG(0)s)", RFC 2931, September 2000.

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.

8. 作者地址

   Brian Wellington
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA 94063

   Phone: +1 650 381 6022
   EMail: Brian.Wellington@nominum.com

9.  版權聲明

   Copyright (C) The Internet Society (2000).  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.

致謝

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



RFC 3007 Secure Domain Name System (DNS) Dynamic Update    安全的域名系統(tǒng)動態(tài)更新		1/7


1
RFC 文檔中文翻譯計劃