秦臻，肖春靜，李樂民

（1.電子科技大學 通信與信息工程學院，四川 成都 610054；2.電子科技大學 計算機科學與工程學院，四川 成都 610054）

1 引言

域名解析系統(tǒng)（DNS）是重要的互聯(lián)網基礎設施，將網絡域名（例如www.example.com）解析為與之相對應的IP地址（例如10.0.0.1）?；诨ヂ?lián)網的各種Web服務、E-mail服務等都可能依賴DNS?，F行的 DNS采用分布式層級結構設計，由域名解析器和一系列域名服務器構成。解析一個域名時，用戶將域名解析請求發(fā)送給域名解析器，由其進行解析。如果域名解析器緩存中存有該請求的 DNS記錄，則域名解析器立即響應用戶的請求，將該DNS記錄返回給用戶。否則，域名解析器需要通過遞歸查詢、訪問各級域名服務器，獲取該域名的DNS記錄，再將其返回給用戶[1～3]。然而，隨著近10多年來互聯(lián)網的發(fā)展，新出現的技術不斷改變網絡環(huán)境，傳統(tǒng)的域名解析服務在性能和安全上逐漸顯現出一些問題。

1) DNS查詢延遲。由于網頁往往嵌入多個鏈接，打開一個網頁需要從多個域名中獲取數據。DNS查詢延遲成為影響打開網頁所需時間的主要因素[4]。DNS記錄在域名解析器的緩存有助于提高查詢速度。為了解析一個未緩存的域名，域名解析器需要以遞歸查詢的方式，訪問各級域名服務器[5]。此外，由于服務器不可達、數據分組丟失等因素，域名解析請求的未響應率為 4%～6%。據統(tǒng)計，300～400ms為解析一個域名所需的平均時間[4]。

2) DNS更新延遲。TTL機制是現行的域名解析系統(tǒng)所采用的DNS記錄更新方式。DNS記錄中的TTL字段決定了DNS記錄的更新延遲。TTL值的大小指示了該 DNS記錄能緩存在域名解析器中時間的長短。對于域名解析器緩存中的 DNS記錄，若域名服務器上該 DNS記錄出現更新，該緩存的DNS記錄則是冗余的信息。若此時解析該域名，則可能出現異常，需要等待域名解析器緩存中該域名DNS記錄的TTL值過期后，域名解析器以“拉”的方式，訪問相應的域名服務器以獲取更新后的DNS記錄。一個合適的TTL值是不易設置的。TTL值過大不利于服務搬遷和DNS記錄更新。TTL值過小則不利于縮短 DNS查詢延遲，同時增加網絡和服務器的負載[6]。許多域名DNS記錄的TTL值設置為幾小時，但DNS記錄往往穩(wěn)定數月[5,7]，可見，TTL機制并不是很好地適用于DNS記錄的更新。

3) 網絡故障和DoS攻擊的應變能力。DNS容易受到網絡故障的影響，也容易受到DoS攻擊。這是因為一個域名往往只由少數幾個域名服務器來提供域名解析服務[1]。據研究[6]，只有 2個域名服務器的域名為78.32%，而且只有1個域名服務器的域名為0.82%。研究還發(fā)現，僅由3個或者更少的域名服務器來提供域名解析服務的域名超過90%。小規(guī)模的網絡故障或網絡攻擊就可以使其不能正常服務。近期的研究報告表明[8]，盡管有87%～96%的域名有2個以上的域名服務器，但域名服務器在相同的自治域（autonomous system）內的域名為82%，域名服務器屬于同一網段（據有相同的IP前綴）的域名為61%。這些都降低了域名解析服務對網絡故障和DoS攻擊的應變能力。

4) 配置錯誤和管理復雜度。域名DNS記錄的管理是一項復雜的任務，很多性能上和安全上的問題都源自配置錯誤[5]。例如，一個典型的安全隱患就是域名服務器之間DNS記錄的傳輸[8]。管理域名服務器的軟件使用起來很復雜，并需要具有專業(yè)知識的人員進行服務器維護和配置。此外，在域名解析器端的不當配置也會造成一些問題[5]。

