DNSSec 調(diào)研報告劉冰洋2008310477清華大學計算機科學與技術(shù)系，北京，100084摘 要：DNS （域名系統(tǒng)）已成為互聯(lián)網(wǎng)服務(wù)的重要基礎(chǔ)設(shè)施，但它存在著嚴重的安全漏洞，近年來針對這些安全漏

DNSSec 調(diào)研報告

劉冰洋2008310477

清華大學計算機科學與技術(shù)系，北京，100084

摘 要：DNS （域名系統(tǒng)）已成為互聯(lián)網(wǎng)服務(wù)的重要基礎(chǔ)設(shè)施，但它存在著嚴重的安全漏洞，近年來針對這些安全漏洞的網(wǎng)絡(luò)攻擊給DNS 和互聯(lián)網(wǎng)帶來了巨大的損失。DNSSec 為DNS 提供了安全擴展功能，支持對數(shù)據(jù)源及事務(wù)和請求的認證，從而在一定程度上遏制了相關(guān)的網(wǎng)絡(luò)攻擊。本文回顧了DNS 的發(fā)展歷程與其面臨的安全威脅，介紹了DNSSec 的基本原理和組成部分，分析了DNSSec 存在的問題，調(diào)研了DNSSec 在全球的部署情況，并對其未來應用進行了展望。

關(guān)鍵詞：DNS, DNSSec, DNS安全, 互聯(lián)網(wǎng)安全.

Abstract : DNS (Domain Name System) is now a very important infrastructure of the Internet. However, it was designed with a lot of vulnerability. These years, the network attacks taking advantages of its vulnerability have brought huge damage to the DNS and Internet. DNSSec, the security extension of DNS, was designed to secure DNS. It supports the authentication of the data origin and transaction and request, so that it mitigates the relevant attacks. This paper reviews the history of DNS and its vulnerability, and introduces the rationale of DNSSec. We analyzed the problems in DNSSec, investigated its deployment progress around the world, and also presented the future application of DNSSec.

Keywords : DNS, DNSSec, Internet Security.

1 引言

1.1 DNS 發(fā)展歷程

DNS （Domain Name System，域名系統(tǒng)）[1]出現(xiàn)之前，網(wǎng)絡(luò)用戶需要在本機上維護一個HOSTS 配置文件，這個文件包含本機與網(wǎng)絡(luò)上的其他系統(tǒng)通信時所需要的信息。當網(wǎng)絡(luò)變得復雜時，這樣做的缺點是顯然的：每臺機器都需要手工維護一個HOSTS 文件，某一臺機器的配置更新將導致每臺與其通信的機器修改配置，網(wǎng)絡(luò)規(guī)模增大時手工維護HOSTS 文件是不可行的。

1983年，在TCP/IP部署后不久，域名系統(tǒng)——即DNS ——被發(fā)明了出來。該系統(tǒng)用于命名組織到域?qū)哟谓Y(jié)構(gòu)中的計算機和網(wǎng)絡(luò)服務(wù)[2]。DNS 負責將易于記憶的域名與計算機的IP 地址映射起來，供用戶查詢。DNS 于1983年成為國際標準，RFC882[3]和RFC883[4]分別描述了DNS 的概念和實現(xiàn)說明。DNS 大大推動了互聯(lián)網(wǎng)、尤其是萬維網(wǎng)的發(fā)展，逐漸成為全球性的重要互聯(lián)網(wǎng)基礎(chǔ)設(shè)施。

DNS 是一個樹狀結(jié)構(gòu)，根域名為“. ”；頂級域名包括“.com ”、“.net ”、“.org ”、“.edu ”、“.gov ”等，還包括各國家和地區(qū)的頂級域名，如“.cn ”、“.au ”等。每個域又可以下設(shè)多

