緯育 2026-0314.2

出自頂極製作所
於 2026年3月17日 (二) 02:57 由 Kuyohong留言 | 貢獻 所做的修訂 →‎進階課程預告與資安提示

PING

本次課程以 Ping 與 ICMP 進行網路診斷為主軸,結合 Wireshark 實作從 frame、Ethernet、IPv4 到 ICMP 與 data 的逐層解析,並延伸觀察 ARP 在區域網路中的角色與觸發時機。內容涵蓋封包生成與回覆流程、回應時間(ms)與 TTL 的意義與推論、Ethernet Frame、IP Header、ICMP Header 的欄位細節與作用、不同作業系統(Windows、macOS、Linux)在 Ping 指令與行為上的差異、Wireshark 的介面與分析功能(時間戳、介面識別、顏色規則、標記/忽略、Bytes/ASCII 顯示、Time Shift),以及使用 ARP 查表與清表、Windows 防火牆設定以啟用 ICMPv4 回覆的實務流程。

課程安排完整練習:查詢 Gateway、設定指令、啟動 Wireshark 擷取、執行 Ping(示例四次往返共八個封包)、停止並分析,並在 LAN 情境中以清除 ARP 快取後的 Ping 驗證兩則 ARP(廣播與回覆)的預期行為,確保學員將實務診斷與協定層細節連結。

Ping 與 ICMP 的基礎概念與用途

  • Ping 作為基本診斷工具
    • 使用 ICMP Echo Request(Type=8)與 Echo Reply(Type=0)進行「我問你、你回我」的互動模型。
    • 典型診斷目標:自身 IP、Gateway、他人/服務主機。不同目標代表不同層面的檢查(本機堆疊、到閘道連通性、端到端可達性)。
  • ICMP 類型與回應
    • Type/Code 可辨識回覆與錯誤;TTL 歸零時路由器可能回傳 ICMP Destination Unreachable 等訊息。
  • 回應時間與 TTL 的意義
    • ms 延遲由作業系統記錄(非封包欄位)。TTL 每經過一個路由器扣 1,至 0 丟棄;可用回覆 TTL 推論跳數、作業系統預設 TTL與拓樸鄰近性。
    • 以延遲與 TTL 共同推論壅塞、線路/路由問題。
  • 作業系統差異
    • Windows 的 Ping 參數以「/?」查詢,常見 -t、-a;預設執行固定次數。macOS/Linux 預設持續執行,需 Ctrl+C 停止。不同系統的 ICMP Data 內容可能不同(如 Windows 常見「ABCDEFG」)。

Wireshark 基本視圖、顏色規則與協定堆疊

  • 詳細視圖與 Bytes 對應:點選 ICMP、IP、Ethernet、frame 層可在右側 Hex/Bytes 對應框選各層範圍,協助核對欄位與長度(如 Total Length)。
  • frame 層欄位與時間顯示:Interface ID、Encapsulation Type、Arrival Time/UTC/Epoch、捕獲序號與大小;可使用 Time Shift 調整顯示位移(一般分析少用)。
  • 封包標記與忽略:Marked/Ignored 便於聚焦分析。
  • Coloring Rules:預設顏色代表社群慣用語義(如 TCP RST、ICMP 等),建議不修改;可在 View > Coloring Rules 檢視與新增自訂規則。
  • 協定堆疊:Ethernet > IP > ICMP > Data;ASCII 顯示更清楚呈現載荷。

乙太網路(Ethernet)Frame 結構與 MAC 辨識

  • Ethernet II(DIX 2.0):preamble、SFD、目的/來源 MAC(6 bytes)、Type(0x0800 表 IPv4)、FCS。IEEE 802.3 將 Type 改為 Length,實務多採 Ethernet II。
  • Wireshark 可顯示 MAC 前 3 碼(OUI)對應廠商,以快速辨識設備類型。

