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