所謂DNS，是一套將人類可讀的域名轉化為計算機可識別IP地址的命名系統(tǒng)。每當一條尚不存在于解析器緩存中的域名查詢請求出現(xiàn)，這一轉化過程就會在從根服務器到頂級域名（例如.com型域名）的整個DNS層級體系中走上一遍。接下來頂級域名（簡稱TLD）會把能夠向我們提供所需IP地址的已授權域名服務器找到，并將相關信息提交回來。在我們從域名服務器獲取到對應的域名信息之后，結果將帶著一個特定的TTL值（即有效時間值）進入DNS解析程序緩存，最終在有效期結束時被清出。

有些時候，某個域會被認定為惡意對象并遭到清除。出現(xiàn)這種情況的原因可謂多種多樣，例如惡意軟件傳播、釣魚感染等。一般來說，防止用戶對某個域發(fā)起訪問的常見方式是將該域從TLD服務器中刪除。然而這還不足以徹底消除安全隱患，因為域仍然能夠再次由解析程序解析，并在下一次TTL過期之前始終處于可用狀態(tài)。通常情況下這算不得什么大問題，因為TTL值生效時間本身就很短，所以攻擊型域的存在時間可能只有數(shù)秒或者數(shù)分鐘。

在本文中，我們將討論近來存在于大多數(shù)DNS服務器中的DNS漏洞。此漏洞是由江堅、梁津津、李康、李軍、段海心以及吳建平等多位研究人員共同發(fā)現(xiàn)的。點擊此處可以查看他們的研究論文。

該漏洞的突破口在于某些DNS服務器中的緩存更新邏輯缺口。此漏洞允許緩存以特定方式被改寫，進而導致某個特定域將在緩存中擁有源源不斷的TTL授權數(shù)據(jù)，且TTL值不受有效時間所限。這樣一來，即使該域被從TLD服務器中清出，也仍然會一直處于可解析狀態(tài)。此種類型的域如今有了自己的名號：幽靈域名（即Ghost Domain Name）。

DNS基礎知識

首先，讓我們先來了解DNS解析工作是如何進行的。

比如說，用戶打開瀏覽器并在地址欄中輸入infosecinstitute.com內容。這時用戶操作系統(tǒng)中的DNS解析程序就會運作起來，嘗試為該域名找出對應的IP地址。解析程序首先會檢查本地緩存，以確認該查詢域名是否在緩存中存在記錄。緩存中通常保存著最近一段時間內用戶使用過的IP地址與主機名稱映射，這樣解析程序就不必重復再重復地為同一個域名多次獲取IP地址。如果解析程序在緩存中無法找到對應的IP地址，那么接下來它就要向DNS服務器發(fā)送請求，檢查是否存在該域名的記錄。DNS服務器通常由我們的網(wǎng)絡服務供應商（簡稱ISP）提供，當然大家也可以為自己進行手動選擇。如果此時仍然查找不到記錄，解析程序就會向不同的域名服務器發(fā)送循環(huán)DNS查詢，以期找到所查域名。當IP地址被尋獲時，解析程序會在將地址發(fā)回用戶端的同時保存在緩存中，以方便今后的使用。

#p# 深入了解DNS查詢

理解DNS查詢的工作原理非常重要。要完成查詢，我們需要由根服務器出發(fā)、直到頂級域名為止，行遍整個DNS層級體系。打開Backtrack終端（大家也可以使用自己喜歡的其它發(fā)行版）并輸入“dig”。屏幕上的顯示結果如下所示：

我們得到的是一套根DNS服務器列表，下面我們就用根DNS服務器查詢infosecinstitute.com域名。具體操作方法如下圖所示： 

這里我們獲得的是一套用于.com域驗證的域名服務器列表。請注意點（.）被放在com后方。這就使我們的查詢內容成為一個正式域名（簡稱FQDN）。接著我們利用這些域名服務器再進行一次查詢。

現(xiàn)在我們得到了infosecinstitute.com的驗證域名服務器列表（即上圖中的ns1.pairnic.com以及ns2.pairnic.com）。下面我們對這些域名服務器發(fā)起查詢，以獲取infosecinstitute.com的IP地址。

#p# 現(xiàn)在在應答部分我們能夠看到infosecinstitute.com的IP地址為216.92.251.5。任務完成！