個子域，子域又可以再設(shè)子域，如此迭代下去。每個域內(nèi)設(shè)置多臺（一般至少為兩臺）域名服務(wù)器（Name Server），負責分配子域域名、維護域名到IP 地址映射關(guān)系的記錄。

DNS 中的另外一種實體是域名解析服務(wù)器（Resolver ），它負責為客戶主機（Client ）提供域名解析（即域名查詢）的服務(wù)。它將一些域名到IP 地址的映射記錄保存到本地，稱為“緩存”，緩存需要定時更新。當用戶所要查詢的域名在這個緩存中沒有命中時，它需要代理用戶去查詢該域名的權(quán)威域名服務(wù)器，并將查詢結(jié)果轉(zhuǎn)發(fā)給用戶。這個“代理查詢”的過程是從DNS 樹的根節(jié)點開始，逐級向下遞歸查找，直到收到權(quán)威域名服務(wù)器的應答或請求超時。

邏輯上域名服務(wù)器與域名解析服務(wù)器是兩個不同的概念和實體，而在現(xiàn)實的應用中，往往將二者合并起來，即一臺域名服務(wù)器往往也提供了域名解析的服務(wù)——通常被統(tǒng)稱為DNS 服務(wù)器。

下圖給出了一個DNS 的查詢過程的例子，主機（Client ）向本地DNS 服務(wù)器（DNS Server）提交對域名“contoso.com ”的查詢請求，若該服務(wù)器的緩存中存在些條目，則向主機返回結(jié)果并結(jié)束此次查詢，否則，它將向根域名服務(wù)器（Root Server）提交查詢請求；根域名服務(wù)器將其指向“.com ”的頂級域名服務(wù)器（Com Server），后者再將其指向“contoso.com ”的權(quán)威域名服務(wù)器（Contoso Server）；最后由它把結(jié)果返回給本地DNS 服務(wù)器，后者將結(jié)果返回給查詢的主機。此次過程結(jié)束后，本地域名服務(wù)器可能會將“contoso.com ”的記錄保存到自己的緩存中，這樣，下次有主機查詢該域名時，就可以直接返回緩存中的結(jié)果了。

圖 1 DNS查詢實例

1.2 DNS 的安全隱患

正如互聯(lián)網(wǎng)早期的許多協(xié)議一樣，DNS 協(xié)議在設(shè)計之初也沒有考慮到安全問題，所以在其不斷的發(fā)展和應用過程中暴露了許多的安全漏洞，并出現(xiàn)了一些有針對性的安全攻擊。比如：DNS 緩存污染（DNS Cache Poisoning）[5]、DNS 放大攻擊（DNS Amplification Attack）

[6]、DNS 客戶洪泛攻擊（Client Flooding）[7]、DNS 動態(tài)更新攻擊（DNS Dynamic Update Vulnerabilities ）[7]、域名欺詐（Domain Name Phishing）[8]等等。

這些安全問題中，DNS 緩存污染被認為是關(guān)系到互聯(lián)網(wǎng)核心安全的決定性問題之一[9]。DNS 緩存污染是指一個DNS 解析服務(wù)器被注入了錯誤的緩存，比如將域名A 指向了域名B 的IP 地址。所謂的“注入”，即指該解析服務(wù)器在查詢某域名記錄時，接受了一個非權(quán)威域名服務(wù)器的錯誤回應，并將該錯誤回應保存到自己的緩存中。這種非權(quán)威域名服務(wù)器的“錯誤回應”可能由其錯誤的配置造成，可能是被黑客利用，也可能根本就不是域名服務(wù)器、而是黑客的一臺計算機（比如實施中間人攻擊）。通過DNS 緩存污染，可以造成用戶無法正常訪問網(wǎng)絡(luò)（DoS ），可以將用戶導向一個其不期望訪問的網(wǎng)站（進而實施竊取信息、詐騙等），也可以將很多用戶導向一個目標網(wǎng)站并使其癱瘓（DDoS ）。由于DNS 緩存污染攻擊易于發(fā)起、危害巨大，逐漸成為互聯(lián)網(wǎng)的重要安全威脅，也是成為了網(wǎng)絡(luò)管理人員十分頭疼的安全問題。