5) DNS濫用。DNS已經成為各種網絡攻擊的首選工具。例如，惡意的廣告系統(tǒng)用一次性的域名來發(fā)布惡意或虛假的內容；匿名注冊的域名被釣魚網站用來竊取私人信息；Fast-Flux網絡通過使用短TTL值的DNS記錄來頻繁地切換IP地址，以跳出防火墻黑名單等[9]。

本文研究了近年來學術界和產業(yè)界關于域名解析服務的相關工作，結合云的內容發(fā)布、存儲特點和域名解析服務的具體需求，提出了一種新型的、可增量部署、現行 DNS兼容的、具有更好性能的域名解析服務模型。

2 相關研究

由于多播技術的發(fā)展和磁盤存儲技術的進步，Kangasharju和Ross在INFOCOM會議上提出了一種新型的 DNS記錄發(fā)布方式[10]，在全球分布的服務器上廣泛地復制 DNS記錄。為了同步和更新各服務器上DNS記錄，該設計提出使用者IP多播或衛(wèi)星信道的方式來發(fā)布 DNS記錄。該設計思想實現了將 DNS記錄復制到廣泛分布的副本服務器概念，但卻受限于TTL機制，高頻率更新的DNS記錄（尤其是小TTL值的DNS記錄）給系統(tǒng)帶來巨大的通信壓力。

Cooperative domain name system（CoDNS）是Ramasubramanian和Sirer[6]在SIGCOMM會議上提出的一種新型的DNS構架。該架構通過將DNS記錄緩存在分布式散列表上，降低 DNS查詢延遲，實現高性能的DNS查詢。但是，CoDNS未能解決動態(tài)域名技術帶來的問題，即域名服務器根據內容服務器和網絡的狀況來動態(tài)地匹配域名和IP地址。此外，該架構不適用于小TTL值的DNS記錄（比如，小于30s），因為它會產生極高的系統(tǒng)開銷。所以，當面臨用戶請求解析小TTL值DNS記錄時，CoDNS會將用戶定向到現行的域名解析系統(tǒng)，造成額外的 DNS查詢延遲。此外，在解析某個域名之前，如何確定該域名DNS記錄TTL值的大小也是有待解決的問題。

為提高域名服務對網絡故障和 DoS攻擊的應變能力，Handley等[11]提出了P2P傳輸的方式，在全球分布的服務器上復制 DNS記錄。該方法實現了在眾多網絡實體中共享 DNS記錄，各實體協(xié)作提供域名解析服務。該方法需要一組能夠協(xié)同合作、相互信任的網絡實體（分布的服務器），才能保證域名解析服務的高效、安全和可靠。

通過全面、系統(tǒng)地分析了當前的 DNS架構，Deegan等[5]指出了其中的不足。他們提出一個集中的發(fā)布機制能更有效地適合于發(fā)布 DNS記錄。實際上，在維持域名的 DNS記錄不變這一前提下，可以通過任何合適的方式來取代目前的 DNS記錄發(fā)布機制。

綜上所述，學術界展開了一系列關于大規(guī)模發(fā)布和緩存 DNS記錄的研究，它們將 DNS記錄以“拉”的方式復制到各個分布的服務器上。在域名解析器端（或其附近）的服務器上復制DNS記錄，能夠縮短 DNS查詢延遲、提高域名解析服務的可靠性；在域名服務器端復制 DNS記錄時，則能夠提高域名解析服務對網絡故障和 DoS攻擊的應變能力。然而，由于受限于TTL機制，以“拉”的方式在域名解析器端復制的DNS記錄是非權威的DNS記錄，當 TTL值過期后，需要再次更新該DNS記錄?？梢姡谟蛎馕銎鞫诉@樣的更新會造成高額的系統(tǒng)開銷（尤其是小TTL值的DNS記錄，需要頻繁地更新）。這也是上述研究沒能解決的問題。

由于缺少激勵機制，上述學術界的改進方案未能得到廣泛的應用和部署。近年來，在商業(yè)利益驅使下，為了獲取域名解析服務背后的用戶信息，許多公司開始提供新型的域名解析服務，例如，Google Public DNS和OpenDNS[12,13]?；谠萍夹g，它們通過共享緩存、提前獲取 DNS記錄等方法，提高了DNS請求的cache-hit rate（域名解析器緩存中存有該DNS請求的幾率），縮短了DNS查詢延遲。使用這類域名解析服務，平均 DNS查詢延遲為 100～200ms。事實上，Google Public DNS和OpenDNS也是[13]以“拉”的方式主動復制DNS記錄，同樣受限于TTL機制，故僅對一小部分的域名實施共享緩存,提前獲取DNS記錄的方法。