IPv4 Header 詳解與驗證

  • Version=4;IHL 常見 20 bytes(無 Options)。
  • DS(DiffServ)多由中間設備設定,端主機通常為 0。
  • Total Length:包含 Header 與 Data;可於 Bytes 視圖核對實際長度(示例 60 bytes)。
  • Identification:封包生成順序遞增;分片時所有分片共享相同 Identification。
  • Flags/Fragment Offset:指示分片狀態與位移。
  • TTL:每過路由器扣 1;回覆封包若 TTL 未扣減(例如 255),可推論對端在同一子網/鄰近位置。
  • Protocol:ICMP=1。
  • Header Checksum:可在偏好設定逐協定啟用驗證;過度啟用可能影響效能。

ICMP Header 與 Data 內容

  • Type/Code:Echo Request=8/0,Echo Reply=0。
  • Checksum、Identifier、Sequence Number:用於配對 request/reply 與統計次序。
  • Data:各平台填入內容可能不同;多數設備會原樣回覆請求的 data。可據 ASCII 顯示比對確認往返關聯與設備處理策略。

ARP 在區域網路中的角色與觸發

  • 位址與網段判定:主機以自身子網遮罩計算並比較目標是否同網段。
    • 同網段:需取得目標 MAC;未知時發送 ARP Request(EtherType=0x0806,Operation=1),收到 ARP Reply(Operation=2)後以該 MAC 封裝傳送。
    • 不同網段:封包送至 Gateway;可能詢問/使用 Gateway 的 MAC。
  • ARP 欄位:Hardware Type(Ethernet)、Protocol Type(IPv4)、HLEN=6、PLEN=4、Sender/Target 硬體/協定位址、Operation。
  • 觸發條件:同網段且未知對方 MAC;若 ARP 快取已存在則不再發送。

Windows 實務操作:ARP/ICMP與防火牆

  • ARP 快取:arp -a 檢視;以系統管理員執行 arp -d * 清空以強制觀察 ARP。
  • Ping 與擷取預期:清表後 Ping 預期看到兩則 ARP(廣播與回覆);即便 Windows 某些版本不回覆 ICMP Echo,ARP 互動仍可見。
  • 防火牆策略(被 Ping 端):首選啟用 ICMPv4 入站規則(進階防火牆 → 入站規則 → 允許 ICMPv4 Echo),不建議全面關閉防火牆;測試後恢復原設定。
  • 介面與組態:私人/公用網路為不同組態檔;版本差異可能影響導覽位置。

封包流程、數量預期與多介面捕獲

  • 封包往返:本機發送 Echo Request,對端回 Echo Reply;本機計算往返延遲(例 3–4 ms)。
  • 封包數量預期:執行 4 次 Ping,理論擷取到 8 個封包(4 出、4 回);若少於預期需調查遺失或過濾原因。
  • 多介面捕獲:在 Capture 設定按住 Ctrl 可同時選取多張網卡,觀察 Interface ID 與來源差異;無法在擷取頁面直接加選。
  • 過濾與視野管理:Display Filter 精準篩選,必要時以 Ignored 暫時隱藏不相干封包。

實務診斷與應對

  • 外包/客服常以簡單 Ping 判定並更換設備;若能提供更深入路由證據,較可能獲得專業處理。
  • 建立心中預期與實測比對:觀察 ms、TTL、封包數量與內容,推論壅塞、速度、路由行為、封包遺失,避免被過度簡化結論誤導。

2026-0316-06.png

網路封包過濾技巧

  • 過濾器的基本使用與常見問題
    • 初學者常以 ip.addr 過濾特定 IP(如 ip.addr == 192.168.2.9)。
    • 此法僅能篩選具 IP 層的封包(如 ICMP),會遺漏不含 IP 層的封包(如 ARP),因 ARP 本身沒有 IP 層結構,ip.addr 對其無效。
  • ARP 專用過濾方式
    • 可用 arp. 前綴的過濾器,針對發送者或目標 IP 過濾。
    • 因 ARP 請求與回應中發送者/目標角色互換,需兩條規則才能完整捕捉一次 ARP 交換,再加上 ICMP 的規則,合計三條,較為繁瑣。
  • 高效整合過濾策略
    • 分析 ping 涉及四種封包:ARP 請求(廣播)、ARP 回應(單播)、ICMP 請求(送出)、ICMP 回應(收到)。
    • 共同點:皆與本機的 MAC 位址相關。
    • 精簡條件式:eth.addr == [我的MAC位址] and (arp or icmp)。
    • eth.addr == [我的MAC位址] 確保來源或目的地 MAC 為本機。
    • (arp or icmp) 將結果限定為 ARP 與 ICMP,排除 HTTP、DNS 等無關流量。
    • 只需一條指令,即可清楚、完整捕捉 ping 相關封包。

