文/張子蛟 高金峰 王炯煒 胡宏偉
DNSSEC部署:山雨欲來風滿樓
文/張子蛟 高金峰 王炯煒 胡宏偉
2010年5月5日,ICANN宣布已在13個根域服務器上部署DNSSEC(DNS Security Extensions,DNS安全擴展),讓業(yè)界感到非常突然。DNSSEC作為解決現(xiàn)有DNS體系數(shù)據(jù)安全性的一個方案,業(yè)界認為其部署和實施存在較大的困難和協(xié)議缺陷。該項工作的加速實施,可能的原因是近期很多知名網(wǎng)站,例如Twitter、Facebook、百度等,包括一些銀行網(wǎng)站被成功實施域名劫持攻擊,影響巨大。另一個可能原因是來自美國商務部的壓力。
DNS(Domain Name System域名系統(tǒng))是因特網(wǎng)的關鍵基礎設施,其體系的核心是13臺根域服務器,由ICANN(The Internet Corporation for Assigned Names and Numbers,互聯(lián)網(wǎng)名稱與數(shù)字地址分配機構)負責管理。
部署DNSSEC,我們該如何應對?實際上,5月5日13個根域服務器并非正式部署DNSSEC,我們先從ICANN的DNSSEC部署時間表談起。
下面是來自I C A N N官方網(wǎng)站的DNSSEC部署時間表:
2009年12月1日:為VeriSign和ICANN提供內(nèi)部使用的簽名根域。ICANN和VeriSign用來試驗使用KSK(Key Signing Key,密鑰簽名密鑰)對ZSK(Zone Signing Key,區(qū)域簽名密鑰)簽名的交互協(xié)議。
2010年1月:第一個根服務開始以DURZ(deliberately unvalidatable root zone,故意無效根域)的形式提供簽名根服務。這些DURZ包含無用的密鑰,用來替代根KSK和ZSK,以防止這些密鑰被正式使用。
2010年5月上旬:所有的根服務器均提供DURZ。從簽名根返回的大尺寸響應報文(大于512字節(jié))的影響可能開始顯現(xiàn)。
2010年5月~6月:對DNSSEC部署的方法進行試驗,并確定DNSSEC在根域的最終部署方案。
2010年7月1日:ICANN公布根域信任錨(trust anchor),且根操作器開始使用正式密鑰提供簽名根域服務——簽名根域正式投入使用。
以上時間表暫定,可能根據(jù)實際測試結果進行調(diào)整。截止到目前,已如期執(zhí)行到第三步。從時間表上看,5月5日部署的僅是DURZ,而非正式的部署,所有根服務器將繼續(xù)響應非DNSSEC域名查詢,但對僅請求DNSSEC的查詢會有所影響。總的來講,DNSSEC部署的這個步驟并未對現(xiàn)存的DNS體系和運行產(chǎn)生大的影響。
但2010年7月1日簽名根域正式投入使用時,對因特網(wǎng),特別是對我國互聯(lián)網(wǎng)的影響和風險,需要認真評估并做出預案。
從長期看,即使全球所有域名服務器都部署了DNSSEC,新的DNS體系也應該繼續(xù)響應不支持DNSSEC的客戶端查詢,直至不支持DNSSEC的老式客戶端徹底退出因特網(wǎng)。
圖1 DNSSEC域名解析過程示意
如圖1所示,以解析www.zzu.edu.cn為例,DNSSEC體系下的解析過程如下:
① 客戶端向根服務器發(fā)出解析.cn的非遞歸請求。在這之前,客戶端應該擁有根域的公鑰。
② 根服務器以根私鑰對響應報文進行簽名,響應報文包括根域服務器信息、.cn域的權威地址、.cn域的公鑰??蛻舳耸盏綀笪暮?,以根公鑰對其進行解密驗證。
③ 客戶端向.cn服務器發(fā)出解析.edu.cn的非遞歸請求。此時,客戶端已擁有.cn公鑰。
④ .cn服務器以.cn私鑰對響應報文進行簽名,響應報文包括.cn域服務器信息、.edu.cn域的權威地址、.edu.cn域的公鑰??蛻舳耸盏綀笪暮?,以.cn公鑰對其進行解密驗證,得到.edu.cn公鑰和其權威地址。
⑤ 客戶端向.edu.cn服務器發(fā)出解析.zzu.edu.cn的非遞歸請求。
⑥ .edu.cn服務器以.edu.cn私鑰對響應報文進行簽名,響應報文包括.edu.cn域服務器信息、.zzu.edu.cn域的權威地址、.zzu.edu.cn域的公鑰。客戶端收到報文后,以.edu.cn公鑰對其進行解密驗證,得到.zzu.edu.cn公鑰和其權威地址。
⑦ 客戶端向.zzu.edu.cn服務器發(fā)出解析www.zzu.edu.cn的非遞歸請求。
⑧ .zzu.edu.cn服務器以.zzu.edu.cn私鑰對響應報文進行簽名,響應報文包括.zzu.edu.cn域服務器信息、www.zzu.edu.cn的解析結果。客戶端收到報文后,以.zzu.edu.cn公鑰對其進行解密驗證。得到最終結果。
從上面的解析過程可知,從根域開始,由上到下逐級簽名驗證的方式稱為信任鏈(Trusted Chain),即父域與子域之間步步為營、逐級建立信任關系。根域是整個DNSSEC體系的核心和安全入口,每一個支持DNSSEC的DNS解析器都需要安裝根公鑰,以建立與根域之間的信任關系。每一個域通過RSA/SHA-1密碼算法為下級域產(chǎn)生一個公鑰/私鑰對,下級域的公鑰保存在本域,私鑰下發(fā)給下級域的權威服務器。由此可以看出,下發(fā)私鑰從安全上來說是一個關鍵環(huán)節(jié)。
值得一提的是,美國商務部有可能成為DNSSEC根密鑰和根域信任錨的惟一掌控者,這可能使DNSSEC的部署難以被部分專家和國家所接受。VeriSign公司作為根域的管理者之一、DNSSEC部署的重要推手和兩個炙手可熱的通用頂級域(.com與.net)的掌控者,其主營業(yè)務之一即是電子證書銷售。在DNSSEC最終的部署方案被確定之前,VeriSign公司是否會在構建DNSSEC信任鏈的電子證書方面提出有利其主營業(yè)務的訴求,我們拭目以待。
圖2 DNSSEC信任鏈示意圖
對整個因特網(wǎng)來講,DNSSEC的部署是一個新課題,實施的效果是否能達到預期,有待從長期的實踐中觀察。僅從部署DNSSEC的時機上來說,DNSSEC的部署還是具備了較為堅實的基礎:
截至今年,DNSSEC已有15年的技術積累。DNSSEC的固有缺陷得到逐步的彌補;
近幾年來,因特網(wǎng)的網(wǎng)絡條件提高很快,帶寬得到大幅度提高,新的設備全部支持DNSSEC,不支持DNSSEC的老設備逐步淘汰;
電子商務和社會性網(wǎng)絡服務日益發(fā)展,民眾對因特網(wǎng)的可靠性提出更高要求,而DNS欺騙日益猖獗;
2009年美國商務部在實施DNSSEC方面提出明確需求和日程表。美國的.gov域于2009年率先實施了DNSSEC;
DNS系統(tǒng)Kaminsky漏洞的發(fā)現(xiàn);
操作系統(tǒng)軟件、瀏覽器軟件、DNS服務軟件的新版本(例如Windows 2008 R2、Windows 7、Bind 9等)提供對DNSSEC的完全支持;
VeriSign宣稱,2011年第一季度將在其所管理的.net和.com頂級域上全面實現(xiàn)DNSSEC。
綜上所述,從2009年開始,全球掀起了一個DNSSEC的部署高潮,有“山雨欲來風滿樓”之勢。
圖3 相對于DNS,DNSEC占用網(wǎng)絡帶寬情況
與老DNS系統(tǒng)相比,DNSSEC的最大問題是標記和校驗計算增大了服務器的系統(tǒng)開銷,從而影響整個DNS體系的響應能力和服務性能。增大的DNS數(shù)據(jù)包,以TCP替換UDP傳輸DNS報文,加重了DNS對整個因特網(wǎng)連接的負擔。據(jù)測試,在NSEC3下,TCP流量相比于UDP通信增加了600倍。同樣的解析任務,DNSSEC數(shù)據(jù)流量相對DNS增加4倍多(圖3)。要緩解這個問題,一是需要升級DNS服務器硬件,二是在DNSSEC服務軟件中采用一系列優(yōu)化策略,例如采用類似組播或P2P的技術,以降低DNSSEC對網(wǎng)絡帶寬的占用。
老DNS對抗DDos(分布式拒絕服務)攻擊沒有非常有效的辦法,采用DNSSEC后,這一點更是雪上加霜。解決的可能方案也是采用類似P2P的技術,以分布式和冗余性抗擊DDos攻擊,也提高了DNSSEC的魯棒性。
2003年以前生產(chǎn)的一些路由器、防火墻及其他老網(wǎng)絡設備,有不少不支持大DNS報文的傳輸。一種情況是會拒絕這些報文的通過,這恐怕要考慮類似IPv6 over IPv4的解決辦法;另一種情況是將大DNSSEC包拆分,這僅影響速度,無妨。
從上面的討論,我們知道,DNSSEC數(shù)據(jù)的安全性主要依賴于公鑰體系的安全性,盡管DNSSEC已從技術上采取了一系列措施,例如使用KSK、SSL傳輸?shù)?。由于DNSSEC密鑰管理體系較為復雜,協(xié)議本身也較為復雜,增加了部署、管理和維護上的負擔。這些都需要時間來解決。
另外,DNSSEC并沒有解決子域名系統(tǒng)自治、多DNS鏡像速度優(yōu)先的問題。
DNSSEC的部署和實施是一個復雜、全球性的系統(tǒng)工程。DNSSEC的實施,非技術方面的問題大于技術方面,特別是對現(xiàn)有DNS體系的向下兼容性方面,是DNSSEC實施的成敗關鍵。作為對現(xiàn)有DNS基礎設施的全面升級,我們沒有理由不對其充滿信心,并為之盡一份微薄之力。
(作者單位為鄭州大學網(wǎng)絡管理中心)