文/李欣琪
目前,復旦大學共有5臺DNS服務器分布于四校區,其中兩臺作為復旦域名名稱服務器(Name Server),同時提供其他域名的遞歸解析服務。因此,DNS服務直接關系到兩方面內容:1.公眾訪問復旦大學相關站點的質量;2.校園網用戶的網絡訪問質量。DNS的性能指標和統計分析,成為信息化建設的一個關注點。建立一個功能全面完善的DNS監控系統,提供DNS服務關鍵信息的統計和分析,幫助排查網絡故障,進行安全預警,具有重要的意義。
以使用最為廣泛的DNS軟件ISC BIND為例,對于BIND服務的監控和統計,可以采取執行命令或使用第三方程序如DNSTOP的方式獲取BIND進程的CPU、內存和網絡等資源消耗情況,并通過編寫腳本來統計BIND產生的日志,獲取相應的查詢記錄。但當DNS服務處于高負載的條件下,這種方式無法及時處理迅速增長的日志,同時頻繁的日志讀取很快會帶來I/O上的瓶頸,甚至影響到DNS服務的質量。
因此,本文提出了一種分布式架構的DNS實時監控系統的設計方案,利用流式數據存儲和分布式計算實時處理DNS性能數據,改變了傳統通過人工排查DNS故障的方式,提高了DNS服務關鍵信息統計和分析的效率,提升了系統的穩定性和安全性。

圖1 DNS運行流程
根據服務類型,DNS可以分為遞歸和迭代兩種。如圖1所示,當用戶要訪問目標域名時,首先查詢本地DNS緩存,如果沒有該域名的解析記錄,則向本地DNS服務器提交查詢請求,由本地DNS服務器代為解析,這一過程稱為遞歸。其中,本地DNS服務器接收到請求后,首先判斷本地緩存中是否有該域名解析記錄。如果有則直接返回相應的IP地址;如果沒有則向十三臺根域名服務器提交查詢請求,并以迭代方式輪詢,直到獲知該域名的解析結果。
上述過程中產生了大量的數據交互,為了了解DNS的運行服務狀況,我們需要對DNS的各項指標進行實時監控。除了常規的CPU、內存、I/O、網絡和進程狀態之外,還需要針對DNS的各類請求進行更細粒度的監控和分析。
首先,需要對DNS實時請求數、A類地址查詢數、CNAME類地址查詢數、MX郵件交換查詢數、AAAA IPv6地址查詢數等不同類型的DNS查詢進行分析和統計,計算各類型的數量及比例,幫助管理員在總體上掌握網絡概況。
其次,分析和統計不同域名的請求次數和頻率,可以了解各業務系統的訪問狀態,以及互聯網訪問的集中區域。
再次,通過統計和分析DNS請求的IP來源也可以從宏觀上掌握整個校園網的網絡請求來源分布和熱點區域;特別對于對外提供訪問服務的站點,可以獲知來訪者在地區上的分布情況。通過以上信息,我們可以實時獲取DNS的運行狀態,以及電子郵件、網站等訪問情況。根據校園網用戶的DNS請求IP來源統計,我們還可以判斷出校園網熱點區域,這些信息可以輔助我們判斷網絡狀況。假如某個區域在一段時間內的DNS請求數相比最近的一段時間,出現急劇下降的情況,很可能是該區域的網絡連接出現了故障,如果出現急劇上升的情況,很可能是該區域存在惡意訪問行為。這些信息都可以幫助管理員在第一時間內追蹤問題根源。同時,通過監測來自互聯網的DNS請求,分析和統計其IP來源、請求對象和頻率,可以發現包括DNS放大攻擊在內的惡意請求,也可以有針對性地對爬蟲的請求進行過濾和屏蔽。
最后,從用戶體驗的角度進行響應時間及DNS服務可用性監測。用戶的網絡訪問首先要通過DNS解析獲取所要訪問域名的IP地址,因此DNS的服務質量直接關系到網頁加載和頁面打開的速度,影響用戶對網絡質量的整體感受。為了更深層次地了解DNS的服務質量,還需要模擬用戶向DNS發出請求的過程,對DNS響應結果和響應時間進行檢測。

