為什么訪問網(wǎng)站會(huì)失敗?為什么我發(fā)送電子郵件失敗?DNS幾乎是所有Internet服務(wù)的源泉，通常是造成此類問題的重要原因。
數(shù)據(jù)包丟失或防火墻配置不正確會(huì)影響多種協(xié)議。但是，DNS作為基本協(xié)議最容易受到數(shù)據(jù)包丟失和防火墻配置錯(cuò)誤的影響。知道這些影響因素可以幫助故障排除，以便可以更快地解決可能出現(xiàn)的任何問題。
DNS的功能
域名服務(wù)(DNS)的主要是將域名和IP地址進(jìn)行映射。由于提供了全球分布式目錄服務(wù)，因此，自1985年以來，域名系統(tǒng)一直是Internet功能的重要組成部分。
丟包問題
DNS從設(shè)計(jì)上說是一種易受攻擊的協(xié)議。在發(fā)送電子郵件，訪問網(wǎng)站之前，必須先通過DNS將域名解析為IP地址。使用相應(yīng)的IP地址，各種協(xié)議可以建立到相應(yīng)服務(wù)器的連接。但是，如果DNS域名解析出現(xiàn)丟包，則其他所有進(jìn)程也會(huì)受到影響。因此，在許多情況下，DNS都是導(dǎo)致網(wǎng)絡(luò)錯(cuò)誤的原因。DNS主要使用UDP作為其傳輸協(xié)議，是非面向連接的協(xié)議。
即使丟失一個(gè)數(shù)據(jù)包也會(huì)導(dǎo)致大量延遲。在上面顯示的示例中，客戶端192.168.2.120在五秒鐘的延遲后才向DNS服務(wù)器發(fā)送新請(qǐng)求。
如果與DNS服務(wù)器之間的連接在一定程度上受到干擾并且無法修復(fù)，請(qǐng)檢查通過TCP的DNS請(qǐng)求是否可以替代。在圖1中丟失的數(shù)據(jù)包已經(jīng)導(dǎo)致五秒鐘的延遲的情況下，圖2中的DNS請(qǐng)求在846ms內(nèi)處理了20%的丟包。
基于TCP的DNS
DNS主要使用UDP作為傳輸協(xié)議。但是，DNS從一開始就被設(shè)計(jì)為能夠同時(shí)使用UDP和TCP。僅當(dāng)DNS無法通過UDP通信時(shí)才使用TCP。
通常，當(dāng)數(shù)據(jù)包大小超過單個(gè)UDP數(shù)據(jù)包的最大長(zhǎng)度512字節(jié)時(shí)。DNS將使用TCP協(xié)議進(jìn)行傳輸。
如果數(shù)據(jù)包大小超過512字節(jié)，則設(shè)置"TC"位(截?cái)?，以通知客戶端消息長(zhǎng)度已超過最大允許大小。在這種情況下，客戶端必須通過TCP重新傳輸請(qǐng)求。
但是，如果TCP被阻止，則客戶端請(qǐng)求必須通過UDP應(yīng)答。這導(dǎo)致數(shù)據(jù)包被分段或丟棄。這會(huì)導(dǎo)致DNS解析速度變慢或域名無法解析。
為什么限制512字節(jié)
512字節(jié)UDP有效負(fù)載的大小取決于IPv4。IPv4標(biāo)準(zhǔn)指定每個(gè)網(wǎng)絡(luò)用戶都必須能夠處理576字節(jié)或更小的字節(jié)的數(shù)據(jù)包。如果減去控制數(shù)據(jù)(標(biāo)題)，則將保留純512字節(jié)有效負(fù)載。
認(rèn)識(shí)到此限制是一個(gè)問題，因此在DNS擴(kuò)展機(jī)制(EDNS)中，最大大小增加到4096字節(jié)。當(dāng)前的DNS服務(wù)器包含EDNS實(shí)現(xiàn)，因此能夠響應(yīng)查詢。
盡管EDNS自1999年以來一直存在，但并非所有網(wǎng)絡(luò)組件都能保證平穩(wěn)運(yùn)行。防火墻是錯(cuò)誤的根源，出于各種原因，可以丟棄總計(jì)超過576字節(jié)的DNS-UDP數(shù)據(jù)包。此行為可能不會(huì)導(dǎo)致任何直接可見的問題，但是必須確保所有網(wǎng)絡(luò)設(shè)備都支持大型DNS數(shù)據(jù)包。如果網(wǎng)絡(luò)環(huán)境不完全支持大型DNS消息，則可能導(dǎo)致DNS數(shù)據(jù)包被分段和/或部分丟棄。對(duì)于最終用戶，這與通過TCP阻止DNS數(shù)據(jù)包具有相同的效果。DNS解析無法響應(yīng)或需要很長(zhǎng)時(shí)間。
使用虹科IOTA分析DNS
通過討論DNS協(xié)議和一些最常見的DNS問題，現(xiàn)在可以解決這些問題。如何以一種簡(jiǎn)單的方式來跟蹤所有這些?這就是虹科IOTA的用處。IOTA是一個(gè)完整而安全的網(wǎng)絡(luò)分析和故障排除解決方案。通過將原始數(shù)據(jù)包數(shù)據(jù)捕獲到磁盤并提取元數(shù)據(jù)以在儀表板中使用，IOTA可以快速分析網(wǎng)絡(luò)上發(fā)生的事情，而不會(huì)丟失任何細(xì)節(jié)。有許多可定制的儀表板可用來幫助監(jiān)視基本性能指標(biāo)，重傳，數(shù)據(jù)包丟失，延遲，吞吐量，可用性，連接性等。
使用虹科IOTA查找DNS問題
DNS儀表板為您提供了針對(duì)您選擇時(shí)間范圍內(nèi)DNS流量的幾種視圖，以查看可用流量。第一部分顯示DNS流量。餅圖顯示使用中的頂級(jí)DNS服務(wù)器以及查詢最多的服務(wù)器及其各自的帶寬。
"底部"部分顯示了所有DNS查詢，這些查詢的客戶端和服務(wù)器IP地址，包括在流量中看到的DNS REPLY代碼，事件ID的日期/時(shí)間。在"詳細(xì)信息"部分下，您可以查看DNS請(qǐng)求總數(shù)和正在使用的DNS查詢。
IOTA的DNS儀表盤
如果沒有IOTA，1TB捕獲磁盤和儀表板，對(duì)這些問題進(jìn)行故障排除將花費(fèi)很時(shí)間，甚至無法完成。想象一下，使用Wireshark挖掘500GB的跟蹤文件，以及每次應(yīng)用過濾器時(shí)的加載時(shí)間。使用IOTA，儀表板可以立即概述DNS流量的狀況。例如，在以下DNS儀表板的屏幕截圖中，清楚地顯示了Server Fail DNS REPLY，以及與此通信相關(guān)聯(lián)的客戶端和服務(wù)器。
如果您想縮小搜索范圍，可以通過選擇ServFail錯(cuò)誤旁邊的“過濾”放大鏡進(jìn)行篩選。這將使用過濾器來查找所有這些特定錯(cuò)誤。 通過應(yīng)用此過濾器，IOTA可以深入了解特定服務(wù)器的DNS服務(wù)器響應(yīng)和元數(shù)據(jù)。 您可以在正在進(jìn)行DNS查詢的IP Source(IP源)下看到客戶端，而在正在接收和響應(yīng)DNS查詢的Server(服務(wù)器)下可以看到IP Destination(IP目的地)。 您可以在下面看到，IOTA已識(shí)別出從客戶端192.168*請(qǐng)求的最近30分鐘內(nèi)發(fā)生的DNS返回代碼。
DNS延遲時(shí)間
對(duì)于這一點(diǎn)，我們轉(zhuǎn)到儀表盤服務(wù)器延遲。 通過使用Goto >>，我們?cè)贒NS控制臺(tái)中設(shè)置過濾器，并在Server Latency Dashboard上顯示。
如下圖所示，顯示了相關(guān)的延遲(以毫秒為單位)。最近30分鐘的最大應(yīng)用程序延遲為163.41ms。 我可以進(jìn)一步看到較高延遲的DNS的確切時(shí)間。
安全訪問和遠(yuǎn)程分析
借助集成的TAP和內(nèi)部存儲(chǔ)功能，IOTA可以部署在網(wǎng)絡(luò)中的任何關(guān)鍵捕獲點(diǎn)，安全地提供對(duì)網(wǎng)絡(luò)的全面可見性。被監(jiān)視的網(wǎng)絡(luò)與管理界面隔離開，以避免通過設(shè)備注入MITM攻擊的任何風(fēng)險(xiǎn)。
IOTA通過HTTPS進(jìn)行全面管理，并具有內(nèi)置VPN，這意味著該設(shè)備可以部署在任何地方，并且可以從您的辦公桌后面輕松訪問。
