DNSSEC部署：山雨欲來風滿樓

文/張子蛟 高金峰 王炯煒 胡宏偉

DNSSEC部署：山雨欲來風滿樓

文/張子蛟 高金峰 王炯煒 胡宏偉

2010年5月5日，ICANN宣布已在13個根域服務器上部署DNSSEC（DNS Security Extensions，DNS安全擴展），讓業界感到非常突然。DNSSEC作為解決現有DNS體系數據安全性的一個方案，業界認為其部署和實施存在較大的困難和協議缺陷。該項工作的加速實施，可能的原因是近期很多知名網站，例如Twitter、Facebook、百度等，包括一些銀行網站被成功實施域名劫持攻擊，影響巨大。另一個可能原因是來自美國商務部的壓力。

DNS（Domain Name System域名系統）是因特網的關鍵基礎設施，其體系的核心是13臺根域服務器，由ICANN（The Internet Corporation for Assigned Names and Numbers，互聯網名稱與數字地址分配機構）負責管理。

部署DNSSEC，我們該如何應對？實際上，5月5日13個根域服務器并非正式部署DNSSEC，我們先從ICANN的DNSSEC部署時間表談起。

ICANN 的部署時間表

下面是來自I C A N N官方網站的DNSSEC部署時間表：

2009年12月1日：為VeriSign和ICANN提供內部使用的簽名根域。ICANN和VeriSign用來試驗使用KSK（Key Signing Key，密鑰簽名密鑰）對ZSK（Zone Signing Key，區域簽名密鑰）簽名的交互協議。

2010年1月：第一個根服務開始以DURZ（deliberately unvalidatable root zone，故意無效根域）的形式提供簽名根服務。這些DURZ包含無用的密鑰，用來替代根KSK和ZSK，以防止這些密鑰被正式使用。

2010年5月上旬：所有的根服務器均提供DURZ。從簽名根返回的大尺寸響應報文（大于512字節）的影響可能開始顯現。

2010年5月～6月：對DNSSEC部署的方法進行試驗，并確定DNSSEC在根域的最終部署方案。

2010年7月1日：ICANN公布根域信任錨（trust anchor），且根操作器開始使用正式密鑰提供簽名根域服務——簽名根域正式投入使用。

以上時間表暫定，可能根據實際測試結果進行調整。截止到目前，已如期執行到第三步。從時間表上看，5月5日部署的僅是DURZ，而非正式的部署，所有根服務器將繼續響應非DNSSEC域名查詢，但對僅請求DNSSEC的查詢會有所影響。總的來講，DNSSEC部署的這個步驟并未對現存的DNS體系和運行產生大的影響。

但2010年7月1日簽名根域正式投入使用時，對因特網，特別是對我國互聯網的影響和風險，需要認真評估并做出預案。

從長期看，即使全球所有域名服務器都部署了DNSSEC，新的DNS體系也應該繼續響應不支持DNSSEC的客戶端查詢，直至不支持DNSSEC的老式客戶端徹底退出因特網。

圖1 DNSSEC域名解析過程示意

DNSSEC域 名解析過程與分析

如圖1所示，以解析www.zzu.edu.cn為例，DNSSEC體系下的解析過程如下：

① 客戶端向根服務器發出解析.cn的非遞歸請求。在這之前，客戶端應該擁有根域的公鑰。

② 根服務器以根私鑰對響應報文進行簽名，響應報文包括根域服務器信息、.cn域的權威地址、.cn域的公鑰。客戶端收到報文后，以根公鑰對其進行解密驗證。

③ 客戶端向.cn服務器發出解析.edu.cn的非遞歸請求。此時，客戶端已擁有.cn公鑰。

④ .cn服務器以.cn私鑰對響應報文進行簽名，響應報文包括.cn域服務器信息、.edu.cn域的權威地址、.edu.cn域的公鑰。客戶端收到報文后，以.cn公鑰對其進行解密驗證，得到.edu.cn公鑰和其權威地址。

⑤ 客戶端向.edu.cn服務器發出解析.zzu.edu.cn的非遞歸請求。

⑥ .edu.cn服務器以.edu.cn私鑰對響應報文進行簽名，響應報文包括.edu.cn域服務器信息、.zzu.edu.cn域的權威地址、.zzu.edu.cn域的公鑰。客戶端收到報文后，以.edu.cn公鑰對其進行解密驗證，得到.zzu.edu.cn公鑰和其權威地址。