1.3 DNSSec 簡介

DNSSec 是DNS Security Extensions（DNS 安全擴展）的縮寫[10]。由于DNS 協(xié)議的安全漏洞和目前嚴重的安全問題，IETF 成立了dnssec 工作組（后來被取代為dnsext （DNS Extensions ）工作組[11]），研究DNS 協(xié)議的安全擴展。DNS 安全擴展制訂了一系列RFC ，包括概念技術(shù)、協(xié)議設(shè)計、報文格式、哈希算法、密鑰管理等多方面。這些RFC 幾經(jīng)更新，目前較為廣泛接受的協(xié)議描述是RFC2535[12]，該協(xié)議在RFC4035進行了更新[13]。由于有關(guān)DNSSec 的一系列RFC 還在設(shè)計中，尚未有定論，本文主要介紹RFC2535中所描述的DNSSec 。

DNSSec 的目標是為DNS 解析服務(wù)器（Resolver ）提供數(shù)據(jù)源認證和數(shù)據(jù)完整性驗證的功能。通過DNSSec 的部署，可以增強對DNS 域名服務(wù)器的身份認證，進而幫助防止DNS 緩存污染等攻擊——DNSSec 是實現(xiàn)DNS 安全的重要一步和必要組成部分。

1.4 本文主要內(nèi)容與文章結(jié)構(gòu)

本文主要介紹DNSSec 的原理，分析可能存在的問題，調(diào)研其部署現(xiàn)狀，并對分析其應用前景。

本文后續(xù)部分組織如下：第2章介紹DNSSec 的原理和組成部分；第3章對DNSSec 進行分析，指出其可能存在的問題；第4章介紹DNSSec 的部署現(xiàn)狀，并對其未來的應用前景進行分析；第5章總結(jié)全文；致謝和參考文獻分別在第6和第7章。

2 DNSSec 的原理與組成

2.1 DNSSec 的目標

DNSSec 協(xié)議的設(shè)計要遵循以下目標和設(shè)計原則：

1) 為DNS 解析服務(wù)提供數(shù)據(jù)源身份認證和對數(shù)據(jù)完整性驗證。從而扼制DNS 緩存污

染等攻擊。

2) 不強制進行訪問控制或者數(shù)據(jù)加密。DNS 是一個公共的網(wǎng)絡(luò)服務(wù)基礎(chǔ)設(shè)施，不能因

為訪問控制或數(shù)據(jù)加密的引入破壞這一基本前提，但是DNSSec 也不強制不能進行數(shù)據(jù)的加密。

3) 向后兼容。即DNSSec 協(xié)議的數(shù)據(jù)可以被舊版本的DNS 協(xié)議正確存儲和分發(fā)（盡

管可能無法正確解釋）。

4) 支持增量部署?；ヂ?lián)網(wǎng)中一部分部署了DNSSec 的域可以在其它域不部署DNSSec

的情況下實現(xiàn)部署收益。

2.2 DNSSec 的基本原理

DNSSec 利用哈希算法計算報文摘要，從而實現(xiàn)數(shù)據(jù)完整性驗證；利用公鑰機制實現(xiàn)對數(shù)據(jù)源的認證。簡單地來看：部署了DNSSec 的權(quán)威域名服務(wù)器在應答查詢請求時，首先使用哈希算法計算應答報文的摘要，再將此摘要用自己的私鑰加密生成簽名后存儲到報文中；查詢方收到應答報文，利用該服務(wù)器的公鑰解密簽名獲得摘要，再將此摘要與從報文數(shù)據(jù)計算出的摘要進行對比來完成數(shù)據(jù)的完整性的驗證。如果數(shù)據(jù)完整性驗證成功，則也同時完成了對數(shù)據(jù)源（權(quán)威域名服務(wù)器）的身份認證，否則認識身份認證失敗。