ARP 協定運作詳解

  • ARP 請求(Request)流程
    • 觸發時機:主機需與同網段目標通信,僅知其 IP、未知其 MAC 時發起 ARP 請求。
    • 封包結構(Ethernet 層):
    • 目的位址:FF:FF:FF:FF:FF:FF(廣播),使同網段所有設備可接收。
    • 來源位址:發起主機 MAC。
    • 類型(Type):0x0806(ARP)。
    • 封包結構(ARP 層):
    • 硬體類型:Ethernet (1)。
    • 協定類型:0x0800(IPv4)。
    • 操作碼(Opcode):1(request)。
    • 發送者 MAC/IP:發起主機的 MAC 與 IP。
    • 目標 MAC 位址:未知,以 00:00:00:00:00:00 填入。
    • 目標 IP 位址:欲查詢的目標 IP。
    • 傳送方式:以廣播形式送至網段內所有設備。
  • ARP 回應(Reply)流程
    • 觸發時機:收到 ARP 請求的設備檢查目標 IP 是否為自身;匹配者才回應。
    • 封包結構(Ethernet 層):
    • 目的位址:原請求方 MAC(由請求封包取得)。
    • 來源位址:回應主機 MAC。
    • 封包結構(ARP 層):
    • 操作碼(Opcode):2(reply)。
    • 發送者 MAC/IP:回應主機之 MAC 與 IP。
    • 目標 MAC/IP:原請求方之 MAC 與 IP。
    • 傳送方式:以單播(unicast)直接送回請求方。
  • ARP 完成後的影響
    • 請求方收到 ARP 回應後取得目標 IP 對應之 MAC。
    • 後續封包(如 ICMP ping 請求)在 Ethernet 標頭填入該 MAC,完成通信。
    • 若 ARP 無回應,因未知目的 MAC,ICMP 封包無法送出。

網路問題判斷

  • 不同網段的行為
    • 目標位於不同網段時,主機不會對目標 IP 發起 ARP。
    • 取而代之,主機將封包送往預設閘道(Gateway),故抓包中不會看到針對目標 IP 的 ARP。
  • ARP 失敗的可能原因
    • 若送出 ARP 請求(封包 1)而無回應(封包 2),表示目標未回應。
    • 可能原因之一:發送方認為目標在同網段,但目標主機因網路設定錯誤,認定與發送方不同網段而不回應。

課後練習與課程預告

  • 課後練習
    • 四項練習以實際抓包驗證理論:
   1. ping 同網段但「不存在」的主機 IP(例:192.168.2.x)。
   2. ping 「不存在」且「不同網段」的主機 IP(例:192.168.222.222)。
   3. ping 主機自己的 IP(例:192.168.2.86)。
   4. ping 本機迴環位址 127.0.0.1。

2026-0316-07.png

