zoukankan      html  css  js  c++  java
  • DNS 壓力測試

    DNS 壓力測試
    去年,提供全世界 DNS 解析之根伺服器 (Root Server) 遭受分散式拒?服務攻擊(DDOS, Distribution Denial of Service),大量的查詢封包幾乎拖跨一半以上根伺服器或使用反應變慢。如果根伺服器失去作用,則基本上整個 Internet 環境也會受到莫大的影響。推衍這個觀點到一般企業或單位的 DNS 伺服器,多數人使用的版本及其承受的壓力為何呢…



    1前言
    DNS (Domain Name Service)為 Internet 基礎之一環,在全世界多數的網域名稱服務多使用 ISC BIND 及 Windwos DNS 以提供名稱查詢之服務,且多數的網路服務(如:郵件服務、網站..)皆與 DNS 習習相關,故 DNS 效能的好壞關係到整個服務的效率。去年,提供全世界 DNS 解析之根伺服器 (Root Server) 遭受分散式拒?服務攻擊(DDOS, Distribution Denial of Service),大量的查詢封包幾乎拖跨一半左右根伺服器或使用反應變慢。如果根伺服器失去作用,則基本上整個 Internet 環境也會受到莫大的影響。推衍這個觀點到一般企業或單位的 DNS 伺服器,多數人使用的版本及其承受的壓力為何?本研究即是在探討此一性質之問題,到底一般我們所使用的 DNS 伺服器其承受的查詢臨界為何?及對系統會有什麼樣的影響。

    關鍵字:DNS、根伺服器,分散式拒絕服務攻擊

    2. 簡介
    此一研究主要在於測試多數人使用的 DNS 版本,在同一機器上其承受的查詢壓力為何?我們以 ISC BIND [1]為測試對象。其中因為 ISC BIND 有許多不同的版本,我們僅選擇其中幾個代表性版本,在相同的機器及網路架構下,進行壓力測試。

    3.說明

    3.1 測試方法
    由於 ISC BIND 版本眾多,且不同的版本使用人數亦不相同,故我們僅以數個不同版本為測試對象(版本編號請見圖例):
    * 版本:BIND 9 以上版本因其可使用多序架構 (multi-threads) 及加密模組( openssl ),故此一版本以上我們再細分其編譯條件。
    * 測試資料:取TWNIC所管理的網域名稱中 65535 筆資料,查詢其 www 主機。
    * DNS組態:以 Cache-Only (不管理任何的網域名稱,僅負責查詢)的 DNS 設定方式,並測試兩種查詢方式:
    ‧遞迴查詢:幫您問到最後的結果,即IP位址。
    ‧非遞迴查詢:只回應您去那問這個結果。
    * 網路:為環境單純化,於區域網路內測試。
    * 主機:AMD 1.5G CPU 及 256 MB 記憶體,以 Linux (RedHat 9.0) 為平台,並僅開啟 DNS 及 Telnet 服務。並於固定時間,每五分鐘讓 DNS 產生查詢之記錄檔,而後畫成 DNS 流量圖(可能佔去少量的系統資源)。
    * 方法:以分散式共同向 DNS 伺服器大量送出查詢封包,平均每秒送出約十萬個封包至 DNS 伺服器[2][3]。

    3.3 遞迴與非遞迴查詢
    圖 1 DNS 的查詢方式

     圖上的 DNS Server 即是我們的測試機器,DNS Server 設為遞迴查詢[4][5]時,其會幫 Client 找到最後的結果。若為非遞迴查詢,則僅會告知 Client 要去 Root Server 問下一站的位置,而 Root Server 的列表則直接存於 DNS Server 上。基本上由此可知,遞迴查詢對 DNS Server 的負擔較大,因為其要根據授權關係( Delegation) 往下找到最後的結果。非遞迴查詢(如右列),則是根據自有的資料告知其去那查下一站。

      我們的統計基準,僅以DNS Server收到的 Cleint 端查詢及回應 Client 端查詢為基準,至於遞迴了幾次並不在我們的統計之列,原因在於 BIND 8 及 BIND 9 的統計資料格式不一致,且無法完全顥示遞迴次數所致。
    圖 2測試架構圖

    3.4 DNS 之統計資料
    由於 BIND 8.X 與 BIND 9.X 之版本之統計資料之格式有很大的不同,BIND 8.X 版本之DNS 運作相關欄位眾多(共二十九項),我們僅取其兩項:

    表格 1 BIND 8.X 版本統計欄位

     上表為 BIND 8.X 版本之統計欄位,我們所要取得的欄位是 DNS 收到的查詢量 (RQ) 及送出的回應量 (Sans) ,意指收到來自 Client 端的查詢與回應數,其差額即查詢失敗數。

    表格 2 BIND 9.X 版本統計欄位

     上表為 BIND 9.X 版本之統計欄位資訊,我們需要的數值為成功查詢數 (success) 及失敗數,兩者之差額即回應量。
    依上述不同版本之欄位意義,我們可以取得一共同之統計標準,依此標準,即可計算固定時間內 DNS 所處理的查詢狀況。而我們則以每五分鐘取值,並以每三十分鐘為平均值,畫於圖表上。同時我們亦偵測系統所收到的封包數及CPU負載(我們將其x100 倍,較容易觀察其變化),以了解其對系統的影響。此處我們不列常見的記憶體則是因為其皆臨介20%的使用率,其原因則是 DNS 的快取功能及我們測試固定資料內容之關係。

    3.5 測試結果
    Server 端的監測我們使用 RRDTOOL (Round Robin Database TOOL)[6] 這套軟體來產生報表,其效果類似常用之 MRTG[7] (Multi Router Traffic Grapher),使用 RRDTOOL 之意義在於同一時間上表現出更多的系統數值變化。


    遞迴查詢

     因遞迴查詢兩版本數值差異較大,流量圖置於一起時,數值小的流量不容易顯現出來,故遞迴查詢部份,我們依其版本將其拆開分別表示出流量圖。

     以下之版本列表我們乃依版本號碼取數個版本,BIND 9.X 的部份再細分其為 threads 版本或非threads 版本,以觀察其差異。BIND 8.X 則無此項差異。下圖並未列出 9.1.0 版本流量,但於表中我們將其列上,其數字差異之大亦讓我們意外。至於 9.0.0 具代表性的版本未做則是因為 9.0.0 版本無法產生查詢記錄欄位,故我們亦未列上。

      遞迴查詢會問到權威主機(即實際管轄此一網域名稱之主機),故可以預見其回應時間會較慢,但與非遞迴查詢究竟有多少的差異,亦是我們觀察的一大重點。

    圖 3 BIND 9.X 遞迴查詢量

    圖 4 BIND 8.X 遞迴查詢量

    『圖三』及『圖四』為 BIND DNS 在我們本次測試中所產生的流量圖,而圖表上紅色區磈( )依序號應如下版本,數據如下:

    表格 3 BIND 遞迴查詢量

    圖 5 BIND 遞迴查詢量,最大/平均/最小 圖

    表格 4 BIND 遞迴回應量

    圖 6 BIND 每秒遞迴查詢量,最大/平均/最小 圖

    非遞迴查詢

    圖 7 BIND非遞迴查詢量

    表格 5 BIND 非遞迴查詢/回應量

    圖 8 BIND 非遞迴,最大/平均/最小 圖

    3.5 狀況探討
    * 不考慮安全問題下,那一版本最好?
    遞迴查詢主機以 9.2.2 為最好,雖然 9.2.0 有最大值突出的表現,但以平均值及 CPU 負載來看,9.2.2 版本應還有成長空間,因為其受限於測試環境 Ethernet 100MB 的容量上限。一個 DNS 封包平均約 80~100 個 bytes,但遞迴查詢時,查詢 www.kimo.com.tw 其層層查詢在無快取的狀況下至少會產生十個封包。造成其無法更上一層樓的原因。以其 CPU 負載估算,應還約有一半的成長空間[2],
    ‧非遞迴查詢版本若單純從流量來看,許多版本都有平均值接近6000 的表現,查詢加上回應亦接近 12000 個封包,也是接近 Ethernet 的上限。但顯然的,9.2.2 在 CPU 負載部份尚未滿載,亦是最佳的表現。
    ‧不論那一個版本,就台灣的 DNS Root Server (.tw) 而言,皆還有餘力,如下圖,就歷史記錄而言,.tw Server 的每秒瞬間總合統量,沒有超過 2000 次,在我們測試的版本上,大多皆能勝任,故一般使用者在選擇版本時大柢上不需要太著重在版本對於資料的處理能力(除 9.1.0 外,原因不詳)

    圖 9 .tw Root Server 流量

    * 系統考量
    ‧從 CPU 負載,及 UDP 封包的進出量來看,顯然 9.X 版本皆優於 8.X。而若使用 threads 的架構,在我們單CPU 的機器上並不能發揮作用,反倒使用效能皆稍稍降低。
    * 穩定度部份
    ‧從查詢/回應面來看,9.X 版本的表現亦穩定許多,在系統或網路滿載的情況下,在流量上較不會產生劇烈變化,標準差亦來的少許多。


    4 結論
    此一壓力測試我們並未將 Windows DNS 列入是最不足之處,原因在於 Windows DNS 我們並無法取得其流量資訊,而從其網站上得知其宣稱查詢處理可至 9500 次/每秒[6]。

      而我們亦未測試其他較早期BIND版本,一則因為其巳少見於網路中,二則是因為在我們的系統編釋時會發生許多錯誤。而綜合現在較多人使用的版本,以 BIND 8 後期的版本及 BIND 9 代表性的版本來看,BIND 9 確實是一套很成熟的 DNS 系統,在我們的測試過程中,其完全沒有當機的情況發生。

      不論使用那一個版本,一般而言大概皆能符合您的需求,但 DNS 安全之問題不可不慎,我們測試的數個版本,亦皆是有安全漏洞之問題。最好的版本是 9.2.2,目前尚是一個沒有安全漏洞的版本,若情況允許,會建議您更改至此一版本,讓您的 DNS Server 既安全又穩定!

    5. 參考文獻

    ISC 官方網站 Web Page http://www.isc.org

    ISC BIND 維護廠商網頁, http://www.nominum.com/content/documents/CNS%20Performance_WP.pdf

    效能試測方法 Web Page http://www.caida.org/outreach/presentations/rssac-0112/rssac-200112.pdf

    Rrdtool 官方網站,用於繪制系統監測圖 Web Page http://www.rrdtool.org

    Mrtg 官方網站, http://www.mrtg.org

    DNS 流量資訊取得方法可參考 TWNIC DNS 教材 http://rs.twnic.net.tw/DNS92/download/92DN-2.doc

    Rrdtool 中文資料 http://phorum.study-area.org/viewtopic.php?t=18496

    遞迴與非遞迴之差異http://rs.twnic.net.tw/DNS92/download/92DN-1.ppt

    微軟之 DNS 效率說明網頁, http://www.eu.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/standard/sag_DNS_imp_UsingSystemMonitor.asp?frame=true


  • 相关阅读:
    Java IO(三)——字节流
    Java IO(二)——RandomAccessFile
    【sqli-labs】 less50 GET -Error based -Order By Clause -numeric -Stacked injection(GET型基于错误的整型Order By从句堆叠注入)
    【sqli-labs】 less49 GET -Error based -String -Blind -Order By Clause(GET型基于盲注的字符型Order By从句注入)
    【sqli-labs】 less48 GET -Error based -Blind -Numeric -Order By Clause(GET型基于盲注的整型Order By从句注入)
    【sqli-labs】 less47 GET -Error based -String -Order By Clause(GET型基于错误的字符型Order By从句注入)
    【sqli-labs】 less46 GET -Error based -Numeric -Order By Clause(GET型基于错误的数字型Order By从句注入)
    【sqli-labs】 less45 POST -Error based -String -Stacked Blind(POST型基于盲注的堆叠字符型注入)
    【sqli-labs】 less44 POST -Error based -String -Stacked Blind(POST型基于盲注的堆叠字符型注入)
    【sqli-labs】 less43 POST -Error based -String -Stacked with tiwst(POST型基于错误的堆叠变形字符型注入)
  • 原文地址:https://www.cnblogs.com/hq2008/p/1128755.html
Copyright © 2011-2022 走看看