DNSSec 可以在以下三種實體上進行部署：DNS 域名服務(wù)器（Name Server）、DNS 解析服務(wù)器（Resolver ）、DNS 客戶端（Client ）。

2.3 DNSSec 的組成部分

DNSSec 由以下幾個部分組成：

1) 密鑰分發(fā)

DNSSec 的密鑰（尤指屬于某一域名的公鑰）分發(fā)機制不僅可以分發(fā)用于DNS 域驗證的公鑰，而且可以支持與域名有關(guān)的非以DNS 目的的其它信息的分發(fā)。公鑰的分發(fā)支持多種密鑰類型和多種密鑰算法。具體的密鑰分發(fā)系統(tǒng)和密鑰算法暫不討論。

2) 數(shù)據(jù)源認證

數(shù)據(jù)源認證是DNSSec 設(shè)計的核心目標。其基本原理已經(jīng)在2.1節(jié)中進行了描述。

3) DNS 事務(wù)與請求認證

DNS 事務(wù)與請求認證是為了對DNS 的查詢請求和DNS 消息頭進行驗證。這項驗證保證了域名服務(wù)器的請求應答可以達到請求的發(fā)送者、并且該應答來自請求者想要查詢的服務(wù)器。要做到這些，只需要對回送的應答報文的簽名進行一些處理——即，使用一些與請求和應答相關(guān)聯(lián)的信息來生成簽名——這樣，就一舉兩得地實現(xiàn)了雙向認證。

3 DNSSec 協(xié)議分析

3.1 安全性分析

DNSSec 借助公鑰機制對數(shù)據(jù)完整性和數(shù)據(jù)源進行驗證（在事務(wù)與請求認證中，也提供了對請求方的身份認證）。通過數(shù)據(jù)源認證，可以在一定程度上遏制DNS 緩存污染和DNS 客戶洪泛攻擊；通過事務(wù)與請求認證，可以減少DNS 動態(tài)更新攻擊的危害。然而，對于DNS 放大攻擊、域名欺詐等，由于它們的原理不是假冒數(shù)據(jù)源，而是利用假冒源地址或者近似域名等手段，所以難以通過DNSSec 來防治。

3.2 運算代價

引入DNSSec 之后，DNS 域名服務(wù)器在應答一個請求時，需要在原有的計算量基礎(chǔ)上，增加對數(shù)據(jù)內(nèi)容的哈希運算，以及對摘要的簽名運算——我們知道，哈希算法如MD5（在RFC2537[14]中被規(guī)定為一種摘要生成算法）的運算量是很大的——這就大大增加了DNS 域名服務(wù)器的計算負荷；同樣，對應答報文的認證也需要類似的運算代價。這就使得DNS 域名服務(wù)器或者域名解析服務(wù)器可能成為DoS 的攻擊目標。實際上，目前很多部署了DNSSec 的域都相應的升級了硬件設(shè)備（比如升級了多核的處理器），來應付增加的計算開銷。

3.3 密鑰管理

但凡引入公鑰機制的系統(tǒng)設(shè)計都會遇到密鑰管理、分發(fā)的問題。公鑰機制的引入往往意味著要引入一套完整的公鑰基礎(chǔ)設(shè)施，而這是很難做到的——這也正是IPSec 之所以至今沒有得到廣泛應用的原因之一。而這個問題相對于DNS 來說，可能沒有嚴重，因為它本身的樹形結(jié)構(gòu)和已經(jīng)形成完善的管理體系，公鑰體統(tǒng)的建立并不難。然而，由于DNSSec 并不可能一夜之間部署到整個互聯(lián)網(wǎng)，而是一部分一部分的增量部署起來的，所以必然使得那些先部署了DNSSec 的子域形成一個一個的“孤島”，它們之間的密鑰管理和分發(fā)機制還沒有一個完善的解決方案：比如，如果一個域的私鑰泄露，想要撤消這對密鑰并使用一對新的密鑰，目前還無法解決?？傊?，DNSSec 使用公鑰體系比起其它系統(tǒng)（如IPSec ）有基礎(chǔ)設(shè)施的優(yōu)勢，但仍然存在著一些困難。

