目前13臺根域名服務器且均在國外[3],我國互聯網的核心域名資源面臨着隨時受制於人的窘境。我國雖於2003年後先後引進F、I、J三個根域名服務器的鏡像,在一定程度上提高中國境內互聯網用戶連接相關網站的速度。但由於最終的數據仍然會被傳送到位於國外的主根域名服務器上,在特殊情況下,我國互聯網仍面臨着因根域名服務器無法提供域名解析而導致癱瘓的問題[4]。
國際上已經開展了通過探索新型域名解析體系的方式,尋求現行域名解析體制的替代方法,如Open NIC[5]、New.NET[6]、Name.Space[7]等。1997年,增強域名系統(eDNS)進入試驗階段,它是現有DNS系統的替代品。這種系統使用自己定義的域名架構。1998年4月計算機專家Eugene Kashpureff也創建了一種新的域名解析系統AlterNIC。但這些系統目前多爲試驗產品,尚未推廣使用。
開發並使用全新的替代域名系統代價較高,而要想馬上完全擺脫國外在域名上的控制權是相當困難的。因此,當前可行的辦法是,在現有域名解析體系的基礎上,研究建立一個適合我國現狀的DNS根/頂級域名服務器應急備份恢復系統,用於特殊時期在國外根/頂級域名服務器不能提供域名解析服務時,可以及時、高效、準確地解析國內DNS請求,確保國內用戶能夠正常使用互聯網。該類工作在CERNET網已作了相關探索[8]。
本文所設計的DNS根/頂級域名應急備份恢復系統主要由DNS信息獲取系統、DNS信息存儲系統、DNS查詢接管系統和DNS應答系統四大部分組成,通過大規模地收集國內及國外的DNS信息,以響應特殊時期國內對的DNS服務要求。如有異常,則迅速啓用DNS應急備份方案。而後採取基於目的地址重定向的DNS請求接管方法,將DNS請求引導到應急備份系統中,通過DNS應答系統作出相應應答。該系統的基本架構如圖1所示。
其中,DNS信息獲取系統結合了在網絡出入口進行監聽被動捕包的方式[10],以及通過指定域名信息主動向特定域名服務器請求獲取相應DNS信息的方式。因第一種方式與本文所介紹的處理應答包的方法類似,因此本文將重點介紹第二種方式。
1 域名信息獲取主動系統設計與實現
1.1 總體結構
本系統分爲以下幾個模塊:
a)DNS請求模塊。從域名源獲取待請求域名,DNS請求包的封裝,請求域名服務器的選取,DNS請求包的發送和重發。
b)DNS解析模塊。DNS響應包的捕獲,解析及各種響應包的處理。
c)請求管理模塊。請求節點的插入和刪除,超時請求的處理。
d)DNS信息存儲模塊。將解析後的資源記錄有組織地存儲到數據庫中,以備恢復時使用。
DNS解析主要用於對其他應用協議(如HTTP、 FTP、E mail)的支持,請求頻率不高,所以多數的DNS解析都是同步的。即在一個請求沒有返回或者未作超時處理時,後續的解析就阻塞在那裏。作爲DNS應急備份系統的數據源和更新源,要求在單位時間內儘可能多地獲取有效的DNS信息,因此本文采取了異步DNS解析方式,以便有效利用單個域名服務器在進行查詢的空閒,發出更多的請求,其系統框圖如圖2所示。
域名請求發送(圖3)和響應接收(圖4)的主要流程爲:從域名列表或域名數據庫中取出一個域名,根據DNS協議的規定封裝成DNS請求包,作爲待發送請求,從域名服務器池中選則一個請求服務器,查看發送隊列是否已滿,是則等待,否則向該域名服務器發送新的請求;每發送一個DNS請求包,將其請求內容及相關信息構成一個請求節點插入到請求隊列的尾部,這樣在請求隊列的頭部則爲時間軸上靠前的請求;每收到一個DNS應答包,通過其ID找到相應請求節點。若此應答包爲非REF包,則刪除相應節點。若此應答包爲REF包,則根據REF包中的ref信息向下一跳域名服務器發出新的請求;在發送請求包和接收應答包的同時監視請求隊列頭部的請求節點是否超時,超時則作重傳或刪除處理。
1.2 DNS請求模塊的設計與實現
本模塊任務是:根據DNS協議規定,封裝DNS請求包;域名服務器池的建立,分配及其維護;向選定的域名服務器發送DNS請求包。
1.2.1 DNS請求數據包的封裝
爲了構造DNS請求包和解析DNS數據包,需瞭解DNS報文格式。請求和應答採用UDP協議傳送。下面簡要介紹本文涉及的DNS報文格式內容,其他可參照RFC[1035][2]。
1)DNS請求報文格式
在DNS協議中所有的通信都是通過一種簡短格式的報文傳遞的。該報文由12 Byte長的首部(header)和4個長度可變的字段(question、answer、authority和additional)組成。其中,首部指明瞭接下來報文中將包含哪些段以及此報文是請求還是響應、是標準請求還是其他的類型。Question(問題)段包含向域名服務器提出請求的信息,answer(答案)段、authority(權威)段、additional (附加)段均採用一種稱爲資源記錄RR(resource record)的相同格式。答案段中包含直接回答問題段的資源記錄,權威段包含可以指向權威服務器的RRs(基本上是NS記錄),附加段包含和請求相關的信息,但不是直接回答的問題(如NS,MX記錄對應的A記錄)。
首部格式如圖5所示。
ID
OROPCODATCRDRAZRCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT
圖5 DNS報文首部格式
ID:16位,請求報文中的ID將複製到應答包中,可用於響應與請求的匹配。
接下來的兩字節爲Flag位:
QR:1位,0表示是請求報文,1表示是響應報文。
OPCODE:4位,表示請求類型(本項目發送標準請求,OPCODE=0)。
RD:1位,值爲1時表明要求遞歸解析。
RCODE :4位。表明應答狀態及各種錯誤。0爲無錯誤有效應答。
QCOUNT、ANCOUNT、NACOUNT、ARCOUNT都是16位,表明相應段中含有RRs記錄的個數。
構造DNS請求包時,應將待請求的域名和請求的類別按照DNS數據包的格式要求加入到Question段,而後再加上首部,封裝成DNS報文。
Question段主要由以下三個字段組成:
a)QNAME。待請求的域名,要按照規定將點分制的域名轉換成多個標誌符的隊列。每個標誌符=一個字節的字符數+標誌符。整個域名以0結尾。規定字符數的最高位爲0(表示非壓縮域名),所以每個標誌符的最大字符數爲63。
b)QTYPE。16位,表示DNS協議所支持的查詢類型。查詢常用的類型和相應的編碼爲如表1所示。#p#分頁標題#e#
表1 QTYPE類型
A1IP地址
NS2權威域名服務器
CNAME5規範名稱
SOA6域權威開始記錄
PTR12域名指針(提供IP向域名解析)
c)QCLASS。16位,IN(1) 表示面向Internet。
2)構造DNS請求報文舉例
下面以請求www.google.com的IP地址爲例,說明構造DNS請求報文的實現方法:
a)構建question段
①QNAME:將www.google.com轉換成3www6google3com0;
②QTYPE:預獲得IP地址,則請求類型應爲A,QTYPE=1;
③QCLASS =1;
b)構建首部
ID,FLAG=0x0100,QCOUNT=1,ANCOUNT=0,NACOUNT=0,ARCOUNT=0。
於是構建的DNS報文如圖6所示。
1.2.2 DNS請求數據包的發送
DNS數據包的發送利用Libnet庫完成。Libnet是UNIX系統上網絡安全工具開發的接口庫[12],提供一系列的接口函數,實現和封裝了數據包的構造和發送過程。利用它可以構造DNS數據包的封裝,並將其以UDP方式發送出去。
如圖7所示,首先對Libnet初始化,將發送方式選爲基於IP層的IPV4_RAW的數據包,參數爲LIBNET_RAW4, 通信所用的設備選擇eth0(可根據主機實際使用網卡選擇);調用libnet_build_dnsv4()函數,構造DNS包(參數設定見1.2.1節);DNS標準請求用UDP協議發送,調用libnet_build_udp()函數,並將端口號指定爲53;而後調用libnet_build_ipv4()函數,並將請求的域名服務器的IP參數傳入,完成DNS的IP數據包構造;最後調用libnet_write()函數將請求包發送出去。由於每次數據包發送時需要的libnet的初始化參數相同,只調用一次libnet_init()初始化函數,在每次發送之後調用libnet_clean_packet()將協議塊和發送緩存清空,爲下一次數據包的發送做準備。
1.2.3 域名服務器池的建立與維護
向一個域名服務器大規模的發送查詢請求,會導致域名服務器負載過重,應答效率將低。所以本文在全國範圍內選取多個公共域名服務器,將請求分散,進而避免對單一域名服務器請求過量,同時當某域名在一個域名服務器得不到應答時,可以從域名服務池中選取其他域名服務器繼續請求。
具體實現爲:將選取的域名服務器IP地址存儲在一個servername.dat文件中,在系統初始化時讀取servername.dat中的IP地址,併爲每一個IP維護一個狀態結構體。其中包括域名服務器服務狀態量state(1爲可用,0爲不可用),失敗應答計數器。每個結構體以雙向鏈表的形式構成域名服務器池,循環挑選可服務狀態的域名服務器作爲DNS請求對象。
當對於一個域名服務器的多個請求沒有響應時,可認爲該域名服務器已不能正常工作,便將其標記爲不可服務,不再爲其分配請求,直到此域名服務器又恢復響應能力。爲檢測域名服務器是否重啓,本系統採用了重複檢測及檢測間隔時間指數級退讓的算法[14]。具體流程如圖8所示。
1.3 DNS解析模塊的設計與實現
本模塊完成的任務是:捕獲DNS響應包,解析及各種響應包的處理。
1.3.1 DNS應答包的捕獲
本系統採用伯克利數據包過濾機制,並利用基於BPF(Berkeley packet filter)過濾機制的Libnids數據包捕獲工具實現DNS數據包的捕獲[12]。
首先進行Libnids的初始化,通過以下三個參數的設定,達到捕捉DNS包的目的。
a)nids_params.pcap_filter = port 53,將LIBNIDS的過濾端口號設爲53。
b)nids_params.device = eth0,接收網卡爲eth0。
c)nids_params.promisc = 1, 把網卡設爲混雜模式。
因DNS靠UDP協議傳輸,故聲明一個udp_callback()函數,並註冊到libnids環境中。這樣,當有目的端口號或源端口號爲53的DNS數據包經過eth0網卡時,將自動調用udp_callback()函數,完成此函數內用戶自定義的DNS解析功能。
1.3.2 DNS應答包的解析
1)應答包格式說明
在DNS請求包的封裝部分已介紹了DNS數據包首部和問題段的格式。在DNS應答包的解析部分主要是對DNS數據包答案段、權威段、附加段的解析。在答案段、權威段和附加段中,DNS信息統一由一種稱做資源記錄(RR)的格式組織。RR的格式[2]如圖9所示。
0123456789101112131415
NAME
TYPE
CLASS
TTL
RDLENGTH
RDATA
圖9 RR格式
其中:NAME是按照前文所描述的格式的域名;TYPE和CLASS的意義也與問題域所提及的意義相同。只是TYPE要比QTYPE的類型多一些;TTL是一個32位的有符號數,代表此條資源記錄的生存期,若TTL爲0表明此條資源記錄是易變的或過期的,不適於緩存;RDLENGTH是一個16位無符號數,表明下一字段RDATA的字節長度。對於不同類型的資源記錄,RDATA字段的格式也各有不同。
2)應答包的分類
首部RCODE的值反映了DNS應答的情況,其值[2]如表2所示。
表2 RCODE值對應表
RCODE描述
0無錯誤
1格式錯誤域名服務器無法解析該請求
2服務器失敗
3域名不存在
4沒有完成
5拒絕服務
由於域名服務器實現的多樣性,RCODE值配置的反映錯誤情況也不盡相同,例如RCODE=3通常表示請求域名不存在,而在ref應答包中RCODE也等於3。所以本系統未採用RCODE值作爲區分應答包類型的標準,而是根據各段的資源記錄數分類。
當答案段不爲空時,此應答爲有效應答,將應答包中所攜帶的資源記錄都解析出來並儲存在數據庫中。當答案段爲空,權威段不爲空時,此應答爲ref應答,將作迭代查詢處理。
3)有效應答包的處理
在有效應答包中,除在答案段有相應的答案外,權威段和附加段中也會有與此域名所在域相關的信息。若將所解出的資源記錄直接存到數據庫中,將破壞這些資源記錄的相關性,不利於後期區文件的恢復。因此,在DNS資源記錄解析時,解出權威段中NS資源記錄的NAME的同時,將此NAME作爲這個包中所有資源記錄的域,儲存在數據庫的相應列中。這樣,將具有相同域的資源記錄組織在一起,使得大量的資源記錄可以恢復成一個區文件,便於恢復時加載到BIND[8]解析系統中,提供DNS查詢服務。#p#分頁標題#e#
4)ref應答的處理
對於ref應答,系統提供迭代查詢功能。對於權威段不爲空的情況,權威段攜帶的資源記錄通常有兩類,即SOA記錄和NS記錄。SOA指出迭代查詢下一跳的所在域,NS指出迭代查詢下一跳的域名服務器。可根據應答包中和NS匹配的A記錄的IP,向下一個域名服務器進行請求。
有些ref應答包,不含有和NS相關的IP信息。爲了處理這種情況,本系統建立了一個搜索表,記錄域和對應的域名服務器的IP,用SOA和NS記錄反映出的域,在搜索表中找到相應的域名服務器的IP地址。迭代查詢流程如圖10所示。
1.4 請求管理模塊的設計與實現
1.4.1 請求隊列的創建
如前文提到的,若大規模向域名服務器發出DNS請求,會增加DNS服務器負擔,並佔用大量的網絡資源。爲了對DNS請求包的發送速率和接收速率進行調節,本系統設置請求隊列管理模塊,由發送線程和接收線程共同控制,以提高請求效率的同時保證應答的質量。同時,該隊列維護的各參數也可反映出當前系統的運行狀態。
存儲結構:雙向隊列,索引表。
請求隊列中各節點包括ID、請求內容、發送時間、迭代請求數refcount。
功能:應答與請求的匹配,控制發送速率,處理過時請求,記錄運行狀態。
其中,ID作爲應答與請求匹配的標準。正如前文所述,DNS請求包的ID在域名服務器作出應答時會原封不動的拷貝到DNS應答包中。所以當本系統收到應答包後,將解析出的ID作爲關鍵字,在隊列中查找具有相同ID的請求,進行匹配。
隨着隊列長度的增大,ID查找時間將會增加,嚴重影響系統的性能。所以實現時爲請求隊列創建了一個索引表,以ID爲索引關鍵詞,節點地址作爲索引項。當查詢時先用ID在索引表中查找到對應的地址,然後通過地址訪問進行相應請求節點的處理。
索引表通常採用二叉樹和Hash表兩種形式,鑑於二叉樹對動態插入和刪除的良好支持,本索引表採用二叉樹方案。利用C函數庫中的tsearch()、tfind()、twalk()、tdelete(),創建和維護請求隊列的搜索表。
1.4.2 請求隊列的管理
該隊列同時有三個線程對其操作,即發送請求時插入節點、取得應答時刪除相應節點和超時請求處理。
具體流程如下:
a)查看發送隊列是否已滿,是則等待,否則發送新請求。
b)每發送一個DNS請求包,將其請求內容及相關信息構成一個請求節點插入到請求隊列的尾部,這樣在請求隊列的頭部則爲時間軸上靠前的請求。
c)每收到一個DNS應答包,通過其ID找到相應請求節點。若此應答包爲非REF包,則刪除相應節點;若此應答包爲REF包,則取得此節點的refcount後刪除此節點,將refcount+1後,與REF包中的請求段等其他信息構成新節點加入隊列的尾部。
d)掃描隊列的頭部的請求節點是否超時,超時則重傳或刪除。
通過此隊列的管理,可維持在網絡中的請求數小於隊列的最大長度,同時又可以保證有應答返回後,立即會有新的請求發出。
1.4.3 超時處理(圖11)
因網絡狀況不佳,域名服務器無響應等原因,在DNS請求中不可避免地會出現請求有去無回的現象。如果對此類超時請求不作及時處理,很快就會堵塞請求隊列,使新的請求無法發送出去。所以本系統建立超時處理線程,當發現請求隊列中有超時節點時就將其重傳或刪除。在設計發送隊列時已考慮超時處理的需要,每次只在發送隊列的隊尾插入新的請求,這樣隊列的頭部一定是在時間軸上排在前面的請求,如果其未超時,那麼隊列中則未超時。
本系統實現時超時時間設爲5 s(參考Windows 2000 DNS服務設置)。
1.4.4 重傳
DNS協議通過客戶服務器交互的形式實現請求與響應。因DNS數據包採用非可靠的UDP協議傳輸,爲處理域名服務器沒有響應而在客戶端設置重傳機制是很有必要的。雖然可以爲DNS數據包添加序列號,但由於數據包會在網絡中重排列或者在域名服務器中打亂處理順序,並不能像TCP協議一樣依據序列順序判斷是否丟包或重傳。在RFC1034和RFC1035中並沒有重傳機制的規定,但是RFC1035建議最佳的重傳機制原則應根據客戶端的需要和網絡的性能而定。基本原則爲:客戶端應避免重複地向同一服務器地址發送同一個請求,而應該先嚐試其他的服務器。
重傳的時間間隔應基於預先的統計計算。頻繁的重傳會導致整體的響應效率明顯下降。可根據客戶端與服務器的連接情況調整重傳時間間隔。通常最小的重傳時間間隔應爲2～5 s。本系統統實現時將超時重傳時間設爲5 s,當檢測到請求超時後則進行重傳。最大重傳次數爲3。
1.4.5 請求隊列管理對發送速率的影響
下面通過MATLAB計算仿真請求隊列的管理對發送速率的影響。
設一個請求響應的往返時間爲rtt,超時時間爲timeout,接收率爲p,請求隊列長度爲L,設發送速率函數爲SEND(t/rtt),觀察T時間內的發送速率SEND的情況。
假定在理想情況下,當發送隊列較小時,請求的域名服務器穩定響應,網絡也未出現擁塞狀況,丟包率完全因爲採用UDP傳輸造成,則丟包率爲定值,接收率也爲定值P
並假定每個請求的往返時間相同爲rtt, 忽略發送時間,即接收到響應後立刻發出新的請求:
在t=0時發出L個請求包,則
SEND(0)=L
當t=rtt時,有LP個應答包收到,並立即發送出新的請求,則
SEND(1)=LP
此時隊列中的等待處理請求爲L(1-P),即SEND(0)(1-P);
當t=2rtt時,有前一次發出去的請求包的一部分應答到,SEND(1)P個應答包接收到,則
SEND(2)=SEND(1)P
依此類推,在未作超時處理之前的第i個rtt時間段發出的請求數爲
SEND(i)=SEND(i-1)P(1)
當t=timeout=Mrtt時,在第一個rtt內所產生的待處理的請求達到超時時間,將被刪除,則此時發出的請求數應爲因上一次發出的請求而收到的應答和刪除超時請求後隊列所產生的空餘位置的總和。所以發出的請求數爲
SEND(M)=SEND(M-1)p+SEND(0)(1-P)
當t=timeout+rtt=(M+1)rtt
SEND(M+1)=SEND(M)+SEND(1)(1-P)
即當ttimeout時,#p#分頁標題#e#
SEND(i)=SEND(i-1)P+SEND(i-M)(1-P)(2)
根據式(1)(2),設rtt=500 ms,L=2 000,P=0.7,用MATLAB計算每個時間段的請求包的發送數,畫圖得發送速率的變化趨勢如圖12所示。
如圖12所示,通過請求隊列的管理,可以根據當時的接收率使發送速率在短時間內穩定在一個合適的值。
由上述推導公式中可以看出,SEND與L爲一次方關係,即在接收率不變的情況下,平穩時的發送速率與隊列長度成正比。所以在發送速率不影響接收率的情況下儘量增大隊列長度,可提高系統DNS信息的接收效率。
若當系統運行中t=t2時,接收率發生變化,p=P2,那麼:
當t-timeout
SEND(i)=SEND(i-1)P2+SEND(i-M+1)(1-P)(3)
而當t-timeoutt2時,超時處理的同爲在接收率是P2下的待處理請求,所以
SEND(i)=SEND(i-1)P2+SEND(i-M+1)(1-P2)(4)
根據式(1)~(4),當接收率由P=0.7變爲P=0.6時發送速率變化趨勢如圖13所示。
1.5 DNS信息存儲模塊的設計與實現
爲滿足存儲大量DNS信息的需求,DNS信息存儲模塊對性能有很高的要求。既要考慮添加數據時頻繁的插入和更新操作,又要考慮到存儲結構以便區文件的恢復和DNS的查詢響應。
1.5.1 結構設計
採集到的DNS數據包中主要有A、NS、MX、SOA、CNAME和PTR等DNS記錄類型。根據這些記錄類型中存儲信息的不同和後期DNS信息備份還原的需要,本系統採用如圖14所示的數據組織方式。
1.5.2 性能優化
在DNS數據存儲過程中,主要是對舊的、重複的資源記錄的刪除操作和對新記錄的插入。隨着數據量的增大,數據庫的刪除,插入動作將佔用大量資源和時間,成爲系統的瓶頸。本系統實現時採用添加索引和爲表分區兩種方式提高數據庫的性能。
本系統在經常需查詢的數據,建立索引。如在where子句出現的host、name等在各表處都添加了索引,性能顯著提高。
數據庫分區是一種物理數據庫設計技術,可以使特定的SQL操作減少數據讀寫的總量以縮減響應時間。例如在select語句掃描操作中,若知道哪個分區中才包含特定查詢中需要的數據,它就能直接去掃描那些分區的數據,而不必全表掃描。分區是否能有效地提高效率關鍵是分區表達式和SQL語句的關聯程度。以dnsA爲例,在DNS數據存儲過程中主要是對某主機的新舊信息進行更新,所以主機名host爲主要查詢變量。本系統採用hash分區方式將表按照host分爲10個區。本數據庫採用MySQL5.1[15]支持的hash分區方式,但該現版本的數據庫系統對分區函數支持有限,只支持少量關於數字和時間的分區函數。所以在dnsA中增加一列hostascii,其值爲host的第一個字符的ASCII碼,以此數據作爲hash函數的變量。相應地在查詢、刪除SQL語句的where語句中也加入hostascii標準。對於有惟一鍵的表,分區表達式必須包含所有惟一鍵(對於符合鍵,包含其中一部分即可)。所以將hostascii與dnsA_ID一起共同設爲主鍵。
2 數據分析與系統測試
1)測試環境 硬件平臺爲曙光天闊620R服務器;網絡平臺爲服務器所在網絡爲千兆網絡;操作系統爲Linux RedHat AS5;數據庫系統爲MySQL 5.10。
2)測試測試1 同步DNS解析與異步DNS解析性能對比
將請求隊列大小設爲1,則相當於同步DNS解析。以此與請求隊列大小爲64的異步DNS解析對比。表3爲以上兩種模式下在10 min內對同一域名列表發送請求的發送速率、接收率和成功率。其中,接收率=接收應答包數/發送請求包數;成功率=接收到的有答案的應答包數/發送的原請求包數,此參數可反映解析的準確率。
表3 同步模式與異步模式性能對比表
請求隊列大小164倍率
原請求數27617 41563.1
ref請求數321 13735.53
總請求數30818 55260.23
有答案應答包15910 45065.72
Ref應答包331 25438
總應答包20212 38961.33
接收率65.5866.78+2%
成功率57.6160+4%
從表3可看出,異步DNS解析模式的效率大大高於同步模式,且接收率和準確率都未有下降。從與原請求率的倍率基本看出,發送速率幾乎與隊列長度呈線性增長的關係。
測試2 請求隊列的長度對性能的影響
爲研究請求隊列的長度對發送速率、接收率、成功率的影響,令隊列長度在500~7 000(步長爲500)範圍內變化,時間長度爲5 min,對同一域名文件內的域名進行解析。
各隊列長度發送速率穩定過程如圖15所示。從圖15可以看出,發送速率的變化規律基本與仿真結果相同。請求隊列越大,平衡建立初期發送速率的波動越大,平衡建立時間越長。這說明請求隊列越大,隊列建立初期對網絡的衝擊越大。
同時可以發現,發送隊列越大,發送速率越快。200 s之後,各隊列發送速率已經穩定,求出各隊列長度200~300 s的平均發送速率,數值如表4所示。
表4 各隊列長度穩定期發送請求的平均速率
隊列長度平均速率/個/s隊列長度平均速率/個/s
500246.111 000532.8
1 500731.482 000927.82
2 5001 405.153 0001 492.07
3 5001 864.084 0002 112.76
4 5002 289.635 0002 491.86
5 5002 547.26 0002 536.31
7 5002 672.78 0002 879.39
爲更好地反映發送速率與隊列長度的關係,以請求隊列長度爲X軸,5 min內各參數爲Y軸繪圖,如圖16所示。
從圖16可以看出,在同一網絡環境下,對於隊列長度request_length存在一個最佳值L(在本測試條件下是4 500)。
在request_length4 500時,5 min內的發送數和接收數都基本上呈線性增長,發送速率和接收速率與隊列長度成正比,丟包率較小,在可接收範圍內變化。這是因爲,較少的請求沒有對網絡和系統帶來負擔,丟包率基本上由於UDP傳輸所導致,丟包率一定。請求隊列中超時請求所佔的比例較少,一直保持大比例的活躍狀態。發送速率基本上由隊列長度決定,而接收速率由發送速率決定。
當4 500
當request_length6 000時,有答案數和接收的數據包數都有所下降,接收速率的減少使得隊列中超時過多的應答包的帶來使系統不能維持原有的性能,使性能更加惡化。此時大的丟包率使得請求隊列中超時請求佔了大部分,由於隊列長度本身已經很大,每次刪除超時隊列中的超時請求後,同時會有大量請求發出,加劇了對網絡和域名服務器的衝擊。此時,請求隊列已經失去了對發送速率的控制,發送速率極度的不穩定,忽快忽慢,造成系統性能嚴重惡化。#p#分頁標題#e#
由上可以得出,請求隊列對發送速率的自適應控制是以較低的丟包率爲前提的,所以當丟包率增大時要通過減小隊列長度,減小對網絡及域名服務器的衝擊,保持系統的高效穩定。
測試3 24 h系統運行情況
將隊列長度固定爲4 500,24 h運行異步DNS解析模塊的程序。圖中X軸爲時間軸,從18:00運行到次日18:00,Y軸爲1 min內的各參數值,趨勢如圖17所示。
圖17中每分鐘接收數和接收率在凌晨0:00～6:00有明顯的提高,這是由於夜間的網絡負載較低,網絡狀態較好導致。同時也說明請求隊列的設置本身有一定自適應調節發送速率的能力,網絡狀態較好時,發送速率就高一些,網絡情況較差時,發送速率就較低。各參數統計值如表5所示。
表5 24 h運行各參數統計
項目數值
原始請求發送數1.66 292108
ref信息發送數1.20 593107
總髮送數1.78 351108
有答案應答接收數4.27 736107
ref信息接收數6.03 007107
總接收數1.11 736108
每秒請求發送數2 052
每秒應答接收數1 286
每秒有效應答接收數492
平均接收率0.6 237
測試4 針對ref信息的迭代查詢的效率
在軟件測試階段發現,在選取的域名服務器中,雖然所有的域名服務器對請求都有應答,但部分域名服務器並不提供遞歸查詢服務[11]。對於非遞歸域名服務器,其將返回ref信息。爲了解ref信息所佔的比例及其對性能的影響,作了如下測試:
考慮到不同域名服務器對不同域名的迴應能力不同,本測試只選取一個域名服務器,通過向其發送非遞歸請求以模擬域名服務器不支持遞歸請求的情況,即將請求包的RD位置0。測試數據爲:域名文件中域名數有1 000個,域名服務器IP地址爲202.138.96.2。測試結果如圖18所示。
其中:A爲客戶端不支持迭代查詢;B爲客戶端支持迭代查詢,域名服務器不支持遞歸查詢;C爲客戶端支持迭代查詢,域名服務器支持遞歸查詢。
從圖18可以看出,若域名服務器不支持遞歸請求,而單一的依靠客戶端做迭代查詢,將大大增加請求包和應答包的數量,且應答的質量也大大下降。所以應儘量選取支持遞歸服務的域名服務器,才能達到高效、高質量的要求。
3 結束語
本文通過對DNS系統及協議的分析,設計並實現了一種高效的DNS信息備份及恢復系統。通過結合被動捕獲DNS數據包和主動請求兩種方式,並利用異步請求模式可以高效得到大量DNS解析信息。同時,本文設計的基於請求隊列管理的發送速率控制方法可有效地實現接收速率和發送速率的匹配,使整個系統更加高效、穩定。
目前該系統可以在10 h內解析出和3 358 427個域名相關的DNS信息,包括4 827 349個A、NS、MX記錄,823 512個SOA記錄。這些DNS信息樣例,有代表性地體現了現行DNS系統和網絡中常見的DNS類型及其相關性。此係統的高效性已可滿足爲DNS應急備份系統提供數據源和更新源的要求。此DNS信息獲取系統已成功地運行在相關課題中,其採集到的第一批數據已作爲DNS系統分佈研究的統計分析數據。並將這些大量的DNS信息重新組建,恢復成與BIND兼容的ZONE文件形式,通過配置好的BIND,響應客戶端的DNS請求。基本上完成了DNS應急備份系統的功能。
除此之外,由本系統獲得的DNS數據還可用於其他項目,如針對基於Netflow的大規模網絡異常事件檢測、骨幹網監測、事件自動報告等系統,對網絡的安全運行具有重大的意義。
參考文獻:
[1]MOCKAPETRIS P. RFC 1034, Domain names-concepts and facili-tiess[S]. 1987.
[2]MOCKAPETRIS P. RFC 1035, Domain-implementation and specification[S]. 1987.
[3]BROWNLEE N, CLAFFY K C, NEMETH E. DNS measurements at a root server [C]//Proc of IEEE Global Telecommunications Conference. 2001:1672-1676.
[4]王垚,胡銘曾,李斌,等.域名系統安全研究綜述[J].通信學報. 2007, 28(9):91-103.
[5]OpenNIC [EB/OL]. http://www.opennicproject.org/.
[6]NEW.NET [EB/OL]. http://www.new.net/.
[7]NAME.SPACE. [EB/OL]. http://name-space.com/.
[8]陳剛,呂緒康,王宗敏. CERNET省域網後備域名系統的設計與實現[J]. 通信學報, 2006, 27(z1):140-142.
[9]ALBITZ P, LIU C. DNS and BIND [M]. 4th ed. Canberra: OReilly Associates Inc, 2001.
[10]WEIMER F. Passive DNS replication[C]// Proc of the 17th Annual FIRST Conference. 2005:1-13.
[11]BONANNO T, KIM H J, PARK J.Design and implementation of recursive DNS server [C]//Proc of IEEE ICACT. 2006:641-644.
[12]劉文濤. 網絡安全開發包詳解[M].北京:電子工業出版社, 2005.
[13]MATTHEW N, STONES R. Linux程序設計[M].北京:人民郵電出版社, 2007.
[14]CORMEN T H, LEISERSON C E, RIVEST R L, et al.Introduction to algorithms [M]. 2nd ed. Cambridge: The MIT Press, 2001.
[15]MySQL 5.1 reference manual[EB/OL]. (2009). http://dev.mysql.com/doc/refman/5.1/en/.