小村軟體有限公司
第 1 章

導入 — 什麼是 DNS 快取毒化

掌握共用解析伺服器記下偽造的 RRset 後,所有使用者都會看到相同錯誤答案的整體圖像。

首先要記住的示意圖

登場角色職責
使用者 / browser進行名稱查詢的一方,信任 resolver 的回答。
shared recursive resolvercache 位於此處,由多位使用者共用。
authoritative servers持有各區域的正規資料。

若錯誤的 RRset 殘留在 shared recursive resolver 的 cache,使用該 resolver 的所有使用者都會收到相同的錯誤答案。

DNS 快取毒化是「共用記憶的竄改」

在 DNS 中,真正危險的不是單一使用者的終端暫時搞錯,而是 shared recursive resolver 記住了偽造的 RRset 並反覆重複使用。在使用者眼中 resolver 看起來像是「知道答案的主體」,但其實看不出那個答案是真品還是 cache。

因此在 troubleshooting 時,必須先把「現在看到的答案是 authoritative、cache,還是 referral 的中途」分開思考。

練習 1-1 — 先把 shared cache 放在主角位置

權威伺服器的 compromise 與 shared recursive resolver 的 poisoning 有時看起來很像。但在防禦與觀測時,應該最先追查的位置並不相同。

Q1. 在 DNS 快取毒化中,會成為核心問題的狀態是哪一個?

問題的核心是「共用解析伺服器記下了什麼」。

Q2. 當一台共用的遞迴解析伺服器被 poison 後,影響容易擴散的主要原因是哪一個?

思考「一台會回傳給多少人」會比較容易整理。

因為有 TTL,錯誤答案會「殘留一段時間」

被 poison 的 RRset 不是在接受的那一瞬間就永久化,而是在 shared cache 中殘留至 TTL 的有效期限。因此即使套用了 patch,在已經殘留的 cache entry 壽命耗盡之前,仍可能看到相同的錯誤答案。

在觀測時,若查看「剩餘 TTL 是否相近」、「使用相同 resolver 的多位使用者是否看到相同值」,就比較容易與 browser 個別的問題區分開來。

練習 1-2 — 錯誤答案只會在 TTL 期間殘留

被 poison 的 RRset 在 shared cache 中會殘留至 TTL 的有效期限。若能追蹤剩餘秒數,就比較容易進行觀測與切割。

Q3. 共用解析伺服器在 09:00:00 接受了一個 TTL 300 秒的錯誤答案。在 09:03:00 時的剩餘 TTL 是幾秒?

從 09:00:00 到 09:03:00 已經經過 180 秒。

秒

不要混淆看起來相似的現象

internal DNS、split-horizon、negative caching、browser 的 HTTP cache,從使用者的角度看,都可能呈現「名稱解析怪怪的」。正因為如此,先確定「是哪一層的 cache」,再去看 authoritative path 與 affected resolver 的差異,才是重要的做法。

什麼是 split-horizon: 對相同名稱,在公司內 resolver 與公司外 (public) resolver 刻意回傳不同答案的 DNS 運維設計。例如從公司內回傳內部 IP、從公司外回傳公開 IP,是常見的構成。詳情會在第 6 章說明,不過閱讀 Q4 選項時,請先記住「這種刻意的設計差異」可能存在。

練習 1-3 — 不要混淆看起來相似的現象

internal DNS、split-horizon、negative caching、browser 的 HTTP cache 看起來可能很相似。要先確定「是哪一層的 cache」。

Q4. 對於「同一個內部名稱在公司內 resolver 與 public resolver 看到不同結果」的情況,最有可能的說明是哪一個?

看起來不同,未必就能立刻斷定是攻擊。

Q5. 關於避免把 DNS 快取毒化與 HTTP 快取混為一談,哪一個說明是正確的?

DNS 的 TTL 與 HTTP 的 cache-control 屬於不同的層。

第 1 章重點整理

  • DNS 快取毒化的主戰場是 shared recursive resolver 的記憶
  • 錯誤答案會在 TTL 期間殘留,因此要把 patch 與 cache 壽命分開思考
  • 不要與 split-horizon 或 HTTP cache 等看起來相似的現象混淆