本文的研究則在公共域名解析器的基礎上更進一步，基于云技術，利用云及其網絡架構，構建一套完整的域名解析服務模型，包括域名解析器和域名服務器的功能。

3 模型設計

解析一個域名所需要的時間取決于域名解析器訪問各級域名服務器的往返通信延遲（RTT）[14]。若結合域名解析器和域名服務器的功能于某網絡實體，能將極大地提高域名解析服務的效率。本節(jié)將提出基于云的域名解析服務模型，它將域名解析器和域名服務器的功能結合于云的節(jié)點服務器上，實現高性能的域名解析。

基于云的域名解析服務模型設計的核心思想是:由廣泛分布的云節(jié)點服務器組成系統(tǒng)，利用云的內容發(fā)布和存儲機制，以“推”的方式，在廣泛分布的節(jié)點服務器上發(fā)布所有域名的權威DNS記錄；同時，各節(jié)點服務器可以取代現行DNS架構中的域名解析器和域名服務器。在此服務模型中，節(jié)點服務器將維持所有域名的DNS記錄。在具體介紹此服務模型的架構之前，先簡單估算維持所有域名的 DNS記錄對節(jié)點服務器存儲空間的要求。

3.1 節(jié)點服務器維持所有DNS記錄的可行性

這里，本文將估算節(jié)點服務器維持所有域名的DNS記錄對存儲空間的需求。在少數情況下，一個域名可能對應多個IP地址，為了簡單起見，假設每個域名對應一個IP地址。據到2010年第三季度的統(tǒng)計[15]，全球注冊的域名數量為近201800000個。域名的長度一般為10～20個字符，可估算，存儲一條A類DNS記錄所需要的空間約為40byte（其中，域名約占20byte，一個IP地址占4byte，其他信息占16byte）。這樣，8GB的空間即可存儲2億個域名的A類DNS記錄。

上述估計，只考慮了域名的A類DNS記錄，而域名的DNS記錄中還包含了CNAME類DNS記錄、SOA類DNS記錄、MX類DNS記錄、PTR類DNS記錄和NS類DNS記錄。這里要指出的是，所有域名的A類DNS記錄都維持在節(jié)點服務器上，NS類DNS記錄不必再使用；此外，絕大部分域名也未使用CNAME類DNS記錄，保守估計約40GB的存儲空間即可維持所有域名的 DNS記錄。就目前的緩存技術和磁盤存儲技術而言，節(jié)點服務器完全有能力維持所有域名的 DNS記錄，所以節(jié)點服務維持所有域名的DNS記錄是可行的。

3.2 模型架構

圖1所示的為基于云的域名解析服務模型，此服務模型包括了現行 DNS架構中權威域名服務器和域名解析器的功能，是一個完整的架構。權威域名服務器維持域名權威的 DNS記錄，域名解析器響應用戶的域名解析請求。

圖1 基于云的域名解析服務模型

在此服務模型中，DNS記錄以“推”的方式發(fā)布。通過云的內容管理服務器，域名所有者將DNS記錄發(fā)布到廣泛分布的云節(jié)點服務器上。這樣，云的節(jié)點服務器就可以發(fā)揮現行 DNS架構中二級域名服務器（權威域名服務器）的功能，其維持的DNS記錄是權威的DNS記錄，由域名所有者直接管理。由于任何更新的 DNS記錄都將由內容發(fā)布服務器在第一時間發(fā)布到各節(jié)點服務器，故節(jié)點服務器上的DNS記錄可不必使用TTL字段，不受TTL機制的限制，。

在解析域名方面，現行 DNS架構中的域名解析器由云的節(jié)點服務器取代（基于IP Anycast路由技術[16]，使用相同的IP地址），用戶的域名解析請求將被指向到附近的任何一個正常工作的節(jié)點服務器。當解析一個域名時，由于節(jié)點服務器上維持了所有域名的 DNS記錄，不需要訪問任何額外的服務器，可立即響應用戶的域名解析請求。用戶到節(jié)點服務器的往返延遲決定了解析一個域名所需的時間。大型的云架構擁有廣泛分布的節(jié)點服務器，既可縮短用戶到節(jié)點服務器的往返延遲，又可避免某個節(jié)點服務器出現負載過重的情況。5.1節(jié)將通過實驗評估此服務模型域名解析的效率，即DNS查詢延遲。