網路連線測試與封包分析

  • Ping 同網段不存在的 IP
    • 行為: 對同一網段內不存在的 IP 執行 ping 時,作業系統會先檢查 ARP 快取是否有該 IP 對應的 MAC 位址。
    • 封包: 找不到 MAC 位址時,系統會發送 ARP 廣播請求,詢問「誰是 [目標IP]?請告訴 [來源IP]」。
    • 結果: 由於目標主機不存在,無任何設備回應 ARP 請求。Windows 10/11 預設會嘗試發送三次 ARP 請求,三次皆失敗後回報「目的地主機無法連線」(Destination host unreachable)。
    • 封包特徵: 在此情境下,Wireshark 會看到大量 ARP 廣播,而不會看到 ICMP (ping) 封包,因為在無法解析 MAC 位址階段就已失敗。
    • 系統差異: 舊版系統(如 Windows 7)可能只發送一次 ARP 即回報失敗,因此 ARP 封包數較少,顯示不同作業系統對 ARP 重試次數的實作差異。
  • Ping 不同網段不存在的 IP
    • 行為: 針對不在同一網段的 IP(外網 IP)執行 ping 時,作業系統會判定需透過預設閘道 (Gateway) 轉發。
    • 封包: 系統會將 ICMP 請求封包發送給閘道。乙太網路層的目標 MAC 為閘道的 MAC,而 IP 層的目標 IP 仍是實際想 ping 的外網 IP。
    • 結果: 封包送至閘道,但最終目標不存在,閘道無法送達,最終導致逾時。Windows 11 顯示「要求等候逾時」(Request timed out)。
    • 關鍵差異: 此過程不會嘗試對外網 IP 發送 ARP,因為通訊是透過閘道進行。需理解乙太網路層與 IP 層目的地可能不同:前者是閘道,後者是最終目標,這常被初學者混淆。
  • Ping 本機 IP 與 Loopback Address
    • 行為: ping 自己的 IP(如 192.168.2.86)或環回地址 (127.0.0.1) 時,皆屬本機內部作業。
    • 封包傳輸: 這些通訊不會經過實體網路卡 (NIC),而是在作業系統核心內部處理後直接回應。ping 自己的 IP 透過實體網卡配置的 IP 進行,ping 127.0.0.1 則透過作業系統的虛擬環回介面 (Loopback Interface)。
    • Wireshark 擷取問題: 若 Wireshark 僅監聽實體網路卡,將無法擷取任何封包,因為流量未通過該網卡。
    • 解決方案: 需在 Wireshark 選擇 Adapter for Loopback Capture 虛擬介面監聽。這是 Npcap 的功能(WinPcap 不支援),可捕捉發往本機的流量。但因來源與目的 IP 皆為本機,方向性較難直觀辨識。

VLAN 與交換器連接埠模式

  • 802.1Q 封包的出現
    • 情境: 在同學間互相 ping 的封包中,可能看到帶有 802.1Q VLAN 標籤,即使電腦自身未設定 VLAN。
    • 原因: 通常是因為電腦連接的交換器 (Switch) 連接埠設定為 Trunk Port 或 Hybrid Port。
    • 電腦處理: 一般個人電腦作業系統預設不識別 802.1Q 標籤,收到此類封包會直接丟棄。但 Wireshark 能識別並解讀標籤,因此可在 Wireshark 中看到 VLAN 資訊。
  • 交換器連接埠模式
    • Access Port: 連接終端設備(電腦、印表機)的普通乙太網路埠,處理不帶 VLAN 標籤的流量。
    • Trunk Port: 用於交換器之間傳輸多個 VLAN 的流量,封包經過時會加上 802.1Q VLAN 標籤以區分所屬 VLAN。
    • Hybrid Port: 混合模式,兼具 Access 與 Trunk 特性,可處理帶標籤與不帶標籤的封包,並依設定決定處理方式。若電腦連到設為 Hybrid 的埠,可能會收到帶 VLAN 標籤的封包。

2026-0317-01.png

DNS

聚焦DNS(Domain Name System/Service)在UDP上的運作,涵蓋DNS查詢流程、UDP與TCP比較、DNS封包與欄位(Header、Question、Answer)、TTL與快取行為,以及DNS在TCP 53於主從(MASTER/SLAVE)備援的用途;並透過WireShark與ping進行實作抓包與過濾。

講師以 www.wirehack.org 為例,說明網址相較IP的記憶性差異、瀏覽器載入頁面會觸發多筆DNS查詢的情境,以及為何即時性應用與DNS多採UDP以提升效率。後段進行實作:清快取、抓取DNS與ICMP封包、設定過濾與檢視欄位,並提示可能觀察到ARP。課程亦預告進階課程將展示DNS遞迴與權威查詢的更深入風暴,且資安課會示範利用DNS查詢類型進行攻防的案例。 重點知識點

