文章目錄
-
- 故事的開始
- DNS的功能
- 丢包問題
- 基于TCP的DNS
- 為什麼限制512位元組
- 使用虹科IOTA分析DNS
- 使用虹科IOTA查找DNS問題
- IOTA的DNS儀表盤
- DNS延遲時間
- 安全通路和遠端分析
- 關注我們
為什麼通路網站會失敗？為什麼我發送電子郵件失敗？DNS幾乎是所有Internet服務的源泉，通常是造成此類問題的重要原因。
資料包丢失或防火牆配置不正确會影響多種協定。但是，DNS作為基本協定最容易受到資料包丢失和防火牆配置錯誤的影響。知道這些影響因素可以幫助故障排除，以便可以更快地解決可能出現的任何問題。
域名服務（DNS）的主要是将域名和IP位址進行映射。由于提供了全球分布式目錄服務，是以，自1985年以來，域名系統一直是Internet功能的重要組成部分。
DNS從設計上說是一種易受攻擊的協定。在發送電子郵件，通路網站之前，必須先通過DNS将域名解析為IP位址。使用相應的IP位址，各種協定可以建立到相應伺服器的連接配接。但是，如果DNS域名解析出現丢包，則其他所有程序也會受到影響。是以，在許多情況下，DNS都是導緻網絡錯誤的原因。DNS主要使用UDP作為其傳輸協定，是非面向連接配接的協定。
即使丢失一個資料包也會導緻大量延遲。在上面顯示的示例中，用戶端192.168.2.120在五秒鐘的延遲後才向DNS伺服器發送新請求。
如果與DNS伺服器之間的連接配接在一定程度上受到幹擾并且無法修複，請檢查通過TCP的DNS請求是否可以替代。在圖1中丢失的資料包已經導緻五秒鐘的延遲的情況下，圖2中的DNS請求在846ms内處理了20％的丢包。
DNS主要使用UDP作為傳輸協定。但是，DNS從一開始就被設計為能夠同時使用UDP和TCP。僅當DNS無法通過UDP通信時才使用TCP。
通常，當資料包大小超過單個UDP資料包的最大長度512位元組時。DNS将使用TCP協定進行傳輸。
如果資料包大小超過512位元組，則設定"TC"位（截斷），以通知用戶端消息長度已超過最大允許大小。在這種情況下，用戶端必須通過TCP重新傳輸請求。
但是，如果TCP被阻止，則用戶端請求必須通過UDP應答。這導緻資料包被分段或丢棄。這會導緻DNS解析速度變慢或域名無法解析。
512位元組UDP有效負載的大小取決于IPv4。IPv4标準指定每個網絡使用者都必須能夠處理576位元組或更小的位元組的資料包。如果減去控制資料（标題），則将保留純512位元組有效負載。
認識到此限制是一個問題，是以在DNS擴充機制（EDNS）中，最大大小增加到4096位元組。目前的DNS伺服器包含EDNS實作，是以能夠響應查詢。
盡管EDNS自1999年以來一直存在，但并非所有網絡元件都能保證平穩運作。防火牆是錯誤的根源，出于各種原因，可以丢棄總計超過576位元組的DNS-UDP資料包。此行為可能不會導緻任何直接可見的問題，但是必須確定所有網絡裝置都支援大型DNS資料包。如果網絡環境不完全支援大型DNS消息，則可能導緻DNS資料包被分段和/或部分丢棄。對于最終使用者，這與通過TCP阻止DNS資料包具有相同的效果。DNS解析無法響應或需要很長時間。
通過讨論DNS協定和一些最常見的DNS問題，現在可以解決這些問題。如何以一種簡單的方式來跟蹤所有這些？這就是虹科IOTA的用處。IOTA是一個完整而安全的網絡分析和故障排除解決方案。通過将原始資料包資料捕獲到磁盤并提取中繼資料以在儀表闆中使用，IOTA可以快速分析網絡上發生的事情，而不會丢失任何細節。有許多可定制的儀表闆可用來幫助監視基本性能名額，重傳，資料包丢失，延遲，吞吐量，可用性，連接配接性等。
DNS儀表闆為您提供了針對您選擇時間範圍内DNS流量的幾種視圖，以檢視可用流量。第一部分顯示DNS流量。餅圖顯示使用中的頂級DNS伺服器以及查詢最多的伺服器及其各自的帶寬。
"底部"部分顯示了所有DNS查詢，這些查詢的用戶端和伺服器IP位址，包括在流量中看到的DNS REPLY代碼，事件ID的日期/時間。在"詳細資訊"部分下，您可以檢視DNS請求總數和正在使用的DNS查詢。
如果沒有IOTA，1TB捕獲磁盤和儀表闆，對這些問題進行故障排除将花費很時間，甚至無法完成。想象一下，使用Wireshark挖掘500GB的跟蹤檔案，以及每次應用過濾器時的加載時間。使用IOTA，儀表闆可以立即概述DNS流量的狀況。例如，在以下DNS儀表闆的螢幕截圖中，清楚地顯示了Server Fail DNS REPLY，以及與此通信相關聯的用戶端和伺服器。
如果您想縮小搜尋範圍，可以通過選擇ServFail錯誤旁邊的“過濾”放大鏡進行篩選。這将使用過濾器來查找所有這些特定錯誤。 通過應用此過濾器，IOTA可以深入了解特定伺服器的DNS伺服器響應和中繼資料。 您可以在正在進行DNS查詢的IP Source（IP源）下看到用戶端，而在正在接收和響應DNS查詢的Server（伺服器）下可以看到IP Destination（IP目的地）。 您可以在下面看到，IOTA已識别出從用戶端192.168*請求的最近30分鐘内發生的DNS傳回代碼。
對于這一點，我們轉到儀表盤伺服器延遲。 通過使用Goto >>，我們在DNS控制台中設定過濾器，并在Server Latency Dashboard上顯示。
如下圖所示，顯示了相關的延遲（以毫秒為機關）。最近30分鐘的最大應用程式延遲為163.41ms。 我可以進一步看到較高延遲的DNS的确切時間。
借助內建的TAP和内部存儲功能，IOTA可以部署在網絡中的任何關鍵捕獲點，安全地提供對網絡的全面可見性。被監視的網絡與管理界面隔離開，以避免通過裝置注入MITM攻擊的任何風險。
IOTA通過HTTPS進行全面管理，并具有内置VPN，這意味着該裝置可以部署在任何地方，并且可以從您的辦公桌後面輕松通路。