在上述模型中，結合了域名解析器和域名服務器功能的云的節(jié)點服務器將使用2個公網IP地址:一個為原云架構所配置的IP地址，用于云架構內部數據的傳輸和同步[17,18]（本文的設計則是利用該IP地址在云架構中發(fā)布和更新DNS記錄）；另一個為云的節(jié)點服務器共用的 IP地址，基于 IP Anycast路由技術[16]，用于對外提供域名解析服務。

3.3 管理、發(fā)布和更新DNS記錄

圖2所示為基于云的域名解析服務模型管理、發(fā)布和更新 DNS記錄的方式。域名所有者將維護域名服務器的工作外包給云，僅需使用客戶端軟件來管理 DNS記錄。為避免假冒攻擊，保證每個域名的 DNS記錄只能由其域名所有者修改，只有在認證后，云的內容管理服務器才會將更新的 DNS記錄發(fā)布到各節(jié)點服務器。此外，由于所有域名的A類DNS記錄都維持于節(jié)點服務器上，不再需要配置NS類DNS記錄。這種管理方式可極大地降低錯誤配置對域名解析服務造成的不利影響。

圖2 管理、發(fā)布和更新DNS記錄

在發(fā)布 DNS記錄方面，基于云的域名解析服務模型利用云的內容發(fā)布機制，以“推”的方式發(fā)布 DNS記錄。在通過認證和授權后，云的內容管理服務器將權威的DNS記錄發(fā)布到各節(jié)點服務器。既然是權威的DNS記錄，則不受TTL機制的限制，可不必使用TTL字段。

在更新 DNS記錄方面，一般只有在進行服務搬遷或重新分配內容服務器資源時，域名服務器上的DNS記錄才會更新，故域名的DNS記錄往往穩(wěn)定數月不變[5,7]。在基于云的域名解析服務模型中，只有當域名所有者需要更新 DNS記錄（即進行服務搬遷或重新分配內容服務器資源）時，內容管理服務器才會將該域名更新的 DNS記錄發(fā)布到各節(jié)點服務器，以取代原來冗余的信息?？梢姡浴巴啤钡姆绞?，在節(jié)點服務器上維持所有域名的權威DNS記錄，并不會給系統(tǒng)帶來通信壓力。對于現行的Google Public DNS和OpenDNS[12,13]，則是以“拉”的方式在節(jié)點服務器上維持域名非權威的 DNS記錄，受限于TTL機制，若要維持所有域名非權威的DNS記錄則會造成大量的系統(tǒng)開銷。

實際上，在沒有域名解析系統(tǒng)的互聯(lián)網初期，網絡信息中心（network information center）也是以“推”的方式發(fā)布HOST.TXT文件（用戶記錄DNS信息）。但是，隨著互聯(lián)網的發(fā)展，其規(guī)模不斷擴大，維持大小不斷增加的HOST.TXT文件的同步和更新變得越加困難。盡管也是采用“推”的方式，由于各域名DNS記錄的發(fā)布和更新過程相互獨立，基于云的域名解析服務模型并不需要使用一個類似于HOST.TXT的文件來統(tǒng)一發(fā)布和更新DNS記錄。

為了評估基于云的域名解析服務模型中 DNS記錄發(fā)布和更新機制產生的通信量，本文進行了為期20天的實驗，每天對265262個域名（域名來源見第5節(jié)）的A類DNS記錄進行查詢。實驗結果顯示每天只有1.3%～1.6%的域名更新了DNS記錄。這里，假定DNS記錄以每天1.6%的更新率，云的節(jié)點服務器上維持有40G的DNS記錄。由此，可以計算出每個節(jié)點服務器只需要維持一個7.77kbit/s（這一數量級）的數據流就可以實現DNS記錄的發(fā)布和更新。

