總復習與案例研究
透過 8 題案例問題，橫跨 bailiwick、entropy、NAT、DNSSEC、維運等視角完成收尾。
在這裡收尾
本章透過 8 題案例問題，橫跨 glue / entropy / NAT / AD bit / negative caching / split-horizon 一起求解。要確認的不是單章的知識，而是能否結合多個章節的視角來判斷。
合格目標： 在 8 題案例中答對 6 題以上，就代表在 cache poisoning 的防禦與觀測上，已能充分勝任現場初步切分的程度。
總復習會用到的視角
| 章節 | 本章會用到的看法 |
|---|---|
| 第 1 章 | 區分「誰的 cache 被誰寫入了答案」 |
| 第 2 章 | in-bailiwick glue 與 out-of-bailiwick additional 的差別 |
| 第 3 章 | ID / source port / question / time window 的一致與 entropy |
| 第 4 章 | 2008 年的教訓與 patch / recursion control 的短期對策 |
| 第 5 章 | DNSSEC 的守備範圍與 last-hop 的 trust 問題 |
| 第 6 章 | dig、記錄檔、negative caching / split-horizon 的切分 |
總復習 7-1 — bailiwick・entropy・DNSSEC (機制軸)
以案例確認 referral 的處理方式、port entropy、AD bit 與 last hop 等「機制能守到哪裡」。
Q1. 父 zone 的 referral 中一起回傳了 NS ns1.shop.example.com 與 A ns1.shop.example.com 192.0.2.53。最妥當的處理方式是？
這應該作為追蹤到子 zone 用的 in-bailiwick glue、限定性地使用。不要等同於 shop.example.com 底下任意名稱的一般最終 answer。
Q2. referral 中 Additional 附上了 NS ns.partner.net 與 A ns.partner.net 198.51.100.10。最安全的判斷是？
安全的做法是意識到可能是 out-of-bailiwick，必要時另行解析 ns.partner.net 本身。全面相信 referral 中混入的附加資料是危險的。
Q3. resolver 位於 NAT 之後，對外的 source port 實際上被縮成 256 種連號。此時最正確的說明是？
最接近的說明是 port entropy 大幅減少、spoof 耐受度容易降低。source port randomization 的關鍵是「從外部看到的多樣性」。
Q4. stub resolver 收到 AD=1 的回應，但其 upstream recursive resolver 與通訊路徑都不夠可信。此時最適當的解釋是？
AD=1 雖是有用的線索，但若沒有充分信任該 recursive resolver 或通訊路徑，就不能視為萬能的端到端證明。不要忘記 last hop 的信任問題。
Q5. 目標 zone 是 unsigned。最正確的說明是？
unsigned zone 無法只靠 DNSSEC validation 守護。因此 query matching、entropy、glue hardening、recursion control 等其他 hardening 依然重要。
總復習 7-2 — 維運、監控、整體方針 (維運軸)
確認監控訊號、cache TTL 的壽命與組織方針等「在現場該怎麼運轉」。
Q6. 對某個 zone 在短時間內持續湧入大量 random 的不存在標籤 query。從 cache poisoning 的觀點，最接近值得注意的理由是？
當對不存在標籤的 random query 增加，uncached 的查詢機會也會增加，miss 與負擔會上升。race 的嘗試次數可能增加，因此這是監控上的訊號。
Q7. 套用 patch 後緊接著，預期使用同一 resolver 的使用者還會在接下來 2 分鐘內看到相同的錯誤答案。最直接的原因是？
因為已經寫入的 cache entry TTL 還沒過期。即使修好了軟體，既有的 stale / poisoned data 仍有殘餘壽命時，看到的結果不會立刻改變。
Q8. 對組織的 recursive resolver 而言，最適當的整體方針是？
最適當的是組合 patch/update、ID/port entropy、glue/bailiwick hardening、對 trusted clients 的 recursion 限制、DNSSEC validation、監控的方針。重點是不依賴單一設定。
本課程的着陸點
- 能說明：一旦 shared recursive resolver 的 cache 中殘留錯誤的 RRset，就會讓全體使用者都被分配到相同的錯誤答案。
- 能區分 referral / final answer / glue，並意識 in-bailiwick / out-of-bailiwick 加以處理。
- 能以公式與數字掌握回應接受條件（question / ID / address / port）與 entropy 與嘗試次數 的關係。
- 能說明 DNSSEC 的 origin authentication / integrity / authenticated denial of existence 與 confidentiality 是不同的事。
- 能結合 last hop 的 trust 問題 來解讀 AD bit 的意義。
- 遇到問題時，能先用
dig @resolver/dig +trace/dig +dnssec觀察回應，並優先排除 negative caching 或 split-horizon。 - 最終能結合 patch、entropy、bailiwick、DNSSEC、維運監控 來思考。
接下來做會更容易紮根的事
- 在自己管理的 resolver 上執行
dig +trace與dig +dnssec，親眼確認 referral 與簽章驗證的輸出。 - 分別選 1 個 unsigned zone 與 signed zone，觀察
adflag 的差異。 - 刻意製造 negative caching 的 TTL 還殘留的情境，親手體驗「明明建立了卻看不到」的典型。
- 在維運端，確認是否有能捕捉 random label 急增或簽章驗證 failure 記錄檔的監控。