觀測與維運 — dig / 記錄檔 / 常見誤判

前章回顧: 第 5 章中,我們整理了 DNSSEC 的守備範圍、last hop 問題,以及多層防禦的組合。本章將把該防禦延伸到「在運作中的 resolver 上,觀測什麼才能察覺崩潰」。dig 的基本操作 (DNS101 中所涵蓋的範圍) 終究只是基礎,本章會進一步深入到從記錄檔中捕捉 poisoning 徵兆的模式。

在管理畫面之前，先看實際的回應

名稱解析問題發生時，比起先看記錄管理畫面的截圖，更快的作法是比較「affected resolver 現在回傳什麼」以及「在 authoritative path 上看起來如何」。

$ dig @192.0.2.53 www.example.com A
$ dig +trace www.example.com A
$ dig +dnssec www.example.com A

此處的 192.0.2.53 是範例用的 TEST-NET 位址。實際確認時，只使用自己管理的 resolver 或正當的觀測對象。

練習 6-1 — 最初的切分

比起管理畫面的印象，先比較實際的回應。

常見現象的切分

現象	首先懷疑的對象	最初的確認
使用同一 resolver 的多位使用者看到相同錯誤答案	shared recursive cache	比較受影響的 resolver 與 authoritative path
只有內部看到不同的 IP	split-horizon / 內部導向設計	設計意圖與內部 zone 是否存在
剛建立的名稱仍回傳 NXDOMAIN	negative caching	否定回應的 TTL
與 RRSIG / AD 有關的異常	DNSSEC validation / last hop	`dig +dnssec` 與 trust chain

negative caching 與誤判

「剛建立的名稱還看不到」、「internal 與 external 不一致」等現象，是與 poisoning 容易混淆的典型案例。先排除 negative caching 與 split-horizon，就能減少不必要的誤報。

提示： negative caching 的 TTL 由 SOA 的 minimum field 與 RFC 2308 所描述的行為決定。請記住，即使是「不存在」的結果也有壽命。

練習 6-2 — negative caching 與誤判

先排除與 poisoning 容易混淆的典型案例。

Q4. 13:00:00 時 NXDOMAIN 被 negative cache 300 秒。13:01:00 建立了該名稱的記錄，但到 13:02:00 時仍然顯示 NXDOMAIN。最接近的說明是？

因為 authoritative server 只回傳 MX 因為 negative caching 的 TTL 尚未過期因為 DNSSEC 自動失效因為是 browser 的 favicon cache

Q5. 下列何者作為懷疑 split-horizon / 內部導向設計而非 cache poisoning 的線索最接近？

同一個 shared resolver 上 random label query 急速增加記錄檔顯示粗率地接受了 Additional 中的 out-of-bailiwick data 簽章驗證 failure 持續發生只有公司內部的 resolver 回傳內部 IP，public authoritative 端依設計回傳不同的答案

從記錄檔捕捉異常的模式

除了用 dig 個別確認之外,定期觀察 resolver / 查詢記錄檔,有助於更早察覺「現在有事正在發生」「過去曾發生過什麼」。作為中級課程的觀測,記住下列 3 種模式在現場會很有幫助。

1. 對同一 zone 的 random label 集中

對同一個父 zone 在短時間內集中出現大量沒見過的子網域 query,且 NXDOMAIN 比率偏高。這與刻意製造 fresh miss 以累積 attempts 的行為一致。同時觀察 querier IP 的偏向與時段的集中。

2. RRSIG 驗證 failure 的連續

當對同一 zone 的簽章驗證 failure 在短時間內連續發生時,以 (a) zone 端的金鑰輪替 / 簽章逾期、(b) 路徑上的回應竄改或誤接受、(c) 驗證端的時鐘偏差,這 3 軸切分。先確認自身的 clock 與 zone 的維運狀況,再把剩餘的疑慮追查為 poisoning 或中間人。

3. NAT / port 觀測的劣化

用 NetFlow / pcap 取得對外 UDP 的 source port 分佈,定期確認是否從預期的高 ephemeral 帶縮減為狹窄的連續編號帶。可及早捕捉 NAT 設定變更或 middlebox 行為變化。

練習 6-3 — 從記錄檔捕捉異常的模式

作為中級課程更進一步,確認從 resolver / 查詢記錄檔中捕捉 poisoning 徵兆的觀點。

Q6. 對某個 zone,在短時間內集中了大量對沒見過的子網域的 query,且每一筆都回傳 NXDOMAIN。從 cache poisoning 的觀點看,最妥當的假設是哪一個？

使用者剛好打了大量錯字可能是類似 Kaminsky 型的行為徵兆,刻意大量發生 fresh miss 以累積 attempts negative caching 出現異常 DNSSEC validation 成功的證據

Q7. 在 validating resolver 的記錄檔中,「對同一 zone 的 RRSIG 驗證 failure」在短時間內連續發生。最先應該切分的假設組合中,最適切的是哪一個？

應該全面清除瀏覽器的 cache (1) zone 端的金鑰輪替 / 簽章失效、(2) 中間路徑上的竄改或錯誤回應的混入、(3) 自身 resolver 的時鐘偏差把 DS 記錄放在 child 端就能解決把 TTL 設為 0 就能通過驗證

本章重點整理

先比較 affected resolver 與 authoritative path
+trace 適合觀察 delegation path
先排除 negative caching、split-horizon、browser cache 等誤判因素
記錄檔中持續觀測「random label 集中」「RRSIG 驗證 failure 連續」「port 分佈縮減」