現階段，團結鄉(xiāng)鄉(xiāng)村旅游發(fā)展依然停留在低層次的“做農家事，吃農家飯，住農家房”的農家樂發(fā)展模式。經營者大多將垂釣休閑、采摘水果和農業(yè)觀光作為主打產品。在某種程度上，旅游項目相對來說是十分單一的，沒有充分挖掘農業(yè)文化和民俗文化的內涵，缺乏新的旅游特色[2]。

3.4 增量部署能力和兼容性

任何系統(tǒng)若要取代現行系統(tǒng)，增量部署能力是必須的?；谠频挠蛎馕龇詹渴鹦枰蛎姓叩呐浜?，通過云的內容發(fā)布機制，將域名的DNS記錄發(fā)布到各分布的節(jié)點服務器。然而，這樣的服務遷移不可能一蹴而就，針對只有部分用戶和域名所有者使用此域名解析服務模型的情況，本文提出了可增量部署的服務模型。

圖3所示為可增量部署的服務模型，實現基于云的域名解析服務模型與現行 DNS的兼容。若用戶使用云的節(jié)點服務器作為域名解析器，對于通過此架構發(fā)布和更新DNS記錄的域名，如3.2節(jié)所述，可立即將所查詢域名的 DNS記錄返回給用戶；對于未使用此架構的域名，節(jié)點服務器作為域名解析器，可查詢其緩存中非權威的 DNS記錄，或以遞歸查詢的方式訪問現行 DNS架構中的各級域名服務器，解析該域名，最后將該域名的 DNS記錄返回給用戶，流程如圖3中a1→a2→a3→a4→a5所示。若用戶使用現行 DNS架構中的域名解析器，對于通過此架構發(fā)布和更新 DNS記錄的域名，節(jié)點服務器作為二級域名服務器注冊于現行DNS架構下，響應域名解析器的查詢請求，流程如圖3中b1→b2→b3→b4→b5所示。

圖3 可增量部署的服務模型

由此可見，基于云的域名解析服務模型雖然采用了新穎的方法來提供域名解析服務，但它可很好地兼容于現行的域名解析系統(tǒng)，實現增量部署。在增量部署此服務模型的過程中，不論用戶選取何種域名解析器，域名所有者以何種方式發(fā)布 DNS記錄，它不會對域名解析服務造成任何不利的影響，同時還能在性能和安全上（第4節(jié)將具體分析）提高域名解析服務的質量。故此服務模型可逐漸吸引用戶和域名所有者，進而可漸進地取代現行的域名解析系統(tǒng)。

4 特性分析

引言介紹了現行 DNS存在性能或安全上的問題，下面結合本文的設計，對它們進行對比分析。

1) 降低查詢延遲。在現行DNS架構下，若要解析一個未緩存的 DNS記錄，域名解析器需要以遞歸查詢的方式訪問多個域名服務器以獲取該DNS記錄。域名解析器到用戶和各級域名服務器的往返延遲決定了 DNS查詢延遲。在本文提出的服務模型下，節(jié)點服務器上維持所有域名的權威DNS記錄，同時也是域名解析器，可直接響應域名解析請求而不需要訪問其他服務器，DNS查詢延遲僅取決于用戶到節(jié)點服務器的往返延遲。第5節(jié)的實驗證明，用戶到節(jié)點服務器的往返延遲遠小于域名解析器到用戶和各級域名服務器的往返延遲。

2) 解決更新延遲問題。TTL機制是造成 DNS更新延遲的根本原因。DNS記錄TTL值的大小，指示了其可緩存在域名解析器中的時間長短。在TTL值有效期內，域名解析器會直接將緩存中的DNS記錄返回給用戶，若在這段時間內權威域名服務器上更新了 DNS記錄，則域名解析器緩存中的DNS記錄成為冗余信息。本文的設計將權威的DNS記錄發(fā)布到廣泛分布的節(jié)點服務器上，不受TTL機制的限制，從根本上解決了這一問題。

3) 提高對網絡故障和DoS攻擊的應變能力。在現行DNS架構中，一個域名的域名服務器往往不多于3個，而且這些域名服務器往往位于同一個IP網段或自治域（autonomous system），網絡故障和DoS攻擊很容易影響域名解析服務。本文的設計可使所有域名的權威DNS記錄在全球范圍內廣泛分布的節(jié)點服務器上發(fā)布和更新。即使某個節(jié)點服務器遇到網絡故障或受到DoS攻擊，在本文提出的模型中，通過IP Anycast路由，用戶的域名解析請求仍可被定向到其他正常工作的節(jié)點服務器，完成域名解析。該模型具有較強的應對網絡故障和DoS攻擊能力。

