基于云的域名解析服務(wù)模型

秦臻，肖春靜，李樂(lè)民

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

1 引言

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

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

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

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

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

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

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

2 相關(guān)研究

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

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

為提高域名服務(wù)對(duì)網(wǎng)絡(luò)故障和 DoS攻擊的應(yīng)變能力，Handley等[11]提出了P2P傳輸?shù)姆绞剑谌蚍植嫉姆?wù)器上復(fù)制 DNS記錄。該方法實(shí)現(xiàn)了在眾多網(wǎng)絡(luò)實(shí)體中共享 DNS記錄，各實(shí)體協(xié)作提供域名解析服務(wù)。該方法需要一組能夠協(xié)同合作、相互信任的網(wǎng)絡(luò)實(shí)體（分布的服務(wù)器），才能保證域名解析服務(wù)的高效、安全和可靠。

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

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

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

本文的研究則在公共域名解析器的基礎(chǔ)上更進(jìn)一步，基于云技術(shù)，利用云及其網(wǎng)絡(luò)架構(gòu)，構(gòu)建一套完整的域名解析服務(wù)模型，包括域名解析器和域名服務(wù)器的功能。

3 模型設(shè)計(jì)

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

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

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

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

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

3.2 模型架構(gòu)

圖1所示的為基于云的域名解析服務(wù)模型，此服務(wù)模型包括了現(xiàn)行 DNS架構(gòu)中權(quán)威域名服務(wù)器和域名解析器的功能，是一個(gè)完整的架構(gòu)。權(quán)威域名服務(wù)器維持域名權(quán)威的 DNS記錄，域名解析器響應(yīng)用戶的域名解析請(qǐng)求。

圖1 基于云的域名解析服務(wù)模型

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

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

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

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

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

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

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

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

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

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

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

3.4 增量部署能力和兼容性

任何系統(tǒng)若要取代現(xiàn)行系統(tǒng)，增量部署能力是必須的?；谠频挠蛎馕龇?wù)部署需要域名所有者的配合，通過(guò)云的內(nèi)容發(fā)布機(jī)制，將域名的DNS記錄發(fā)布到各分布的節(jié)點(diǎn)服務(wù)器。然而，這樣的服務(wù)遷移不可能一蹴而就，針對(duì)只有部分用戶和域名所有者使用此域名解析服務(wù)模型的情況，本文提出了可增量部署的服務(wù)模型。

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

圖3 可增量部署的服務(wù)模型

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

4 特性分析

引言介紹了現(xiàn)行 DNS存在性能或安全上的問(wèn)題，下面結(jié)合本文的設(shè)計(jì)，對(duì)它們進(jìn)行對(duì)比分析。

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

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

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

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

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

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

5 實(shí)驗(yàn)評(píng)估

下面通過(guò)大規(guī)模實(shí)驗(yàn)對(duì)基于云的域名解析服務(wù)模型性能進(jìn)行評(píng)估。實(shí)驗(yàn)使用的域名集合來(lái)自于美國(guó)西北大學(xué)連續(xù)4個(gè)月的DNS查詢?nèi)罩局幸欢螢槠?4 h的片段。這組24 h的DNS查詢?nèi)罩酒我还舶?3884065次DNS查詢，解析了265262個(gè)不同域名。

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

5.1 DNS查詢延遲

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

在基于云的域名解析服務(wù)模型中，云的節(jié)點(diǎn)服務(wù)器上維持有所有域名的 DNS記錄，域名解析過(guò)程中不必再進(jìn)行遞歸查詢，用戶僅需訪問(wèn)云的節(jié)點(diǎn)服務(wù)器即可獲取DNS記錄。因此，基于云的域名解析服務(wù)模型的DNS查詢可以通過(guò)測(cè)量云的節(jié)點(diǎn)服務(wù)器到用戶的RTT來(lái)評(píng)估。這里，實(shí)驗(yàn)通過(guò)測(cè)量Google Public DNS云架構(gòu)的節(jié)點(diǎn)服務(wù)器到PlanetLab節(jié)點(diǎn)的RTT來(lái)估算基于云的域名解析服務(wù)模型的DNS查詢延遲。對(duì)于其他3種情況，各PlanetLab節(jié)點(diǎn)依次使用3種域名解析器，通過(guò)現(xiàn)行DNS架構(gòu)，解析上述的265262個(gè)域名。

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

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

5.2 DNS更新延遲

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

圖5 TTL值的累積分布

5.3 DNS可靠性

下面將比較4種域名解析服務(wù)的可靠性（通過(guò)連續(xù)24h的測(cè)量）。對(duì)基于云的域名解析服務(wù)模型，實(shí)驗(yàn)測(cè)量的是其網(wǎng)絡(luò)和節(jié)點(diǎn)服務(wù)器的可靠性。網(wǎng)絡(luò)的可靠性（分組丟失率）可以通過(guò)ICMP PING節(jié)點(diǎn)服務(wù)來(lái)測(cè)量，節(jié)點(diǎn)服務(wù)器的可靠性則通過(guò) TCP PING節(jié)點(diǎn)服務(wù)器來(lái)測(cè)量。在 5s的時(shí)隙內(nèi)，如果ICMP PING和TCP PING都收到了節(jié)點(diǎn)服務(wù)器的響應(yīng)，則認(rèn)為域名解析服務(wù)在這5s時(shí)隙內(nèi)是可靠的。對(duì)于其他3種域名解析服務(wù)，實(shí)驗(yàn)采用文獻(xiàn)[21]中的方法，每隔5s發(fā)送一次DNS查詢請(qǐng)求。將時(shí)間間隔設(shè)置為 5s是因?yàn)橐话阌蛎馕銎髂J(rèn)的超時(shí)重傳為 5s。如果在5s內(nèi)沒(méi)有收到響應(yīng)，則認(rèn)為出現(xiàn)異常，這5s時(shí)隙內(nèi)域名解析服務(wù)不可靠。最后，統(tǒng)計(jì)24h內(nèi)可靠的5s時(shí)隙的數(shù)量，并計(jì)算出各域名解析服務(wù)的可靠性。

如圖6所示是可靠性實(shí)驗(yàn)的測(cè)量結(jié)果。對(duì)基于云的域名解析服務(wù)模型，其可靠性明顯高于其他 3種域名解析服務(wù)。在所有140個(gè)PlanetLab節(jié)點(diǎn)中，50%節(jié)點(diǎn)的可靠性達(dá)到了99.99%（其他域名解析服務(wù)的這一指標(biāo)只有99.9%或99%）。這主要是因?yàn)閷?duì)于未緩存的DNS記錄，其他3種域名解析服務(wù)需要以遞歸查詢的方式訪問(wèn)各級(jí)域名服務(wù)器，域名服務(wù)器間歇性無(wú)響應(yīng)、網(wǎng)絡(luò)傳輸過(guò)程中 UDP分組丟失都會(huì)降低域名解析服務(wù)的可靠性。此外，可以注意到，當(dāng)使用ISP的域名解析器時(shí)，有近20個(gè)節(jié)點(diǎn)的可靠性為 0。這是因?yàn)槟切┕?jié)點(diǎn)配置的主域名解析器出現(xiàn)故障，切換到備用域名解析器的時(shí)間超出5s或沒(méi)有備用域名解析器?；谠频挠蛎馕龇?wù)模型、Google Public DNS和OpenDNS則未出現(xiàn)這一狀況，通過(guò)IP Anycast路由技術(shù)，它們可將用戶快速地重定向到附近的其他正常工作的域名解析器上。

圖6 可靠性

6 結(jié)束語(yǔ)

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