DNS概念與用途

  • 網址與IP的對應
    • DNS將「有意義的名稱(網址)」映射為「沒有意義但實用的數字(IP位置)」,讓使用者以易記名稱上網,實際連線仍用IP。
    • 範例網址:水果大學 wirehack.org;講師以記憶對比說明「104251.6」等數字難以長期記憶。
  • DNS縮寫與稱呼
    • DNS可解作Domain Name System,亦有人稱Domain Name Service;講師表示稱呼並非重點。
  • DNS的運作層與埠號
    • DNS以UDP為主,目的埠為53(UDP 53);一般使用者查詢多為UDP。
    • DNS亦設計TCP 53確保資料完整性,典型用於兩台DNS伺服器之間的備援與資料同步(MASTER/SLAVE架構,SLAVE向MASTER取資料時用TCP 53)。
    • 實作情境中,若抓到兩台Windows Server做DNS備援,可見TCP 53風暴;本次課程重點在UDP 53。

DNS查詢流程與網路封裝

  • 基本查詢步驟與封包流向
    • 使用者在命令列執行ping某網址(例:wireshark.org),電腦辨識其為「網址」而非IP,需發送DNS查詢封包。
    • 查詢流程:主機以UDP送至目的Port 53的設定DNS伺服器(例如中華電信的DNS)。若本機無法直接到達,Layer2目的MAC設為Gateway,由具路由功能的Gateway轉往外網,最終抵達DNS伺服器。
    • DNS伺服器可能回應「知道」或「不知道」。不知道時可向其他DNS查詢(遞迴或轉送)。本課僅觀察用戶端至ISP DNS的風暴;進階課程將展示DNS之間的風暴。
    • 回覆抵達後由Gateway轉交給用戶端;用戶端獲得IP後,ping(ICMP)以該IP通訊,預期產生雙向各5個ICMP封包(「必須兩次等於十次」係指雙向回應的往返)。
  • 封裝層次
    • 以太網路(Ethernet)為最底層;其Data承載IP。
    • IP的Data承載UDP。
    • UDP的Data承載DNS。
    • 本課聚焦UDP與DNS層,Ethernet、IP已略過。

UDP機制、優缺點與與TCP的比較

  • UDP欄位與特性
    • UDP標頭簡單:來源Port、目的Port、Length(整體封包長度)、Checksum,以及Data。
    • 查詢時目的Port填53;來源Port為1024以上的隨機Port,各主機不同。
  • UDP缺點與資料完整性問題
    • 範例「HELLO」分成5個封包(H/E/L/L/O)。若其中一個子封包Checksum不通過被丟棄,上層應用不會知道遺失(Transport層丟棄未通知上層),收到可能變成「HELO」,導致壓縮檔解不開、圖片壞掉等。
    • 若需完整性,應用端需自行偵測與重傳設計,或改用TCP。
  • UDP優點與效率原因
    • 標頭欄位少、驗證少,傳輸效率高。
    • 在Ethernet MTU 1500下:IP約20 bytes;TCP最小20 bytes(可因Options增加),相較之下UDP負擔更小,使Data可承載更多有效載荷。
    • 網速不變時,有效資料承載越多傳輸越快;例子指出BT(BitTorrent)傳輸使用UDP常讓人感覺更快。
  • 為何DNS與即時性應用用UDP
    • DNS若走TCP需三次握手與結束流程,查詢變慢;UDP避免握手,回應更即時。
    • 網路電話/即時影音需連續播放,即使遺失部分資料也可容忍;TCP逐包確認會造成播放不連續。