3.4 管理代價

DNSSec 固然為DNS 服務(wù)提供了一套安全解決方案，但由于DNSSec 比原來簡單的DNS 復雜的多，那么培訓一個得力的網(wǎng)絡(luò)管理人員，由其負責升級設(shè)備或軟件、配置系統(tǒng)、處理故障等工作，都較原來更為復雜，從而為網(wǎng)絡(luò)運行機構(gòu)引入了較大的管理開銷。 4 DNSSec 的實現(xiàn)與部署

4.1 DNSSec 的實現(xiàn)

本節(jié)將介紹BIND （Berkeley Internet Name Daemon）和Windows Server 2003 DNS提供的對DNSSec 相關(guān)功能的支持。

4.1.1 BIND

BIND 是一個實現(xiàn)DNS 協(xié)議的開源軟件[15]。它是DNS 相關(guān)協(xié)議族的參考實現(xiàn)，但仍然可以作為產(chǎn)品級的軟件。迄今為止，它是互聯(lián)網(wǎng)中被使用最為廣泛的DNS 軟件。BIND 最初由美國加州大學伯克利分校的幾名畢業(yè)生編寫，并發(fā)布在4.3BSD 上?，F(xiàn)在由Internet Systems Consortium進行維護和支持。

自從版本8.1.2開始，BIND 發(fā)布了對DNSSec 的支持。目前其最新版本為9.6.1。BIND 宣布其支持DNSSec 相關(guān)的所有標準。

本文不對BIND 的配置、使用方法進行介紹。

4.1.2 Windows Server 2003 DNS

Windows Server 2003 DNS是一套運行在Windows Server 2003上的提供DNS 服務(wù)的應用程序[16]。它并不完全支持RFC2535中所述的所有DNSSEC 的特性，而只提供RFC2535中定義的“基本支持”。

本文不對Windows Server 2003 DNS的配置、使用方法進行介紹。

4.2 DNSSec 的部署情況

前面已經(jīng)提到，DNSSec 支持增量部署；在實際的部署過程中，也正是先有一部分網(wǎng)絡(luò)（或域）部署起來，目前部署的范圍正在逐漸擴大。

網(wǎng)站xelerance 發(fā)布了截止到2007年11月21日，全球范圍內(nèi)的DNSSec 的部署情況[17]，如下圖：

圖 2 DNSSec在全球范圍內(nèi)的部署情況

可見許多頂級域名服務(wù)商已經(jīng)開始部署了DNSSec 。截止2007年11

月，中國大陸還沒

有DNSSec 的部署。

2008年12月，“代表著超過1.12億個域名(占所有已注冊域名的65)的七家主要域名廠商已經(jīng)組建了一個行業(yè)聯(lián)盟，宣布共同采用DNS 安全擴展機制—DNSSEC 。 DNSSEC 行業(yè)聯(lián)盟包括：運營.com 和.net 注冊業(yè)務(wù)的VeriSign 、運行.biz 和.us 注冊業(yè)務(wù)的NeuStar ；.info 運營商 Afilias Limited；.edu 運營商EDUCAUSE 以及運營.org 注冊業(yè)務(wù)的The Public Interest Registry ”[18]。可見，從這些頂級域名的運營商開始，DNSSec 要逐漸在全球范圍內(nèi)大規(guī)模部署開去了。

此外，DNSSEC Deployment Initiative網(wǎng)站上也提供了有關(guān)DNSSec 部署的方法和動態(tài)新聞[19]。