⑦ 客戶端向.zzu.edu.cn服務器發出解析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密碼算法為下級域產生一個公鑰/私鑰對，下級域的公鑰保存在本域，私鑰下發給下級域的權威服務器。由此可以看出，下發私鑰從安全上來說是一個關鍵環節。

值得一提的是，美國商務部有可能成為DNSSEC根密鑰和根域信任錨的惟一掌控者，這可能使DNSSEC的部署難以被部分專家和國家所接受。VeriSign公司作為根域的管理者之一、DNSSEC部署的重要推手和兩個炙手可熱的通用頂級域（.com與.net）的掌控者，其主營業務之一即是電子證書銷售。在DNSSEC最終的部署方案被確定之前，VeriSign公司是否會在構建DNSSEC信任鏈的電子證書方面提出有利其主營業務的訴求，我們拭目以待。

圖2 DNSSEC信任鏈示意圖

部署時機和概況

對整個因特網來講，DNSSEC的部署是一個新課題，實施的效果是否能達到預期，有待從長期的實踐中觀察。僅從部署DNSSEC的時機上來說，DNSSEC的部署還是具備了較為堅實的基礎：

截至今年，DNSSEC已有15年的技術積累。DNSSEC的固有缺陷得到逐步的彌補；

近幾年來，因特網的網絡條件提高很快，帶寬得到大幅度提高，新的設備全部支持DNSSEC，不支持DNSSEC的老設備逐步淘汰；

電子商務和社會性網絡服務日益發展，民眾對因特網的可靠性提出更高要求，而DNS欺騙日益猖獗；

2009年美國商務部在實施DNSSEC方面提出明確需求和日程表。美國的.gov域于2009年率先實施了DNSSEC；

DNS系統Kaminsky漏洞的發現；

操作系統軟件、瀏覽器軟件、DNS服務軟件的新版本（例如Windows 2008 R2、Windows 7、Bind 9等）提供對DNSSEC的完全支持；

VeriSign宣稱，2011年第一季度將在其所管理的.net和.com頂級域上全面實現DNSSEC。

綜上所述，從2009年開始，全球掀起了一個DNSSEC的部署高潮，有“山雨欲來風滿樓”之勢。

圖3 相對于DNS，DNSEC占用網絡帶寬情況

局限性和對策構想

與老DNS系統相比，DNSSEC的最大問題是標記和校驗計算增大了服務器的系統開銷，從而影響整個DNS體系的響應能力和服務性能。增大的DNS數據包，以TCP替換UDP傳輸DNS報文，加重了DNS對整個因特網連接的負擔。據測試，在NSEC3下，TCP流量相比于UDP通信增加了600倍。同樣的解析任務，DNSSEC數據流量相對DNS增加4倍多（圖3）。要緩解這個問題，一是需要升級DNS服務器硬件，二是在DNSSEC服務軟件中采用一系列優化策略，例如采用類似組播或P2P的技術，以降低DNSSEC對網絡帶寬的占用。

老DNS對抗DDos（分布式拒絕服務）攻擊沒有非常有效的辦法，采用DNSSEC后，這一點更是雪上加霜。解決的可能方案也是采用類似P2P的技術，以分布式和冗余性抗擊DDos攻擊，也提高了DNSSEC的魯棒性。

2003年以前生產的一些路由器、防火墻及其他老網絡設備，有不少不支持大DNS報文的傳輸。一種情況是會拒絕這些報文的通過，這恐怕要考慮類似IPv6 over IPv4的解決辦法；另一種情況是將大DNSSEC包拆分，這僅影響速度，無妨。

從上面的討論，我們知道，DNSSEC數據的安全性主要依賴于公鑰體系的安全性，盡管DNSSEC已從技術上采取了一系列措施，例如使用KSK、SSL傳輸等。由于DNSSEC密鑰管理體系較為復雜，協議本身也較為復雜，增加了部署、管理和維護上的負擔。這些都需要時間來解決。

另外，DNSSEC并沒有解決子域名系統自治、多DNS鏡像速度優先的問題。

DNSSEC的部署和實施是一個復雜、全球性的系統工程。DNSSEC的實施，非技術方面的問題大于技術方面，特別是對現有DNS體系的向下兼容性方面，是DNSSEC實施的成敗關鍵。作為對現有DNS基礎設施的全面升級，我們沒有理由不對其充滿信心，并為之盡一份微薄之力。

（作者單位為鄭州大學網絡管理中心）