4) 降低管理復雜性。域名服務器上的DNS記錄的管理是一項復雜的工作，需要管理人員據有專業(yè)的知識使用域名服務器軟件進行維護和配置。維護和配置不當，會造成一系列的問題。對于本文提出的設計，在維護方面，域名所有者將域名服務器的維護工作外包給云，不需要對域名服務器進行維護；在配置方面，由于不必使用NS類DNS記錄，且DNS記錄不必使用TTL字段，可降低出現人為配置錯誤的可能性。

釣魚網站攻擊主要是通過偽造非權威的 DNS記錄，污染域名解析器緩存，進而實施的攻擊。為降低這類攻擊的威脅，可對訪問域名解析器的 IP地址進行限制，但白名單中的IP地址仍可實施該攻擊。然而，由于管理和配置上的疏忽，互聯(lián)網上大量的域名解析器存在該攻擊漏洞。對于 Google Public DNS這類公共的域名解析器，它們沒有限制用戶IP地址，而是使用IETF RFC 5452[19]中的方法，降低域名解析器緩存被污染的機率。在本文提出的設計中，對于用戶的域名解析請求，返回的都是權威的DNS記錄，從根本上解決了釣魚網站攻擊這類以偽造DNS記錄、污染緩存而實施攻擊的問題。

為在互聯(lián)網上發(fā)布虛假的、非法的信息，Fast-Flux網絡以快速更變域名的 IP地址方式來跳出防火墻黑名單。在 Fast-Flux網絡的域名服務器端，DNS記錄使用很小的TTL值，以Round-Robin方法頻繁更換IP地址。在本文提出的設計中，任何更新的 DNS記錄都是由云的內容管理服務器發(fā)布到各節(jié)點服務器。內容管理服務器可輕易檢測和限制惡意或可疑的行為（例如，Fast-Flux網絡）。

5 實驗評估

下面通過大規(guī)模實驗對基于云的域名解析服務模型性能進行評估。實驗使用的域名集合來自于美國西北大學連續(xù)4個月的DNS查詢日志中一段為期24 h的片段。這組24 h的DNS查詢日志片段一共包含了13884065次DNS查詢，解析了265262個不同域名。

實驗平臺為PlanetLab[20]，通過使用不同的域名解析服務，對上述域名集合進行解析，比較各域名解析服務的性能。PlanetLab平臺由1074個節(jié)點組成，分布于530個不同地理位置[20]。本實驗一共使用了其中的 140個位于不同地理位置PlanetLab節(jié)點，其中，北美洲78個，歐洲35個，亞洲16個，其他地區(qū)11個。這樣，每個PlanetLab節(jié)點可代表不同地理位置的用戶群體，分別使用 4種域名解析器（ISP提供的域名解析器、Google Public DNS、OpenDNS和云的節(jié)點服務器）來解析上述的265262個域名。實驗結果顯示，基于云的域名解析服務模型在查詢延遲、更新延遲、可靠性等各方面都體現出優(yōu)越性，下面逐一分析。

5.1 DNS查詢延遲

已有研究利用域名解析服務遞歸查詢的DNS查詢延遲來估算互聯(lián)網上2節(jié)點之間的RTT[14]；這里，本文是利用互聯(lián)網上2節(jié)點之間的RTT來估算DNS查詢延遲。若域名解析器緩存中存有與DNS請求相應的DNS記錄，DNS查詢延遲可以很準確地用域名解析器到用戶的 RTT來估算；DNS遞歸查詢的延遲也可通過域名解析器到用戶和各級域名服務器的RTT來估算。筆者通過實驗驗證，對于域名解析器緩存中維持的DNS記錄，平均 DNS查詢延遲僅比域名解析器到用戶的RTT大2ms左右。