DNS封包結構與重要欄位

  • DNS Header重點
    • Transaction ID(交易ID):客戶端隨機指定(類似UID),伺服端回覆以相同ID配對。大量並行DNS查詢(如載入含多張圖片的網頁)時,ID用於快速配對請求與回覆。
    • QR:指出封包為查詢或回覆。
    • Flags與Opcode等中間欄位:一般多為固定值或0,常見為「standard query」。
    • Question Count(問題數):一次查詢可含多個問題,數值以二進制表示。
    • Answer Count(答案數):回覆的資源記錄數量,例如1或4個IPv4位址。
    • Authority(權威)與Additional(附加)計數:現代用戶端場景常不需使用;講師以「104查號台」比喻Additional提供「若不信可再詢問」的附加資料,稱現今多已不用(歷史上曾用)。
  • Question區段
    • Question Name:欲查詢的名稱(網址)。名稱可長可短,DNS名稱在封包中以標籤長度機制編碼(講師以斜線提示有機制可壓縮/可變長,細節於後續課程)。
    • Question Type:查詢類型(如A代表IPv4,AAAA代表IPv6)。講師提到其編號,並於資安課將示範更多超乎想像的查詢用途與攻防。
    • Question Class:通常為IN(Internet,值為1),歷史上規劃多類,現今普遍只用IN。
  • Answer區段
    • Name:回覆中再次附送問題名稱。
    • Type/Class:分別指出記錄類型(如A/AAAA)與類別(IN=1)。
    • TTL(Time To Live):以秒為單位(例:5、300、600、900、1800)。表示快取期限,於期限內重複查詢同名時不再向DNS詢問。
    • TTL的策略用途:
    • 若伺服器欲節省頻寬、避免頻繁查詢,可將TTL設大(如900、1800)。
    • 若重視資安、防止被洗IP,TTL可設很小(如5),使用戶端立即忘記並再次查詢。
    • 大型內容服務(例:YouTube)為做流量分配與負載平衡,常將TTL調低,依每次查詢動態導向不同地區(美國、日本、德國、韓國)的伺服器。
    • RDLENGTH(RD length):回覆資料長度,例如IPv4為4 bytes。
    • RDATA(RD data):實際答案內容,依RDLENGTH變動,A記錄則為IPv4位址。

網頁載入與大量封包的關聯

  • 網頁資源與封包數量
    • 載入首頁流程:先下載index.html,再依內含連結(通常為網址而非IP)請求圖片、影音、廣告等資源。
    • 每張圖片前可能先DNS查詢,再TCP三次握手、HTTP請求、ACK往返、資料分段與ACK,單一圖片即可能產生十幾個封包;多張圖片與影音資源可累積至數百甚至上千封包。
    • 教學以ping與簡單DNS查詢示範,避免新手被大量封包干擾理解。

實作與觀察(WireShark + ping)

  • 前置檢查與清快取
    • 以圖形化介面或命令列查看本機DNS伺服器(Windows: ipconfig /all 或類似;講義提到「iafconfig、ipconfig /o」為口誤或簡寫,重點在確認DNS設定)。
    • 執行ipconfig /flushdns,顯示「成功清除DNS的快取」,避免快取影響觀測。
  • 抓包與過濾
    • 開啟WireShark,同步在命令列ping「WireShark.org」(講師口語亦稱wirehack.org,皆為示例目標;可替換其他網站)。
    • 停止抓取後設定過濾條件(Filter由學員自行研究,講師稍後提供指引)。
    • 預期封包序列:前兩個為DNS(查詢與回覆),接著約八個ICMP(ping的往返),最後可能再有兩個DNS(情境變化);若出現ARP,多為本機向Gateway詢問MAC位址。
    • 觀察:DNS回覆之IP可能變動屬正常,尤其在低TTL與負載平衡策略下。

進階課程預告與資安提示

  • 進階DNS風暴觀察
    • 本課只看用戶端到ISP DNS的風暴;後續課程將演示DNS間的遞迴/權威查詢風暴,包含若本機能加入特定節點時可見更完整流程。

2026-0317-02.png