通過我們自定義的DNS服務器進行查詢并獲取不同記錄也是可行的。在下圖中，我們將使用DIG命令向谷歌的DNS服務器（8.8.8.8）發(fā)起查詢，以搜索infosecinstitute.com的地址記錄。

基本上是指提供給DNS查詢的特定記錄的有效時間。如果我們再次重復以上查詢過程，可以看到現(xiàn)在TTL的有效時間已經減少至3503。

當某個域被認定為惡意的情況下，它從全局域名空間中被清除掉的過程基本上分為兩個步驟。首先是從TLD服務器中清除對應記錄，接下來是等待其TTL在所有DNS服務器中的有效時間耗盡。

要確定某個域名的IP地址，需要了解的一大重點是該域的授權數(shù)據(jù)。授權數(shù)據(jù)中包含了域的NS記錄及其對應的A記錄，也就是域名服務器的IP地址。授權數(shù)據(jù)同樣擁有一條特定TTL，可以告訴我們授權數(shù)據(jù)將于何時進入緩存。在下圖中，我會向TLD服務器發(fā)送.com查詢，以獲取一條并不存在的子域地址。反饋回來的信息包含驗證部分以及附加部分，內容則涵蓋了指定域的NS記錄以及對應域名服務器的IP地址（即A記錄）。
 

 讓我們來看看這個實例。我將在自己的網(wǎng)站中創(chuàng)建一個名為infosec.seraching-eye.com的子域。

完成之后，讓我們使用特定開放式DNS服務器8.8.8.8（即OpenDNS）來查詢這個新域。

 
#p#  我們仍然可以在應答部分看到響應結果。同樣，我們可以看到其中包含一個特定的TTL值：14399。授權數(shù)據(jù)現(xiàn)在已經進入該服務器的緩存，因此我們再接再厲，清除剛剛建立的子域。 

正如大家所見，子域inforsec.searching-eye.com已經被成功刪除?，F(xiàn)在讓我們再進一步，再向同樣的DNS服務器發(fā)起針對子域inforsec.searching-eye.com的查詢指令。

令人驚訝的是，我們仍然收到了響應。

這是因為目前谷歌的DNS服務器緩存中仍然保留著查詢記錄。正如我們所見，TTL有效時間已經縮短至12790。至于響應存在的原因，相信大家也能夠推斷出來：由于我們在子域存在的時候曾經向該DNS服務器發(fā)出過查詢指令，因此相應授權數(shù)據(jù)就一直存在于該服務器的緩存中。

現(xiàn)在，我們要向自己的默認DNS服務器發(fā)起同樣的子域查詢指令。

根據(jù)上圖所示，我們沒有得到響應。這是因為由于我們的默認DNS服務器中并不具備相應緩存記錄，所以服務器將遍歷整個DNS層次結構，希望找到我們所查詢子域的IP地址。而一旦遍歷過程到達頂級域名（即.com）處，服務器會發(fā)現(xiàn)此記錄并不存在，最終也就不會返回任何結果。

#p# 漏洞

此漏洞由特定DNS服務器中的DNS緩存更新策略所引發(fā)。正如前文中所討論，某個域可以通過從TLD中刪除并耗盡全部DNS服務器中授權數(shù)據(jù)有效時間的方式從全局域名空間中徹底被清除。但只要能夠延長授權數(shù)據(jù)的TTL，例如使其永遠不歸零，那么這個域將始終處于可解析狀態(tài)。

請注意，并不是所有DNS服務器都存在此類漏洞。不過根據(jù)論文的闡述，此漏洞在大多數(shù)DNS服務器中都能輕松找到，因為這些服務器并沒有嚴格執(zhí)行緩存更新的邏輯要求。

第一步是注冊一個域名服務器。一般來說這種服務可以由我們的域名服務供應商提供。我希望自己的域名服務器采用xyz.mydomain.com的形式，而非xyz.hostingcompany.com的形式。請注意，我們提供的IP地址必須是一個有效的域名服務器IP。

 一旦域名服務器注冊完成，我們就要按照下圖所示將其設置為自己的域名服務器。

根據(jù)下圖所示，我們已經可以確定testns.searching-eye.com徹底設置完成。這套新的域名服務器可以用來查詢那些并不存在的子域。 
 

接下來我們創(chuàng)建另一個名為ghost.searching-eye.com的子域。
 

 這一步工作完成后，我們選取某個特定DNS服務器（當然要選那些存在漏洞的）并通過它查詢這個子域。

