以下是 gpt 的問答
提問:
dnssec 掛掉時，實際的解決方式是什麼 https://blog.cloudflare.com/de-tld-outage-dnssec/
GPT 回答
我會先核對 Cloudflare 這篇文章的事件脈絡，再整理成「當 DNSSEC 壞掉時實務上怎麼救」的操作層級答案。
實際解法不是「修好每個 .de 網域」，而是在 遞迴解析器端暫時繞過壞掉的 DNSSEC 驗證，同時等待 TLD registry 修正簽章。
以這次 .de 事件來看：
- 根因
DENIC 在 2026-05-05 約 19:30 UTC 開始發布錯誤的.deDNSSEC 簽章。DNSSEC validating resolver 依規格必須拒絕這些回應，所以會回SERVFAIL。因為錯在.deTLD 層，影響會往下擴散到所有.de網域。 - 第一層緩解：serve stale
Cloudflare 1.1.1.1 先靠 serve stale 撐住部分流量：如果 resolver cache 裡還有事件前取得的有效紀錄，即使 TTL 過期，也先繼續回舊資料，而不是立刻回SERVFAIL。這只能保護「cache 裡本來就有」的紀錄，沒有快取的新查詢仍會失敗。 - 真正讓解析恢復的手段：Negative Trust Anchor / 等效機制
Cloudflare 後來把.de暫時標成 insecure zone，效果等同於 RFC 7646 的 Negative Trust Anchor, NTA：告訴 validating resolver「針對.de底下的名稱，暫時當作沒有 DNSSEC，不做驗證」。這讓 resolver 可以回 DNS 答案，而不是因為壞簽章回SERVFAIL。Cloudflare 在 22:17 UTC rollout 這個 mitigation，1.1.1.1 的影響結束。 - 代價
這不是無風險。暫停.de的 DNSSEC 驗證期間，.de網域會暫時失去 DNSSEC 提供的防竄改保護。但在這種 TLD 層級、公開確認、廣泛影響的事故中，實務判斷是：回未驗證但可用的 DNS 答案，比對所有使用者回 SERVFAIL 更好。
所以可以簡化成：
DNSSEC 掛掉時，resolver 端的實務救法是：先 serve stale，有必要時對故障 zone/TLD 加 Negative Trust Anchor，暫時跳過 DNSSEC validation；registry/authoritative 端則修正簽章或 key rollover 問題後，再移除 NTA。
如果你是維運自己的 resolver，實際 runbook 大概是：
1. 確認是 DNSSEC bogus，而不是 authoritative timeout / network issue
2. 用 dig +dnssec、delv、unbound-host 或 resolver log 確認壞在哪一層
3. 若是上游 TLD/parent zone 故障，啟用 serve-stale
4. 對受影響 zone 設定 NTA / insecure override
5. 設定很短的到期時間，避免忘記移除
6. 持續監控 DS/DNSKEY/RRSIG 是否恢復一致
7. 上游修復後移除 NTA，恢復 DNSSEC validation以 Unbound 為例，概念上會是：
unbound-control list_insecure
unbound-control insecure_add de
# 修復後
unbound-control insecure_remove de但重點是：NTA 應該是短期、明確範圍、可稽核的 incident mitigation，不是常態設定。
提問
什麼是 serve-stale
GPT 回答
serve-stale 是 DNS resolver 的一種「先回舊答案」機制。
正常 DNS 流程是：
查詢 example.com
→ resolver cache 裡有答案，而且 TTL 還沒過期
→ 直接回 cache如果 TTL 過期，正常情況下 resolver 會去 authoritative DNS 重新查。但如果 authoritative DNS 掛了、網路不通、DNSSEC 驗證暫時失敗，resolver 可能拿不到新答案。
serve-stale 的做法是：
cache 裡有舊答案
→ 雖然 TTL 已經過期
→ 但上游查詢失敗
→ 先把舊答案回給使用者也就是：
寧可回一個可能稍微過期、但大概率仍正確的 DNS 答案，也不要直接回 SERVFAIL。
舉例：
www.example.de A 203.0.113.10
TTL = 300 秒5 分鐘後 TTL 過期。resolver 應該重新查詢。
但如果這時 .de DNSSEC 壞掉，resolver 重新查會失敗。若啟用 serve-stale，而且 cache 裡還有舊的 203.0.113.10，resolver 可以先回：
www.example.de A 203.0.113.10這樣使用者可能完全感覺不到 DNS 故障。
不過它有幾個限制：
- 只能救 cache 裡已經有的紀錄
如果 resolver 從來沒查過某個網域，沒有舊答案可回，serve-stale 幫不上忙。 - 舊答案可能已經不準
如果網站剛換 IP、剛改 MX、剛做 failover，serve-stale 可能會回到舊資料。 - 它不是修 DNSSEC 的方法
serve-stale 只是降低故障影響；真正的修法仍是修正 authoritative zone 的簽章、DS、DNSKEY、RRSIG，或短期使用 NTA 繞過壞掉的 DNSSEC 驗證。
可以把它想成 DNS 的「備用快取模式」：
正常情況：回新資料
上游壞掉：回舊資料
沒有舊資料：還是失敗在 .de 事件裡，serve-stale 讓 Cloudflare 1.1.1.1 對已快取的 .de 網域繼續回應，但對沒有快取的查詢無法救，所以後來才需要把 .de 暫時標成 insecure zone。
留言