封包結構分析(以 Wireshark 為例)

  • IP 層
    • 初學者可展開查看細節;有經驗的分析師通常關注來源與目的地 IP 位址。
    • IP 層協定欄位指示上層協定,例如 Protocol: UDP 表示承載的是 UDP 封包。
  • UDP 層
    • UDP 標頭核心資訊為來源埠(Source Port)與目的埠(Destination Port)。
    • UDP 標頭無欄位直接指明承載的應用層協定(如 DNS);Wireshark 依埠號解析應用層協定。
    • 送出封包時,Wireshark 檢查目的埠;若為 53,則解析為 DNS。
    • 接收封包時,Wireshark 檢查來源埠;若為 53,則解析為 DNS。
  • 應用層協定的埠號
    • 更改標準埠號(如將 FTP 的 21 改為 2100)技術上可行,但客戶端需知悉新埠號才能通訊。
    • 分析工具依賴標準埠號解析協定;使用非標準埠號可能導致 Wireshark 誤判、分析錯誤或顯示大量錯誤訊息(黑色標示)。

DNS 查詢封包(Query)

  • DNS 標頭欄位
    • Transaction ID:隨機數(如 8102),用於匹配查詢與回應;回應封包使用相同 ID。
    • Flags:包含多個標誌位。
    • QR(Query/Response):查詢封包為 0。
    • Standard Query:常見查詢類型,Flags 通常為 0x0100。
    • Counters:
    • Question Count:通常為 1。協定允許一包多問,但實務上幾乎都是一包一問。
    • Answer Count:查詢封包為 0。
    • Authority/Additional Records Count:查詢封包通常為 0。
  • DNS 問題區段(Question Section)
    • Name:查詢的網域名稱。
    • Type:查詢記錄類型。
    • A:查詢 IPv4 位址。
    • 若未停用 IPv6,可能同時發出查詢 AAAA(IPv6 記錄)的封包;若公司網路不使用 IPv6,會產生不必要流量。
    • Class:通常為 IN(Internet)。
  • 問題名稱(Name)的編碼方式
    • DNS 問題中的網域名稱為變動長度編碼。
    • 以一個數字位元組代表後續字元數量。例如 www.wireshark.org 編碼為 03 w w w 09 w i r e s h a r k 03 o r g。
    • 結尾以 00 位元組表示結束。
    • 該設計用以儲存不同長度的網域名稱。

DNS 回應封包(Response)

  • DNS 標頭欄位
    • Flags:
    • QR(Query/Response):回應封包為 1。
    • Standard query response:Flags 通常為 0x8180。
    • Counters:
    • Question Count:1,對應查詢封包的問題。
    • Answer Count:回應的答案數量,例如 2 表示有兩個 IP 位址。
  • DNS 答案區段(Answer Section)
    • Name:對應查詢的網域名稱。
    • Type:記錄類型,如 A。
    • Class:IN。
    • TTL(Time to Live):指示客戶端應快取於記憶體的時間(秒),例如 300 秒(5 分鐘)。在此期間再次訪問同一網站將直接使用快取,不再發出 DNS 查詢。
    • Data Length:RDATA 欄位長度;對 IPv4 位址(A 記錄)為 4 位元組。
    • Address(RDATA):實際 IP 位址。
  • 處理多個 IP 位址
    • 當 DNS 回應提供多個 IP 位址(如 104.25.10.6、104.25.11.6)時,依講師觀察,客戶端通常先使用列表中的第一個 IP 連線。
    • 除非第一個 IP 連線失敗,否則不會嘗試第二個 IP。

DNS 伺服器的選擇與影響

  • DNS 伺服器與連線問題
    • 不同 DNS 伺服器(如 8.8.8.8、1.1.1.1)可能對同一網域提供不同或排序不同的 IP 列表。
    • 某網站無法訪問時,可能因大多數人使用的 DNS 伺服器所提供 IP 的路徑出現問題(如海底電纜中斷);使用不同 DNS 的人可能獲得不同 IP,因而可正常訪問。
  • 判斷 DNS 伺服器好壞的方法
    • IP 數量:好的 DNS 伺服器可能返回所有相關 IP 位址,提供更多選擇;有些伺服器為節省流量僅返回一個 IP。
    • 進階使用者獲得多個 IP 位址更有利,因為提供備援。
    • 可將電腦 DNS 設定為不同伺服器,並用 Wireshark 觀察回應的 IP 數量與內容,以評估服務品質。

2026-0317-03.png