小村軟體有限公司
第 5 章

DNSSEC 與多層防禦 — 保護什麼、剩下什麼

掌握 DNSSEC 的守備範圍與 last-hop 的局限,組合為多層防禦。

前章回顧: 第 4 章中,我們從 2008 年的教訓整理了短期 hardening (patch、entropy、recursion 限制、監控) 的組合。本章中將更進一步,確認 DNSSEC 守護什麼、不守護什麼,以及在「最後一段 (last hop)」中還剩下什麼。

DNSSEC 是「用簽章來驗證」的機制

DNSSEC 會對 DNS data 加上簽章,讓 resolver 能沿著簽章鏈去驗證。核心是 origin authentication 與 integrity,並不是把通訊內容本身保密。

parent DS
從父區指向子區 DNSKEY 的雜湊/參照。
child DNSKEY
該區用於驗證的公開金鑰。
RRset + RRSIG
RRset 本體與覆蓋其上的簽章。

從 parent 的 DS 到 child 的 DNSKEY,再到 RRset 的 RRSIG,一路沿著 trust chain 走下去。

提供的 / 不提供的

提供的
data origin authentication、data integrity、authenticated denial of existence。
不提供的
query / response 的保密,以及通訊路徑的加密本身。

練習 5-1 — 要守什麼、不守什麼

把「用簽章驗證」與「保密」分開看。

Q1. 下列哪一項不屬於 DNSSEC 所提供的能力?

Q2. 下列哪一項原則上不是 DNSSEC 提供的?

Q3. 下列哪一項最接近 DS 記錄的角色?

分辨 secure / insecure / bogus

signed zone 若驗證通過就是 secure。有些 zone 在 parent 沒有 DS,屬於 unsigned / insecure。相對地,當 parent 有 DS 卻無法沿到 child 的金鑰或簽章時,就要當成 bogus 來處理。

狀態DS / 金鑰 / 簽章的狀況意義
secure有 DS,DNSKEY / RRSIG 的驗證也通過簽章驗證成立
insecureparent 沒有 DS(unsigned zone)沒有 DNSSEC 的保證,但在設計的預期範圍內
bogus有 DS 卻驗證不通過疑似竄改或設定不全,不應作為回應使用

練習 5-2 — 分辨 secure / insecure / bogus

由 DS 的有無,以及 DNSKEY / RRSIG 的驗證結果決定狀態。

Q4. 當 parent 有 DS,但 child 的 DNSKEY / RRSIG 驗證無法通過時,validating resolver 最接近的處理方式是什麼?

last hop 的問題

即使 recursive resolver 在做 validation,也無法保證 stub 能充分信任那個 resolver 或通訊路徑。RFC 4033 指出,若 security-aware stub resolver 要實際享受 DNSSEC 的好處,必須同時信任 recursive server 與 channel 兩者。

因此 AD bit 是有用的提示,但並不是萬能的端到端證明。

無法信任 last hop 的典型情況
(1) 在公共 Wi-Fi 上,攻擊者透過 DHCP 派送偽造的 DNS 伺服器。(2) 在公司網路中混入流氓 DHCP 伺服器,把 recursive resolver 的 IP 覆蓋掉。(3) 中間人介於 stub 與 recursive 之間,擅自將 AD bit 設為 1 並回傳偽造回應。在這些情況下,即使看到 AD=1,也無法保證 stub 所對話的「validating resolver」是真的。

在這類環境中,必須與另外保護 stub 與 recursive 之間通訊路徑的機制 (DoT / DoH,或經由 IPsec 將可信任的 resolver 固定下來等) 結合考量。

用實例看簽章驗證 — dig +dnssec 的輸出

單靠概念不容易掌握,以實際的 dig 輸出來確認。對 signed zone (例:example.) 加上 +dnssec 查詢時,flags 會出現 ad,並在 ANSWER 中排列出 RRSIG 記錄。

$ dig +dnssec example. SOA

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.                       IN      SOA

;; ANSWER SECTION:
example.                3600    IN      SOA     sns.dns.icann.org. noc.dns.icann.org. 2024010101 7200 3600 1209600 3600
example.                3600    IN      RRSIG   SOA 8 1 3600 20260601000000 20260501000000 12345 example. AbCdEf...(簽章資料)

這裡要注意的有以下兩點:

flags 中出現 ad
表示 validating recursive resolver 成功完成了簽章驗證,並設定 AD bit 後回傳。
ANSWER 中排列著 RRSIG
對應 RRset 本體的簽章記錄。從 stub 看到的 RRset 與 RRSIG 配對,正是在 recursive 端被驗證後回傳的結果。

反之在 bogus (有 DS 卻無法通過驗證) 的情況下,會看到 status: SERVFAIL 且 ANSWER 為空。這是實作體現「未能通過驗證的回應就不該使用」的例子。

組合為多層防禦

無論只靠 DNSSEC,或只靠 query matching、port entropy,單獨都不夠。比較現實的做法,是把入口(patch、recursion 限制)、一致條件(ID / port / question / bailiwick)、驗證(DNSSEC)、維運(監控・記錄檔)疊在一起思考。

patch / update
堵住已知漏洞與 query matching 的缺陷。
ID / port entropy
連同外部可見的 port 空間一起,盡量維持寬廣。
glue / bailiwick hardening
不隨便接受 referral 的 additional。
recursion control
recursion 只提供給信任的 client。
DNSSEC validation
能做就運行 validating resolver。
監控
捕捉 random label 的急增、連續的驗證失敗等。

練習 5-3 — last hop 與多層防禦

讀 AD bit 與多層防禦時,要意識到 trust 的邊界。

Q5. 對於 stub resolver 而言,下列對 AD bit 最貼切的說明是哪一個?

Q6. 以下對於 modern resolver 防禦做法的說明,最平衡的是哪一個?

本章帶走的要點

  • DNSSEC 提供 origin authentication / integrity / authenticated denial of existence
  • confidentiality 是另一回事,光靠 DNSSEC 得不到
  • AD bit 與 validating resolver 的結果,要連同 last hop 的信任問題一起解讀
  • 不要只靠單一機制,把 patch・entropy・bailiwick・DNSSEC・監控疊起來