DNSSEC 原理、配置与布署简介
本文轉載自：http://netsec.ccert.edu.cn/duanhx/archives/1479
作者：段海新，清華大學信息網絡工程研究中心
-------------------------------------------------------------------------------------------------------
?
DNSSEC 原理、配置與布署簡介
May 16, 2011 Duan Haixin作者：段海新，清華大學信息網絡工程研究中心
摘要：DNSSEC是為解決DNS欺騙和緩存污染而設計的一種安全機制。本文概要介紹DNSSEC的背景、工作原理、在BIND上的配置，最后介紹國際上的布署情況和它可能對互聯網安全體系的影響。
1? DNSSEC的背景和目的
域名系統（Domain Name System，DNS）是一些“Too simple, Too Naive”的互聯網先驅者設計的，它象互聯網的其他協議或系統一樣，在一個可信的、純凈的環境里運行得很好。但是今天的互聯網環境異常復雜，充斥著各種欺詐、攻擊，DNS協議的脆弱性也就浮出水面。對DNS的攻擊可能導致互聯網大面積的癱瘓，這種事件在國內外都屢見不鮮。
盡管DNS的安全問題一直被互聯網研究和工程領域廣為關注，但是有一種普遍存在的攻擊卻始終沒有解決，即DNS的欺騙和緩存污染問題。DNS安全擴展（DNS Security Extension, 即DNSSEC）主要是為了解決這一問題而提出的（盡管它還有其他用途）。因此，在介紹DNSSEC的原理之前有必要簡單介紹DNS欺騙和緩存污染攻擊的原理。
1.1?? DNS欺騙攻擊和緩存污染
用戶在用域名（www.example.com）訪問某一個網站時，用戶的計算機一般會通過一個域名解析服務器（Resolver Server，也稱遞歸服務器（Recursive Server））把域名轉換成IP地址。解析服務器一般需要通過查詢根域名服務器（root）、頂級域名服務器（TLD）、 權威域名服務器（Authoritative Name Server），通過遞歸查詢的方式最終獲得目標服務器的IP地址，然后交給用戶的計算機。如圖1所示。
圖1 DNS域名欺騙和緩存污染攻擊
對于上述任何一個請求(1,2,3,4)過程，攻擊者都可以假冒應答方（根、頂級域、權威域、或解析服務器）給請求方發送一個偽造的響應，其中包含一個錯誤的IP地址。發送請求的用戶計算機或者解析服務器很傻、很天真地接受了偽造的應答，導致用戶無法訪問正常網站，甚至可以把重定向到一個偽造的網站上去。由于正常的DNS解析使用UDP協議而不是TCP協議，偽造DNS的響應報文比較容易；如果攻擊者可以監聽上述過程中的任何一個通信鏈路，這種攻擊就易如反掌。
更加糟糕的是，由于DNS緩存（Cache）的作用，這種錯誤的記錄可以存在相當一段時間（比如幾個小時甚至幾天），所有使用該域名解析服務器的用戶都無法訪問真正的服務器。根據[1]，由于眾所周知的原因，中國幾乎所有的解析服務器的緩存都已經被嚴重的污染了，給用戶的訪問、網絡的管理帶來了很多困難。攻擊者可能是黑客、網絡管理者等等，但本文不去討論這些攻擊者的身份和動機。
1.2?? DNSSEC的目標、歷史和意義
上述攻擊能夠成功的原因是DNS 解析的請求者無法驗證它所收到的應答信息的真實性，而DNSSEC給解析服務器提供了防止上當受騙的武器，即一種可以驗證應答信息真實性和完整性的機制。利用密碼技術，域名解析服務器可以驗證它所收到的應答（包括域名不存在的應答）是否來自于真實的服務器，或者是否在傳輸過程中被篡改過。
盡管從原理上來說DNSSEC并不復雜，但是從1997年第一個有關DNSSEC的標準RFC 2065 [2] 發布至今已經十多年了，直到最近一兩年才有了可觀的進展。1999年IETF對DNSSEC標準進行了修訂RFC 2535[3]，但很快被證明這次修訂是失敗的。直到2005年，一個可用的DNSSEC標準才制定出來（RFC 4033-4035）[4][5][6]，目前主流域名服務軟件（如BIND ）實現的也是這一版本。2008年，IETF又發布了一個NSEC3（RFC5155）[7]標準，以提高DNSSEC隱私保護能力。 隨著DNSSEC的推廣，也許還會有一些新的問題和新的修訂，DNSSEC標準仍在發展過程中。
盡管DNSSEC的目標僅限于此（即不保護DNS信息的保密性和服務的可用性），但是，DNSSEC的成功布署對互聯網的安全還有其他好處，比如提高電子郵件系統的安全性，甚至把DNS作為一個公鑰基礎設施（PKI）。
本文所介紹的DNSSEC工作原理基于RFC 4033-4035，關于DNS工作原理、配置和數字簽名技術超出了本文的范圍，感興趣的讀者可以參考[8]。在此基礎上簡單介紹最常用的域名服務系統（BIND）的基本配置過程，最后DNSSEC在國際上的布署情況以及可能給網絡安全帶來的影響。
2? DNSSEC原理
簡單的說，DNSSEC依靠數字簽名保證DNS應答報文的真實性和完整性。權威域名服務器用自己的私有密鑰對資源記錄（Resource Record, RR）進行簽名，解析服務器用權威服務器的公開密鑰對收到的應答信息進行驗證。如果驗證失敗，表明這一報文可能是假冒的，或者在傳輸過程、緩存過程中被篡改了。 RFC 4033概要介紹了DNSSEC所提供的安全功能并詳細介紹了相關的概念，下面通過一個簡化的實例介紹DNSSEC的工作原理 。
如圖2所示，一個支持DNSSEC的解析服務器（RFC4033中Security-Aware Resolver）向支持DNSSEC的權威域名服務器（Security-Aware Name Server）請求域名www.test.net.時，它除了得到一個標準的A記錄（包含IPv4地址）以外，還收到一個同名的RRSIG記錄，其中包含test.net這個權威域的數字簽名，它是用test.net.的私有密鑰來簽名的。為了驗證這一簽名的正確性，解析服務器可以再次向test.net的域名服務器查詢響應的公開密鑰，即名為test.net的DNSKEY類型的資源記錄。然后解析服務器就可以用其中的公鑰驗證上述www.test.net. 記錄的真實性與完整性。
圖2 DNSSEC基本工作原理
但是，解析服務器如何保證它所獲得的test.net.返回的公開密鑰（DNSKEY記錄）是真實的而不是假冒的呢？ 盡管test.net.在返回DNSKEY記錄的同時，也返回對這個公鑰的數字簽名（名為test.net的RRSIG記錄）；但是，攻擊者同樣可以同時偽造公開密鑰和數字簽名兩個記錄而不被解析者發現。
象基于X509的PKI體系一樣，DNSSEC也需要一個信任鏈，必須有一個或多個開始就信任的公鑰（或公鑰的散列值），在RFC 4033中稱這些初始信任的公開密鑰或散列值為“信任錨（Trust anchors）”。信任鏈中的上一個節點為下一個節點的公鑰散列值進行數字簽名，從而保證信任鏈中的每一個公鑰都是真實的。理想的情況下（DNSSEC全部布署），每個解析服務器只需要保留根域名服務器的DNSKEY就可以了。
在上面的例子中，假設解析服務器開始并不信任test.net.的公開密鑰， 它可以到test.net.的上一級域名服務器net.那里查詢test.net.的DS（Delegation Signer， 即DS RR）記錄，DS RR中存儲的是test.net. 公鑰的散列值（比如用SHA-1算法計算得到的160比特數據的16進制表示）。假設解析服務器由管理員手工配置了.net的公鑰（即Trust Anchor），它就可以驗證test.net.公鑰（DNSKEY）的正確與否了。
2.1?? DNSSEC的資源記錄
為了實現資源記錄的簽名和驗證，DNSSEC增加了四種類型的資源記錄： RRSIG（Resource Record Signature）、DNSKEY(DNS Public Key)、DS(Delegation Signer)、NSEC(Next Secure)。前三種記錄已經在上面的實例中提到了，NSEC記錄是為響應某個資源記錄不存在而設計的。具體的說明參見RFC 4034，本文概要介紹如下。
2.1.1 ?DNSKEY記錄
DNSKEY資源記錄存儲的是公開密鑰，下面是一個DNSKEY的資源記錄的例子：
example.com. 86400 ?IN ?DNSKEY ?256 ?3 ?5? ( AQPSKmy….. aNvv4w==? )
其中256是標志（flag）字段，它是一個16比特的數，如果第7位（左起為第0位。這一位是區密鑰（Zone Key）標志, 記為ZK）為1，則表明它是一個區密鑰，該密鑰可以用于簽名數據的驗證，而且資源記錄的所有者（example.com.）必須是區的名字。第15位稱為安全入口點（Security Entry Point，SEP）標志，將在下面介紹。
下一個字段“3”是協議（protocol）字段，它的值必須是3，表示這是一個DNSKEY，這是為了與以前版本DNSSEC兼容而保留下來的。其他的值不能用于DNSSEC簽名的驗證。
下一個字段“5”是算法（Algorithm）字段，標識簽名所使用的算法的種類。其中常用的幾種：1：RSA/MD5; 3：DSA/SHA-1; 5 RSA/SHA-1;
最后括號中的是公開密鑰（Public Key）字段，它的格式依賴于算法字段。
在實踐中，權威域的管理員通常用兩個密鑰配合完成對區數據的簽名。一個是Zone-Signing Key(ZSK)，另一個是Key-Signing Key(KSK)。ZSK用于簽名區數據，而KSK用于對ZSK進行簽名。這樣做的好處有二：
（1）用KSK密鑰簽名的數據量很少，被破解（即找出對應的私鑰）概率很小，因此可以設置很長的生存期。這個密鑰的散列值作為DS記錄存儲在上一級域名服務器中而且需要上級的數字簽名，較長的生命周期可以減少密鑰更新的工作量。
（2）ZSK簽名的數據量比較大，因而破解的概率較大，生存期應該小一些。因為有了KSK的存在，ZSK可以不必放到上一級的域名服務中，更新ZSK不會帶來太大的管理開銷（不涉及和上級域名服務器打交道）。
2.1.2 RRSIG記錄
RRSIG資源記錄存儲的是對資源記錄集合（RRSets）的數字簽名。下面是對一個A記錄簽名后得到的RRSIG記錄：
host.example.com. 86400 IN RRSIG? A? 5? 3? 86400 20030322173103 (
20030220173103? 2642? example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
…
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
從第五個字段（“A”）開始各字段的含義如下：
類型覆蓋（The Type Covered Field）：表示這個簽名覆蓋什么類型的資源記錄，本例中是A；
算法：數字簽名算法，同DNSKEY記錄的算法字段；本例中5表示RSA/SHA-1。
標簽數量（The Labels Field）：被簽名的資源域名記錄所有者（host.example.com.）中的標簽數量，如本例中為3，*.example.com.為2，“.”的標簽數量為0。
接下來的幾個字段分別是被簽名記錄的TTL、有效期結束時間、開始時間。
然后（2642）是密鑰標簽（Key Tag），它是用對應公鑰數據簡單疊加得到的一個16比特整數。如果一個域有多個密鑰時（如一個KSK、一個ZSK），Key Tag可以和后面的簽名者字段（example.com.）共同確定究竟使用哪個公鑰來驗證簽名。
2.1.3 ?DS記錄
DS（Delegation Signer）記錄存儲DNSKEY的散列值，用于驗證DNSKEY的真實性，從而建立一個信任鏈。不過，不象DNSKEY存儲在資源記錄所有者所在的權威域的區文件中，DS記錄存儲在上級域名服務器（Delegation）中，比如example.com的DS RR存儲在.com的區中。
下面是一個DS記錄的實例：
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A98631FAD1A292118 )
DS 之后的字段依次是密鑰標簽（Key Tag）、算法、和散列算法（1代表 SHA-1）。后面括號內的內容是dskey.example.com.密鑰SHA-1計算結果的16進制表示。Example.com必須為這個記錄數字簽名，以證實這個DNSKEY的真實性。
2.1.4 ?NSEC記錄
NSEC記錄是為了應答那些不存在的資源記錄而設計的。為了保證私有密鑰的安全性和服務器的性能，所有的簽名記錄都是事先（甚至離線）生成的。服務器顯然不能為所有不存在的記錄事先生成一個公共的“不存在”的簽名記錄，因為這一記錄可以被重放（Replay）；更不可能為每一個不存在的記錄生成獨立的簽名，因為它不知道用戶將會請求怎樣的記錄。
在區數據簽名時，NSEC記錄會自動生成。比如在vpn.test.net和xyz.test.net之間會插入下面的這樣兩條記錄：
vpn.test.net.?? 10800?? IN A??? ???192.168.1.100
172800? NSEC??? xyz.test.net. A RRSIG NSEC
172800? RRSIG?? NSEC 5 5 172800 20110611031416 (
20110512031416 5271 test.net.
Ujw/aq….15dV5tF7XgWSR78= )
xyz.test.net.? 10800?? IN A??? 192.168.1.200
其中NSEC記錄包括兩項內容：排序后的下一個資源記錄的名稱（xyz.test.net.）、以及vpn.test.net.這一名稱所有的資源記錄類型（A、RRSIG、NSEC），后面的RRSIG記錄是對這個NSEC記錄的數字簽名。
在用戶請求的某個域名在vpn和xyz之間時，如www.test.net.，服務器會返回域名不存在，并同時包括 vpn.test.net的NSEC記錄。
2.2?? DNSSEC對現有DNS協議的修改
由于新增DNS資源記錄的尺寸問題，支持DNSSEC的域名服務器必須支持EDNS0（RFC2671），即允許DNS報文大小必須達到1220字節（而不是最初的512字節），甚至可以是4096字節。
DNSSEC在報文頭中增加了三個標志位：
（1）DO（DNSSEC OK, 參見RFC3225）：支持DNSSEC的解析服務器在它的DNS查詢報文中，必須把DO標志位置1，否則權威域服務器認為解析器不支持DNSSEC就不會返回RRSIG等記錄。
（2）AD （Authentic Data）：AD是認證數據標志，如果服務器驗證了DNSSEC相關的數字簽名，則置AD位為1，否則為0。這一標志位一般用于自己不做驗證的解析器（non-validating security-aware resolvers）和它所信任的遞歸解析服務器（security-aware recursive name server）之間，用戶計算機上的解析器自己不去驗證數字簽名，遞歸服務器給它一個AD標志為1的響應，它就接受驗證結果。這種場景只有在它們之間的通信鏈路比較安全的情況下才安全，比如使用了IPSEC和TSIG[]。
（3）CD （Checking Disabled）： 關閉檢查標志位用于支持DNSSEC驗證功能的解析器（validating security-aware resolver）和遞歸域名服務器之間，解析器在發送請求時把CD位置1，服務器就不再進行數字簽名的驗證而把遞歸查詢得到的結果直接交給解析器，由解析器自己驗證簽名的合法性。
最后，支持驗證的DNSSEC 解析器對它所收到的資源記錄的簽名（RRSIG），必須能夠區分區分以下四種結果：
（1）安全的（secure）：解析器能夠建立到達資源記錄簽名者的信任鏈，并且可以驗證數字簽名的結果是正確的。
（2）不安全的（insecure）：解析器收到了一個資源記錄和它的簽名，但是它沒有到達簽名者的信任鏈，因而無法驗證。
（3）偽造的（Bogus）：解析器有一個到資源記錄簽名者的信任鏈，但是簽名驗證是錯的。可能是因為受到攻擊了，也可能是管理員配置錯誤。
（4）不確定（Indeterminate）：解析器無法獲得足夠的DNSSEC 資源記錄，因而不能確定用戶所請求的資源記錄是否應該簽名。
3? DNSSEC的配置
盡管DNSSEC的工作原理看起來讓人氣餒，實際的配置操作卻并不復雜。本節以BIND 9為例介紹DNSSEC的基本配置。盡管BIND 9.3以上就開始支持DNSSEC，仍然建議使用當前最高版本的BIND（當前最新的版本是9.8）。
配置或布署DNSSEC有兩種場景：
（1）配置安全的域名解析服務器（Resolver），該服務器可以保護使用它的用戶，防止被DNS 欺騙攻擊。這里只涉及數字簽名的驗證工作。
（2）配置安全的權威域名服務器（Name Server），對權威域的資源記錄進行簽名，保護服務器不被域名欺騙攻擊。
3.1?? 配置安全解析服務器
3.1.1 激活DNSSEC
首先，在BIND的配置文件（一般是/etc/named.conf）中打開DNSSEC選項，比如：
options {
directory “/var/named”;
dnssec-validation yes;
….
};
3.1.2 配置Trust anchor
其次，要給解析服務器配置可信錨（Trust Anchors），也就是你所信任的權威域的DNSKEY。理想情況下我們可以配置一個根的密鑰就夠了，但是目前DNSSEC還沒有完全布署的情況下，我們需要配置很多安全島（Secure Island）的密鑰。可以從很多公開的網站下載這些可信域的DNSKEY文件，包括：
（1）Root Zone DNSSEC Trust Anchors：https://www.iana.org/dnssec/。2010年7月布署實施。如果DNSSEC全部布署成功，這一個公開密鑰就足夠了。
（2）The UCLA secspider ： https://secspider.cs.ucla.edu，由美國加州大學洛杉磯分校（UCLA）張麗霞教授的實驗室維護。
（3）The IKS Jena TAR：https://www.iks-jena.de/leistungen/dnssec.php
這些文件大概是這樣的格式：
trusted-keys {
“test.net.” ?256 3 5? “AQPzzTWMz8qS…3mbz7Fh
……
….fHm9bHzMG1UBYtEIQ==”;
“193.in-addr.arpa.” 257 3 5 “AwEAAc2Rn…HlCKscYl
kf2kOcq9xCmZv….XXPN8E=”;
};
假設上述trust anchors的文件為/var/named/trust-anchors.conf，則在/etc/named.conf中增加下面一行：
include “/var/named/sec-trust-anchors.conf”;
3.1.3 測試
在完成上述配置修改之后重新啟動named進程，然后選擇一個trust anchor文件中有的區或者它下一級的域名，在解析服務器上用dig測試一下，例如：
#dig @127.0.0.1 +dnssec? ?test.net.? SOA
如果配置正確，應該返回test.net的SOA記錄和相應的RRSIG記錄，另外返回的頭部中應該包含AD標志位，表示DNSSEC相關的數字簽名驗證是正確的，類似下面的樣子：
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1397
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
如果沒有得到期望的結果，需要查看DNS的日志來找出問題。BIND為DNSSEC相關的事件增加了一個dnssec類別，可以在/etc/named.conf配置日志如下：
logging {
channel dnssec_log {
file “log/dnssec” size 20m;? ?// a DNSSEC log channel 20m;
print-time yes; ??????????????????// timestamp the entries
print-category yes; ?????????// add category name to entries
print-severity yes; ?????????// add severity level to entries
severity debug 3;??????? ?// print debug message <= 3 t
};
};
category dnssec { dnssec_log; };
3.2?? 配置權威服務器
3.2.1 生成簽名密鑰對
首先為你的區（zone）文件生成密鑰簽名密鑰KSK：
# cd /var/named
# dnssec-keygen -f KSK -a RSASHA1 -b 512 -n ZONE test.net.
Ktest.edu.+005+15480
然后生成區簽名密鑰ZSK：
# dnssec-keygen -a RSASHA1 -b 512 -n ZONE test.net.
Ktest.edu.+005+03674
其中的-a 參數是簽名算法，-b是密鑰長度。上述命令共產生兩對DNSKEY密鑰（共四個文件），分別以.key和.private結尾，表明這個文件存儲的是公開密鑰或私有密鑰。
3.2.2 簽名
簽名之前，你需要把上面的兩個DNSKEY寫入到區文件中
#cat “$INCLUDE Ktest.net.+005+15480.key” >> db.test.net
# cat “$INCLUDE Ktest.net.+005+03674.key” >> db.test.net
然后執行簽名操作：
# dnssec-signzone -o test.net. db.test.net
db.test.net.signed
上面的-o選項指定代簽名區的名字。生成的db.test.net.signed
然后修改/etc/named.conf如下：
options? {
directory “/var/named”;
dnssec-enable yes;
};
zone “test.net” {
type master;
file “db.test.net.signed”;
};
記住，你每次修改區中的數據時，都要重新簽名：
# dnssec-signzone -o test.net -f db.test.net.signed.new db.test.net.signed
# mv db.test.net.signed db.test.net.signed.bak
# mv db.test.net.signed.new db.test.net.signed
# rndc reload test.net
3.2.3 發布公鑰
要讓其他人驗證你的數字簽名，其他人必須有一個可靠的途徑獲得你的公開密鑰。DNSSEC通過上一級域名服務器數字簽名的方式簽發你的公鑰。
用dnssec-signzone時，會自動生成keyset-文件和dsset-開頭的兩個文件，分別存儲著KSK的DNSKEY記錄和DS記錄。作為test.net區的管理員，你需要把這兩個文件發送給.net的管理員，.net的管理員需要把這兩條記錄增加到.net區中，并且用.net的密鑰重新簽名。
test.net.????????????? 86400?? IN NS?? ns.test.net.
86400?? DS????? 15480 5 1 (
F340F3A05DB4D081B6D3D749F300636DCE3D
6C17 )
86400?? RRSIG?? DS 5 2 86400 20060219234934 (
20060120234934 23912?? net.
Nw4xLOhtFoP0cE6ECIC8GgpJKtGWstzk0uH6
……
YWInWvWx12IiPKfkVU3F0EbosBA= )
如果你的上一級域名服務器還沒有配置DNSSEC，你不得不另找其他方式了，比如，把上述兩個文件提交到一些公開的trust anchor數據庫中發布(如上面介紹過的secspider)，或者直接交給愿意相信你的解析服務器的管理員，配置到他們的trust anchor文件中。
4 DNSSEC的布署
互聯網工程技術領域普遍認為DNSSEC是增強互聯網基礎設施安全非常關鍵的一步，比如，美國國土安全部發起了DNSSEC布署計劃，美國網絡空間國家戰略安全明確要求布署DNSSEC。DNSSEC的大規模布署還可能解決其他的安全問題，比如密鑰的分發和安全的電子郵件。
盡管互聯網工程界認為DNSSEC非常重要，但是大規模的布署仍然非常謹慎。巴西 (.br)、保加利亞 (.bg)、捷克 (.cz)、波多黎各 (.pr) 和瑞典 (.se), 很早就開始了在他們國家的頂級域名上布署DNSSEC，IANA在2007年開始在一個根域名服務器上進行簽名試驗。許多機構在DNSSEC的布署上付出了巨大的努力，具體請參見[9]。
在ICANN和VeriSign的推動下，2010年7月所有13個根域名服務器都用對根域簽名完畢且投入運營[10]。頂級域名（如.org, .net等）也在計劃之中，有些國家級的頂級域名服務器（如.cz、.jp、.us、.fr等）已經完成了這一任務。
國際上一些大的ISP已經開始布署支持DNSSEC的解析服務器，以保護他們接入用戶的安全，美國Comcast 公司是其中的先驅者之一。
5? 總結與展望
本文概要介紹了DNSSEC的目標、原理、基本配置與當前的布署情況。由于篇幅和作者的經驗、精力有限，無法對一些細節展開討論， 感興趣的讀者可以閱讀后面的參考文獻。
作者認為如果DNSSEC能夠普遍布署，可能給互聯網的安全體系產生重大的影響；因為有了DNSSEC的數字簽名，把DNS作為密鑰分發的PKI在很多應用場合已經具有了可行性。它不僅僅可以加強DNS系統本身的安全，作為網絡的基礎設施，還給其他的應用、特別是端到端的移動通信、IPv6網絡環境的安全問題提供新的解決辦法。
但是作者也認為，離這一目標的實現還有很長的路要走。一方面DNSSEC自身的協議還在發展，另一方面其他的應用要想利用DNSSEC的機制還需要大規模的研究試驗和最后的標準化。另外，DNSSEC在某些國家是否會遭遇政策性的阻礙，也是個未知數。
盡管如此，因為DNS對互聯網實在太重要了；如果DNSSEC是通往一個安全可靠的互聯網基礎設施的必由之路（目前作者還沒有看到可以替代DNSSEC的其他解決方案），為此所付出的代價，也是別無選擇的。
6?? 參考文獻
[1] Graham Lowe, Patrick Winters, Michael L. Marcus. The Great DNS Wall of China， December 21, 2007.? http://cs.nyu.edu/~pcw216/work/nds/final.pdf
[2] RFC 2065,Domain Name System Security Extensions, 1997.http://www.ietf.org/rfc/rfc2065.txt
[3] RFC 2535,Domain Name System Security Extensions,1999,http://www.ietf.org/rfc/rfc2535.txt
[4] RFC 4033, DNS Security Introduction and Requirements,2005, http://www.ietf.org/rfc/rfc4033.txt
[5] RFC4034,Resource Records for the DNS Security Extensions,2005,http://www.ietf.org/rfc/rfc4034.txt
[6] RFC4035,Protocol Modifications for the DNS Security Extensions,2005,http://www.ietf.org/rfc/rfc4035.txt
[7] RFC5155,DNS Security (DNSSEC) Hashed Authenticated Denial of Existence,2008,http://www.ietf.org/rfc/rfc5155.txt
[8] Paul Albitz, Cricket Liu, DNS and BIND 5th Edition, O’Reilly Publication, 2008
[9] Wikipedia, Domain Name System Security Extensions, http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
[10] Root DNSSEC update, 2010, http://www.root-dnssec.org/2010/07/16/status-update-2010-07-16/
This entry was posted in 網絡安全 and tagged DNS. Bookmark the permalink.本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/wuwentao2000/archive/2011/05/26/6448666.aspx
總結
以上是生活随笔為你收集整理的DNSSEC 原理、配置与布署简介的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： DNS协议报文(RFC1035)
- 下一篇： RYSNC使用说明