5 總結(jié)與展望

DNS 已經(jīng)成為互聯(lián)網(wǎng)上重要的服務(wù)系統(tǒng)和基礎(chǔ)設(shè)施，然而傳統(tǒng)的DNS 協(xié)議卻存在著諸多安全漏洞，利用這些漏洞的網(wǎng)絡(luò)攻擊已經(jīng)給DNS 和互聯(lián)網(wǎng)服務(wù)帶來了巨大的破壞。DNSSec 提出為DNS 安全提供了一套較好的解決方案，它通過利用公鑰機制對數(shù)據(jù)源或事務(wù)請求雙方的認證，從而在一定程度上防止DNS 服務(wù)器偽造的問題，遏制了DNS 緩存污染、DNS 客戶洪泛攻擊和DNS 動態(tài)更新攻擊的實施。

然而，DNSSec 也存在著一些問題，比如：它不能防止DNS 放大攻擊、域名欺詐等，哈希、簽名運算開銷過大、容易成為DoS 的攻擊目標，密鑰管理體系較為復雜、尚有一些未被解決的問題，協(xié)議較為復雜、帶來管理和維護上的負擔等等。這些問題中，有些是DNSSec 本身無法解決也不計劃去解決的問題（如防止DNS 放大攻擊、域名欺詐等），而還有一些是待解決的問題。

由于針對DNS 的攻擊越來越多，DNSSec 的部署得到了越來越多運營商的重視，近年來其部署速度加快，而頂級域名運營商組成的行業(yè)聯(lián)盟則更是加快了其部署的進度。由于DNSSec 本身的重要性、相關(guān)標準的相對完善性、行業(yè)普遍的重視程度和DNS 系統(tǒng)本身建立公鑰系統(tǒng)的天然優(yōu)勢，我們有理由相信，DNSSec 將會在未來10年內(nèi)快速地在全球范圍內(nèi)部署，并且逐步取代原有的DNS 。

6 致謝

感謝段海新老師和張甲同學的指導和幫助。

7 參考文獻

[1] “Domain Name System,” Wikipedia, June 2009.

[2] “DNS,” 百度百科, baike.baidu.com/view/22276.htm, June 2009.

[3] P. Mockapetris, “DOMAIN NAMES - CONCEPTS and FACILITIES,” RFC 882, November

1983.

[4] P. Mockapetris, “DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION,” RFC

883, November 1983.

[5] “DNS cache poisoning,” Wikipedia, June 2009.

[6] Niranjan, “DNS Amplification Attack,” Security Tools News & Tips, February 2007.

[7] Diane Davidowicz, “Domain Name System (DNS) Security,” Yahoo Geocities, 1999.

[8] “Domain name phishing schemes a growing problem,” Internet-Security.ca, December 2006.

[9] S. Bellovin, “Report of the IAB Security Architecture Workshop,” RFC 2316, April 1998.

[10] “Domain Name System Security Extensions,” Wikipedia, June 2009.

[11] “DNS Extensions (dnsext) Charter,” IETF, April 2009.

[12] D. Eastlake, “Domain Name System Security Extensions,” RFC 2535, March 1999.

[13] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose, “Protocol Modifications for the

DNS Security Extensions,” RFC 4035, March 2005.

[14] D. Eastlake, “RSA/MD5 KEYs and SIGs in the Domain Name System (DNS),” RFC 2537,

March 1999.

[15] “ISC BIND,” Internet Systems Consortium (ISC.org).

[16] Microsoft TechNet, “DNSSEC 概述,” Microsoft TechNet中文主頁.

[17] Paul Wouters, “World Wide DNSSEC Deployment,” ,

November 2007.

[18] 網(wǎng)界網(wǎng)佚名, “致力保護DNS 安全 頂級域名運營商采用DNSSEC,” 網(wǎng)界網(wǎng),

[19] DNSSEC Deployment Initiative, .