圖2 監控系統架構
根據上述需求,對DNS實時監控系統的架構進行設計,如圖2所示。監控系統包括控制中心、數據傳輸、數據清洗、索引、分布式存儲、檢索、統計分析和可視化等部分。
通過控制中心向DNS集群下達數據傳輸任務,DNS集群將各類性能數據和日志文件通過數據傳輸模塊發往指定的存儲區域進行集中化存儲。由于原始數據的類型和格式各異,所以需要根據數據源分別對各類數據進行數據清洗,去除格式異常的無效數據,并將其轉換為預定義的邏輯結構。接下來數據將會以流的形式發送給索引模塊,索引模塊為數據建立索引,并將其存儲至HBase節點上。對于前端用戶發起的查詢請求,檢索模塊通過HBase集群的讀寫接口進行并行處理,并將結果返回給用戶。同時,可視化模塊負責提供數據的多樣化展示。
DNS服務器時刻都在響應用戶的請求,大量的數據在會話中產生。這其中量最大的就是刻畫服務性能的相關數據。例如,服務器實時的CPU、內存使用率,網絡帶寬的使用情況,并發請求數等等。另外,通過配置,DNS能夠以對服務器的性能指標進行統一管理,需要將這些數據統一傳輸到監控系統的后端存儲上進行集中處理。數據傳輸任務由控制中心向各DNS服務器下發,可使用FTP、SCP等多種傳輸方式。
對于傳輸到監控系統后端存儲上的數據,由于其格式各不相同,并且可能包含一些無效的數據,所以在進行索引和分析之前,需要對數據進行統一的清洗。數據清洗主要通過Fluentd來實現。Fluentd是一款開源的數據流收集系統,它的特點在于其輸入輸出部分均是可定制化的,用戶可以通過簡單的配置,將數據流以指定格式輸出到目標位置。例如,一條典型的DNS查詢請求格式如下所示:
18-Aug-2012 15:05:19.975 info: client 175.186.6.136#56377:view internal: query: www.hao123.com IN A +
各字段分別記錄了請求日期、時間、請求來源和端口,以及請求對象和請求類型。為了從中提取對數據統計和分析有價值的信息,可以通過構造正則表達式定義如下的Fluentd數據格式配置來對該條數據進行整理:
format /^(?
整理后的數據為Key-Value的形式,非常適合做進一步地處理。
為了提高數據檢索的速度,需要將清洗后的數據做進一步的處理而不是直接進行存儲。首先將數據通過全文索引工具Lucene進行處理,由于是文本文件,Lucene使用Text File Parser對數據進行解析,提取出索引項和相關頻率等信息。接下來Lucene對數據構建反向索引并進行存儲,其中反向索引包含搜索關鍵詞所對應的所有文檔,通過這種方式來提高對文檔關鍵詞的檢索速度。但隨著處理數據量的增加,索引的規模也在迅速膨脹,直接基于文件系統存儲索引會使檢索性能明顯下降。本文通過將Lucene索引存儲到專為海量數據處理而設計的HBase之上,能夠很好地利用HBase高可靠性、高性能、可伸縮的分布式存儲特點,即使在索引規模較大的情況下也能夠實現實時的查詢。
對于監控系統的數據傳輸、數據清洗、索引和存儲等任務,都需要由控制中心來統一下發命令和進行任務調度。在數據傳輸過程中,控制中心需要實時檢測傳輸是否中斷,傳輸完成之后還要再次檢查線上數據和監控系統后端存儲數據是否一致。如果兩份數據不一致,控制中心需要通知數據傳輸模塊進行重傳。對于成功傳輸的數據,控制中心會通知傳輸模塊將其從DNS線上服務器刪除。同樣,數據處理的其他各階段,也需要控制中心來監控處理過程,對于出現異常的任務需要重新啟動,只有順利完成的任務才能夠進入下一個階段進行進一步的數據處理。
經過索引后的數據,可以通過監控系統的前端提交查詢請求。查詢請求的格式支持Lucene的查詢語法,同時支持多條件、多字段的綜合查詢。例如,需要查詢2013年07月03日所有查詢fudan.edu.cn域名的請求情況,可以輸入以下語句進行查詢:
Date:”2013-07-03” AND domain:”fudan.edu.cn”
檢索模塊將通過HBase查詢接口對索引數據進行查詢,并返回所有的結果。
對于DNS的各項監控指標,單純從記錄查詢和數據統計上可能無法對DNS的整體運行狀況有全局性的了解。因此對監控數據進行可視化展示和對比能夠讓管理員對DNS運行狀態一目了然。本文設計的監控系統通過橫向和縱向對比各監控指標所占的比例和趨勢,提供柱狀、餅狀和熱力圖等可視化方式,使管理員全面掌握DNS以及網絡的運行情況。

圖3 DNS監控系統數據檢索頁面

圖4 DNS各類查詢比例

圖5 DNS每日統計報表

圖6 DNS請求來源
以最流行的DNS軟件BIND為例,使用本文設計的監控系統進行實時監控。BIND配置文件的語法允許使用logging關鍵字定義不同的channel,每個channel指定存放日志信息的文件名、文件個數及大小、消息等級,并指定日志內容是否包括時間和消息的類別。通過配置可以將DNS運行時產生的一些關鍵信息以文本形式保存在磁盤上,關鍵配置如下所示:
Logging {
channel security_log {
File "/home/dns/log/dns-sec.log" size 10240m;
Severity info;
Print-severity yes;
Print-timeyes;
};
channel query_log {
File "/home/dns/log/dns-query.log" size 10240m;
Severity info;
Print-severity yes;
Print-timeyes;
};
channel default_log {
File "/home/dns/log/dns-default.log" size 10240m;
Print-category yes;
Print-time yes;
Severity info;
};
category security { security_log; };
category queries { query_log; };
category default { default_log; };
};
5臺DNS使用同樣的日志配置,并以logrotate的方式每15分鐘進行輪轉??刂浦行目刂茢祿鬏斈K將生成的數據實時發送到監控系統的后端存儲上進行數據清洗。經過索引后的數據可以接受來前端的實時檢索。通過監控系統前臺檢索某天某段時間內的DNS查詢請求效果如圖3所示。
對于各類DNS監控指標的實時可視化效果如圖4所示。當DNS流量或并發請求出現異常時,為了進一步排查,需要對請求來源做統計分析,請求來源可視化可以為解決此類問題提供幫助。如圖5所示,通過某天的DNS流量統計報表發現其中一臺DNS流量同比有大幅上漲,通過圖6所示的DNS請求來源統計可以迅速定位可疑IP地址,并通過監控系統的前臺檢索該IP請求內容,進一步確認該IP是否存在惡意訪問行為。
同時,DNS監控系統對請求來源實時繪制熱力圖,根據其IP來源映射到所屬的地理位置,并以標注點的明亮程度代表請求的數量多少。熱力圖支持通過正則表達式過濾IP來源和查詢歷史。
本文設計和實現了一種DNS實時監控系統,能夠實時分析和統計DNS的各類請求及來源分布,并通過統計報表及可視化的手段幫助管理員從全局把握DNS和網絡的運行狀況。在實際應用中,該實時監控系統能夠幫助管理員及時發現網絡中潛在的問題和風險,進行預警和告警,還可以幫助管理員進行細粒度的問題排查,具備處理高效、監控精準、響應實時、統計分析全面的特點。