在基于云的域名解析服務模型中，云的節(jié)點服務器上維持有所有域名的 DNS記錄，域名解析過程中不必再進行遞歸查詢，用戶僅需訪問云的節(jié)點服務器即可獲取DNS記錄。因此，基于云的域名解析服務模型的DNS查詢可以通過測量云的節(jié)點服務器到用戶的RTT來評估。這里，實驗通過測量Google Public DNS云架構的節(jié)點服務器到PlanetLab節(jié)點的RTT來估算基于云的域名解析服務模型的DNS查詢延遲。對于其他3種情況，各PlanetLab節(jié)點依次使用3種域名解析器，通過現行DNS架構，解析上述的265262個域名。

圖4所示為4種域名解析服務DNS查詢延遲的累積分布?？梢宰⒁獾?，相對于其他3種域名解析服務，基于云的域名解析服務模型的 DNS查詢延遲明顯較低。具體來說，Google Public DNS云架構的節(jié)點服務器到各PlanetLab節(jié)點RTT的中位數約為50ms；使用Google Public DNS和OpenDNS這類公共的域名解析器，DNS查詢延遲的中位數約為100ms；而使用ISP的域名解析器，DNS查詢延遲的中位數約為230ms。由此可見，若基于云的域名解析服務模型應用于Google Public DNS的云架構上，可將DNS查詢延遲縮短2～4倍。隨著Google Public DNS云架構規(guī)模的擴大（目前，Google Public DNS云架構的節(jié)點服務器僅為40個左右）或將此服務模型應用于其他更大規(guī)模的云架構上，DNS查詢效率可得到進一步的提高。

圖4 DNS查詢延遲的累積分布

5.2 DNS更新延遲

在現行DNS架構中，TTL機制造成了DNS記錄的更新延遲[5]。TTL值的大小決定了DNS記錄更新延遲的長短。實驗使用的域名集合中全部265262個域名TTL值的累積分布如圖5所示?？梢宰⒁獾?，TTL值的中位數約為2h。也就是說，若域名所有者需要重新分配內容服務器資源，則需要承受近 2h的延遲。在 DNS記錄發(fā)布方式上，本文提出的模型采用的是“推”機制，不必采用TTL機制，從根本上解決了這個問題，使域名所有者可以“無縫”地重新分配內容服務器資源。

圖5 TTL值的累積分布

5.3 DNS可靠性

下面將比較4種域名解析服務的可靠性（通過連續(xù)24h的測量）。對基于云的域名解析服務模型，實驗測量的是其網絡和節(jié)點服務器的可靠性。網絡的可靠性（分組丟失率）可以通過ICMP PING節(jié)點服務來測量，節(jié)點服務器的可靠性則通過 TCP PING節(jié)點服務器來測量。在 5s的時隙內，如果ICMP PING和TCP PING都收到了節(jié)點服務器的響應，則認為域名解析服務在這5s時隙內是可靠的。對于其他3種域名解析服務，實驗采用文獻[21]中的方法，每隔5s發(fā)送一次DNS查詢請求。將時間間隔設置為 5s是因為一般域名解析器默認的超時重傳為 5s。如果在5s內沒有收到響應，則認為出現異常，這5s時隙內域名解析服務不可靠。最后，統(tǒng)計24h內可靠的5s時隙的數量，并計算出各域名解析服務的可靠性。

如圖6所示是可靠性實驗的測量結果。對基于云的域名解析服務模型，其可靠性明顯高于其他 3種域名解析服務。在所有140個PlanetLab節(jié)點中，50%節(jié)點的可靠性達到了99.99%（其他域名解析服務的這一指標只有99.9%或99%）。這主要是因為對于未緩存的DNS記錄，其他3種域名解析服務需要以遞歸查詢的方式訪問各級域名服務器，域名服務器間歇性無響應、網絡傳輸過程中 UDP分組丟失都會降低域名解析服務的可靠性。此外，可以注意到，當使用ISP的域名解析器時，有近20個節(jié)點的可靠性為 0。這是因為那些節(jié)點配置的主域名解析器出現故障，切換到備用域名解析器的時間超出5s或沒有備用域名解析器。基于云的域名解析服務模型、Google Public DNS和OpenDNS則未出現這一狀況，通過IP Anycast路由技術，它們可將用戶快速地重定向到附近的其他正常工作的域名解析器上。

圖6 可靠性

6 結束語