#p# 現(xiàn)在我們可以確定授權數(shù)據(jù)已然進入DNS服務器的緩存當中。乘勝追擊，刪除新建的子域。目前授權數(shù)據(jù)的TTL應該還存在，但處于不斷減少之中。因為我們知道授權數(shù)據(jù)包含著域的NS記錄以及域名服務器的A記錄，因此它可以表示如下：

在子域被刪除一段時間之后，授權數(shù)據(jù)可能如下圖所示：

下一步是改變域名服務器的名稱，比如改成test2.searching-eye.com。使用與之前同樣的DNS服務器（4.2.2.4），我們向其查詢域名服務器的A記錄，即test2.searching-eye.com。

解析程序將觀察授權數(shù)據(jù)并向testns.searching-eye.com的IP地址發(fā)送查詢指令，但此時該IP地址已經被test2.searching-eye.com所占用。接著解析程序會返回域名服務器的IP地址，但它也將同時發(fā)現(xiàn)存在一個新的域名服務器（因為服務器名稱已經經過改動），最終結果是它會用新服務器覆蓋掉原有的緩存內容（不同的DNS服務器可能使用不同的緩存更新邏輯機制）。在緩存內容被覆蓋之后，授權數(shù)據(jù)將如下圖所示（前提是DNS服務器并沒有嚴格遵循緩存更新邏輯，也就是說本文所討論的漏洞在該服務器中確實存在）：
 

 請注意，新的授權數(shù)據(jù)被賦予了新的TTL值。如果多次重復上述過程，那么就能夠避免該TTL歸零（當然有某些特殊情況下，該值在很長一段時間后仍然會歸零，詳細情況請閱讀文章結尾提供的論文鏈接）。

為了讓這種攻擊模式大范圍起效，攻擊者必須向盡可能多的漏洞DNS服務器發(fā)送查詢指令，旨在盡量避免授權數(shù)據(jù)的TTL有效時間耗盡。由于眾多DNS服務器的緩存中仍然保留著授權數(shù)據(jù)，因此攻擊者就能夠讓自己的惡意域始終有IP地址可用，進而使更多用戶順利訪問進來。

#p# 如何檢測幽靈域名

幽靈域名是指那些已經被從TLD服務器中刪除，但卻仍然可被DNS服務器所解析的域。其出現(xiàn)的原因分以下兩種：

對應域授權數(shù)據(jù)的TTL值尚未耗盡。請注意，如果對象域的TTL不會被刷新，那么則不應將其視為幽靈域名。

授權數(shù)據(jù)的TTL值利用DNS服務器漏洞進行不斷刷新。

下面是一些頗具指導意義的辦法，以幫助大家揪出幽靈域名。

在域中通過遍歷DNS分層結構的方式執(zhí)行DNS查詢，即本文中“DNS查詢”章節(jié)中的內容。

利用特定DNS服務器對某個域的A記錄發(fā)起查詢。

如果DNS查詢步驟無法給出回應，但卻能通過使用特定DNS服務器得到查詢結果，那么目標域很可能屬于幽靈域。我們無法確定得出確切結論，因為很可能這種現(xiàn)象是由于授權數(shù)據(jù)的TTL尚未耗盡所造成（當然也不排除其中存在TTL重置活動）。所以，目前最大的難題就是界定哪些屬于幽靈域而哪些不是。

以下步驟可能具有一定輔助作用：

記錄目錄授權數(shù)據(jù)的TTL值。

等待域TTL值剩余時間耗盡，并再次發(fā)起查詢。如果該DNS服務器仍然能夠解析目標域，那么我們可以肯定該域為幽靈域。

綜述

在這篇文章中，我們就論文中公布的漏洞展開討論。歸納來說，就是通過非法更新DNS服務器緩存的方式，人為刷新特定域授權數(shù)據(jù)的TTL值。這意味著該域在被從TLD服務器中清除后，仍然可以長期處于可解析狀態(tài)。其后我們又討論了一些方法，用于界定某個特定域是否屬于幽靈域。

參考文獻

1.幽靈域名：被消除后仍可解析
https://www.isc.org/files/imce/ghostdomain_camera.pdf
2.DNS攻擊（從入門到精通）
http://resources.infosecinstitute.com/dns-hacking/

原文鏈接：
http://resources.infosecinstitute.com/ghost-domain-names/