本文分析了現行 DNS存在的問題。針對這些問題，本文結合云的內容發(fā)布、存儲特點和域名解析服務的需求，提出了基于云的域名解析服務模型。設計采取了“推”機制，在全球廣泛分布的云的節(jié)點服務器上發(fā)布各域名權威的 DNS記錄，使節(jié)點服務器實現現行 DNS架構中二級域名服務器功能。這將極大提高域名解析服務對DoS攻擊和網絡故障的應變能力，同時可降低域名管理的復雜性，還能有效地限制 DNS濫用。更重要的是，節(jié)點服務器也作為域名解析器，響應域名解析請求。這樣的設計使得節(jié)點服務器結合了域名服務器和域名解析器的功能，DNS查詢將不再需要以遞歸查詢的方式訪問各級域名服務器，節(jié)點服務器能直接響應用戶的域名解析請求，極大地提高了查詢效率。本文通過實驗證明了基于云的域名解析服務模型在查詢延遲、更新延遲、可靠性等各方面的性能都有顯著提高。最后，此服務模型可與現行 DNS兼容，通過增量部署，可以實現漸進地取代現行的域名解析系統(tǒng)。

[1]MOCKAPETRIS P.Domain Names:Concepts and Facilities[S].RFC 1034, 1987.

[2]MOCKAPETRIS P.Domain Names:Implementation and Specification[S].RFC 1035, 1987.

[3]MOCKAPETRIS P, DUNLOP K.Development of the domain name system[A].SIGCOMM'98[C].Stanford, CA, USA, 1988.123-133.

[4]A DNS number for faster browsing[EB/OL].http://www.infoq.com/news/2009/12/Public-DNS-Google,2009.

[5]DEEGAN T, CROWCROFT J, WARFIELD A.The main name system:an exercise in centralized computing[J].ACM Sigcomm Computer Communication Review, 2005, 35(5):5-14.

[6]RAMASUBRAMANIAN V, SIRER E G.The design and implementation of a next generation name service for the internet[A].SIGCOMM'04[C].Portland, OR, USA, 2004.331-342.

[7]LISTON R, SRINIVASAN S, ZEGURA E.Diversity in DNS performance measures[A].ACM IMW'02[C].New York, USA, 2002.19-31.

[8]KALAFUT A, SHUE C, GUPTA M.Understanding implications of dns zone provisioning[A].IMC'08[C].New York, USA, 2002.19-31.

[9]ANTONAKAKIS M, PERDISCI R, DAGON D, et al.Building a dynamic reputation system for DNS[A].USENIX Security'10[C].Washington.DC, USA, 2010.1-17.

[10]KANGASHARJU J, ROSS K.A replicated architecture for the domain name system[A].INFOCOM'00[C].Tel Aviv, Israel, 2000.660-669.

[11]HANDLEY M, GREENHALGH A.The case for pushing DNS[A].HotNets'05[C].College Park, MD, USA, 2005.1-6.

[12]Google public DNS[EB/OL].http://code.google.com/speed/publicdns/.

[13]Open DNS[EB/OL].http://www.opendns.com/.

[14]GUMMADI K, SAROIU S, GRIBBLE S.King:estimating latency between arbitrary Internet and hosts[A].ACM IMW'02[C].Marseille,France, 2002.1-14.

[15]The total number of Web domains[EB/OL].http://www.labnol.org/internet/total-web-domain-names/18395/,2010.

[16]KATABI D, WROCLAWSKI J.A framework for scalable global IP-anycast[A].SIGCOMM'00[C].New York, USA, 2000.3-15.

[17]KEAHEY K, FIGUEIRDO R, FORTES J, et al.Science clouds:early experiences in cloud computing for scientific applications[J].Cloud Computing and Applications, 2008, 2008:825-830.

[18]BERNSTEIN D, LUDVIGSON E, SANKAR K, et al.Blueprint for the intercloud-protocols and formats for cloud computing interoperability[A].ICIW'09[C].Venice/Mestre, Italy, 2009.328-336.

[19]HUBERT A, MOOK R.Measures for Making Dns More Resilient Against Forged Answers[S].RFC 5452, 2009.

[20]PlanetLab[EB/OL].http://www.planet-lab.org/,2007.

[21]PARK K, PAI V, PERTERSON L, et al.CoDNS:improving DNS performance and reliability via cooperative lookups[A].OSDI'04[C].San Francisco, CA, USA, 2004.1-16.