.de TLD DNSSEC rollover 翻車——stale-serve 與 NTA 撐三小時

2026 年 5 月 5 日 19:30 UTC， DENIC 對 .de 區進行一次例行的 KSK rollover， 發出去的 RRSIG 卻無法被任何符合 DNSSEC 規範的解析器驗證。 從那一刻起， 故事的所有後續發展都被一條硬規則決定： bogus 就是 bogus，驗證器 MUST 回 SERVFAIL。 三小時後， 是 stale-serve 與 negative trust anchor 兩條臨時延長線把網際網路撐到 Cloudflare 22:17 UTC 的修補與全球 resolver 同步把 NTA 推上線—— 德國的 web 才慢慢回到 NOERROR。

DNSSEC 與常見故障最大的不同是它的「正確失敗」是 by design：簽章算不過時，規範要求驗證器主動拒絕。若降級為「無法驗證但仍回答」，整套設計就失去意義。這個性質意味著一次 TLD 級的操作失誤，會被規範本身放大成「整個子樹立即下線」。這次事件的所有後續討論——NTA 為什麼必要、stale-serve 為什麼是剛需——都繞著「規範強制下線」這個前提打轉。

19:30 UTC——DENIC 一次 KSK rollover 發出無法驗證的 RRSIG

背景是 DNSSEC 的兩把鑰匙： ZSK（Zone Signing Key）日常簽 zone 內所有 RRset， KSK（Key Signing Key）簽的是 DNSKEY RRset， 並透過父區 root 發布的 DS record 與信任鏈接續起來。 輪換 KSK 是 DNSSEC 操作裡最敏感的一步—— 你要先把新 KSK 的 hash 放進父區的 DS， 再切換 zone 內 DNSKEY 的角色， 整套過程必須讓 cache 中的舊紀錄與權威伺服器上的新紀錄之間始終有一條可被驗證的鏈。 DENIC 在 19:30 UTC 推送的那一批 RRSIG 沒能滿足這個條件。

更精確地說： DENIC 在這個時點把新的 KSK 設為「active signing」角色， 並用新 KSK 重簽 .de 的 DNSKEY RRset。 事後分析指向， 這個重簽過程裡至少有一批被發布到 public secondary 的 RRSIG， 當你拿 .de DNSKEY 裡對應的那把公鑰去驗證時， 怎麼算都不對。 簽章是「non-validatable」—— 這是 DENIC 自己對外的措辭， 沒有更細的技術歸因。 對驗證器來說， 這就是 bogus； 對 zone operator 來說， 這意味著生產鏈裡某一步沒有做端到端驗證， 把一份壞掉的簽章順著發布管道送到了全網。

Cache 行為讓失誤被放大。.de DNSKEY 典型 TTL 86400 秒、root DS TTL 7200 秒——全球 resolver 不是同步看到新內容：有些 cache 還握著舊 DNSKEY 驗證仍能過，有些已 expire 拉到新的就壞。事件初期幾分鐘內各 resolver 狀態不一致，事故「真正起點」會被誤讀為慢慢爬升的曲線而不是垂直跳起的台階。

下方時間軸把事件節點放進可拖曳 scrubber——推到任意時間點，可看到該刻全球驗證器與 1.1.1.1 對 .de 的狀態。

scrub the handle along the axis 把上方的圓形把手拖到任意時間點，看那一刻全球 DNSSEC 驗證器與 1.1.1.1 對 .de 查詢的狀態。

事件來源：Cloudflare blog（2026-05-05 timeline 與 1.1.1.1 query log 描述）。時間軸涵蓋 18:30 至 23:00 UTC。

Cloudflare 在事後說得直接： 「any validating DNS resolver receiving these signatures was required by the DNSSEC specification to reject them」。 也就是說， 從 19:30 UTC 起， BIND、Unbound、Knot Resolver、PowerDNS Recursor、systemd-resolved、 所有 1.1.1.1 / 8.8.8.8 / 9.9.9.9 等公開 resolver—— 只要打開了 DNSSEC 驗證—— 都被規範本身強迫對 .de 的任何回應回 SERVFAIL。 沒有「降級」這個選項； DNSSEC 的安全模型就是建立在「驗證失敗等於不回應」之上的。

打開 EDE (Extended DNS Errors, RFC 8914) 的 resolver 在 SERVFAIL 上附帶結構化錯誤碼，攻擊面分析直接讀 EDE: 6 (DNSSEC Bogus) 並指出具體 RRset：

;; status: SERVFAIL, id: 12345
;; EDE: 6 (DNSSEC Bogus): (RRSIG with malformed signature
;;     found for example.de/nsec3 (keytag=33834))

keytag=33834 指向 DENIC 在 rollover 中正在切換的那把 KSK； nsec3 則是 .de 用來做 authenticated denial of existence 的記錄類型—— 換句話說， 連「這個名字不存在」這種否定回應， 因為它的 NSEC3 鏈也被同一把 key 簽， 一樣會 bogus。 整個 zone 都被自己的簽章鎖了起來。

EDE 6 與單純 SERVFAIL 在客戶端訊號處理上差異巨大。沒有 EDE 的 resolver 只能對應用程式吐 SERVFAIL——一個語意極度模糊的錯誤碼，可能是網路斷、權威死、query 被 truncate、或 DNSSEC 失敗。多數 HTTP client 看到 SERVFAIL 的 fallback 是「retry」或「換 resolver」——對 DNSSEC 失敗都沒用：re-query 撞到同樣簽章、換 resolver 多半也啟用 DNSSEC。EDE 6 出現時客戶端應停止重試並把訊息傳達給使用者。

為什麼一個 TLD 的簽章錯誤會把整個 .de 變成 SERVFAIL

DNSSEC 的信任鏈是嚴格的父對子： root zone 的 DNSKEY 由社群以 ceremony 形式管理； root 的 DS 指向 .de 的 DNSKEY； .de 的 DNSKEY 簽 .de 區內所有 RRset， 包括給每一個 example.de 的 DS。 驗證 www.example.de 的 A record 時， validator 從 root 一路往下檢查： 每一步的 DS hash 必須對得上下一層的 DNSKEY， 每一層的 RRSIG 都必須能用那把 DNSKEY 驗過。

這個設計的隱含假設是「每一層的操作者都比下一層更可信」。Root KSK 由 IANA 透過實體 ceremony 管理，一年只動兩次；.de KSK 由 DENIC 管理，操作頻率高很多但仍在 HSM 內、有 dual control；example.de 自己 ZSK 在自動化 pipeline 跑。這種「越上層、操作越保守、影響範圍越大」的金字塔，在這次事件裡正好相反過來：DENIC 這層中等保守的操作出了失誤，把下面所有層級拖下水。

下圖把信任鏈五個主要角色拆開——點任意元件可看它在這次事件裡承擔的責任、知道與不知道什麼。

root zone · DS for de.

Root 區公布的 DS 紀錄宣告「.de 的 KSK 公鑰 hash 應該是 X」。這個 DS 由 root 的 KSK 簽署，trust anchor 直接寫死在每個 validator 裡。

事件中：root 的 DS 沒問題、沒改動，仍然正確指向 .de 應有的 KSK。

不知道 → 子區 RRSIG 是否真的對。父子之間只簽 key 的 hash，不簽資料。

.de KSK · keytag 33834

負責簽 .de 的 DNSKEY RRset。Validator 用 root 給的 DS hash 對得上這把 KSK，就代表「root 認證了 .de 用這把 KSK 簽 key」。

事件中：新 KSK 的 hash 已經放進 root DS、KSK 本身有發布，但用它去驗 .de 自家 zone 的 RRSIG 算不過——這是故障的核心位置。

不知道 → 自己簽出去的 RRSIG 在下游真的能驗證。沒有 pre-publish loop 把這條閉環。

.de ZSK + RRSIG

ZSK 日常簽 zone 內所有 RRset（DS、NS、NSEC3、glue ...）。每一份 RRSIG 帶 keytag 指向產生它的那把 key。

事件中：對外發送的 RRSIG 對應 keytag 33834（新 KSK 角色）的那批簽章是 malformed；連 NSEC3 的否定回應簽章也壞掉，整個 zone 對 validator 失去密碼學意義。

不知道 → 上游 KSK 在這次 rollover 是否做了 ceremony 之外的額外切換。對 ZSK 角色來說，KSK 只是「告訴它今天該用誰簽 DNSKEY」。

example.de · 任意子 zone

子 zone 自己的 DS、NS、甚至 glue record 都放在 .de 區裡，由 .de 的 ZSK 簽。子 zone 自己有沒有簽 DNSSEC 都不影響——只要 .de 區內的 referral 簽章壞了，validator 就無法繼續往下走。

事件中：所有 .de 結尾的域名一律 SERVFAIL，無論 example.de 自己是 secure、insecure 還是根本沒開 DNSSEC。

不知道 → 父區發生了什麼事。子 zone 操作者只看到「我這邊沒動，但全世界都查不到我了」。

DNSSEC validator

Recursive resolver 內的驗證模組。從 root 一路往下檢查 DS → DNSKEY → RRSIG。任一層 bogus，整棵子樹返回 SERVFAIL，且附帶 EDE 6（如果有開）。

事件中：規範要求 validator 必須拒絕，沒有「降級為 insecure」的選項。唯一允許的「繞過」是 operator 主動掛 NTA（RFC 7646）。

不知道 → 簽章為什麼壞。它只知道「算出來不對」，是 DENIC 操作失誤還是 in-flight 攻擊都長同樣的樣子。

點任意方框檢視該組件的責任與「不知道什麼」。圖中虛紅色箭頭標出這次事件的斷點——KSK 與 ZSK 之間，DENIC 推出的 RRSIG 對應 keytag 33834 算不過。

關鍵設計在於： 任何一層斷掉， 下面所有層級都失效。 Validator 看到 .de 的 DNSKEY RRset 無法用 root 的 DS hash 對應的那把鑰匙驗過—— 或者 .de 內某個 RRSIG 完全 malformed—— 它就會把整棵子樹標成 bogus。 請注意四個 DNSSEC 狀態的差別：

• secure：鏈完整、所有 RRSIG 驗證通過、資料可信。
• insecure：父區沒有發布 DS，子 zone 明確選擇不簽——這是合法狀態，validator 直接放行。
• bogus：父區發布了 DS（宣告子 zone 應該簽），但 RRSIG 驗證失敗。這時規範要求 validator 必須回 SERVFAIL，不得回答 query 結果。
• indeterminate：較罕見，validator 無法判斷父區是否啟用 DNSSEC（例如查不到 trust anchor）。

DENIC 那批簽章把整個 .de 推到 bogus。example.de 自己有沒有簽 DNSSEC 都不重要——它的 DS、NS 都在 .de 區裡，同樣 bogus。對最終使用者就是：德國的銀行、鐵路、電商、新聞，只要 .de 結尾都連不上，「millions of domains unreachable」。

NSEC3 鏈也壞了：用來簽「這個名字不存在」否定回應的簽章由同一把 ZSK 產生，所以連「確認不存在」的回應也拿不到。瀏覽器 NXDOMAIN fallback、DNS-based ad-blocker 負面 list、email 的 SPF/DKIM/DMARC lookup 一律 SERVFAIL。對 email 系統影響特別大：許多實作把「DNS 查不到」當 fail-open，但回 SERVFAIL 時 spam filter 多半解讀為 transient error 而 defer——事件期間所有 .de 寄出的合法郵件都進入 retry queue，DNS 恢復後還要花更久消化堆積。

KSK rollover 的五步操作——以及這次卡在哪一步

標準 KSK rollover 流程（RFC 6781 第 4.1.2 節，Double-KSK 方案）是五步舞。下方 scroll-driven 圖示把這五步拆開，紅色高亮指出這次事件可能卡在哪一步。

Step 1 · 起點

Zone 用單把 KSK（K-old）簽 DNSKEY；root 公布的 DS 指向 K-old；ZSK 日常簽資料。Validator 對所有查詢都驗得過。

這是穩定態，可能維持數年。

Step 2 · K-new 加入 DNSKEY RRset

Zone operator 生成新 KSK（K-new），把它加進 DNSKEY RRset；同時用 K-old 與 K-new 各簽一次 DNSKEY。validator 仍然用 K-old 驗證；K-new 已經在 cache 裡，但還沒被信任。等所有 cache 都看到 K-new——通常 TTL 上限是兩天。

這一步沒有對外可見的變化。

Step 3 · 父區 DS 切到 K-new

Zone operator 通知 root 更新 DS——把指向 K-old 的 hash 換成 K-new 的 hash（或同時公布兩個 DS）。Root 推送，validator 從 root 拿到新 DS。從此 K-new 才有了 root 級別的信任。

父子協調最敏感的時點。

Step 4 · K-old 退役

Zone operator 從 DNSKEY RRset 移除 K-old，只留 K-new；用 K-new 重簽 DNSKEY。validator 用 root 給的 K-new hash 驗 K-new，再用 K-new 驗 DNSKEY RRset，整條鏈閉合。

這次事件據信卡在這一步附近——重簽 DNSKEY 時 RRSIG 產出 bogus。

Step 5 · 等 cache 沖洗

等舊 DNSKEY、舊 DS 在所有 cache 過期。Rollover 完成；zone 回到 Step 1 的穩定態（K-new 變 K-old）。從這一刻起，KSK 切換可以再開始一輪。

整套流程通常需要 30 天以上。

scroll · 右側狀態跟著左側段落變

Step 4 是這次事件的最大嫌疑點。從 EDE 訊息裡的 keytag=33834 與 NSEC3 失敗共同指向「DENIC 用新 KSK 角色重簽 DNSKEY、ZSK 又重簽整個 zone 時，至少一批 RRSIG 算錯了」。這種錯誤通常不會來自演算法本身——SHA-256 + RSA 標準組合都很穩——而是更可能來自簽章生成 pipeline 的某個邊界條件：簽到一半換 key、把舊 key 的 timestamp 帶到新 RRSIG、或 zone serial / record ordering 在某種狀況下與簽章時的快照不一致。DENIC 還沒公布細節。

工程教訓不在「具體錯哪裡」，而在「為什麼壞掉的 RRSIG 能順著發布管道走到 public secondary」。閉環應該是：sign → push to internal validator → real query → PASS 才 push public。這層 self-validation 在 DENIC 的 pipeline 裡或缺失、或被某種 path 繞過。

有效的 pre-publish validation 不是「跑一個 BIND 對自家 RRSIG 驗證一次」這麼簡單。它必須用 root 真實 trust anchor 從上而下完整跑一次解析，模擬 fresh resolver（沒有 cache、沒有 trust shortcut），對 zone 內代表性的 RRset 全部驗一遍——DNSKEY、各 DS、各 NS、NSEC3 鏈、wildcard、否定回應。這樣才能 catch「NSEC3 鏈計算 bug」「特定字元組合的 hash 邊界」等非典型失敗。對 TLD 級 zone operator，這層 validation 應該是強制 pre-deploy gate。

stale-serve 與 NTA——兩條延長線怎麼撐到 22:17

嚴格按規範，19:30 UTC 之後德國網際網路應該完全停擺三小時。實際沒有——兩個「規範邊緣」的工程實踐救了場：1.1.1.1 的 serve-stale 撐住已快取紀錄，全球 resolver 操作者用 NTA 在第一個小時內繞過 .de 的 DNSSEC 檢查。

機制	觸發條件	這次事件覆蓋什麼	代價
serve-stale RFC 8767	權威伺服器無回應或持續驗證失敗時，自動繼續服務 cache 內已過期紀錄。	所有 cache 裡「最近被查過」的 .de 名字——大型熱門域名（spiegel.de、db.de、各大銀行）保持可用。隨時間衰退。	使用者拿到的可能是過期 IP（指向已下線的伺服器），但 stale window 通常 ≤ 24h。
NTA RFC 7646	Resolver 操作者人為決策，對特定 zone 暫時關閉 DNSSEC 驗證。生命週期通常 6h，到期自動失效。	掛 NTA 的 resolver 對 .de 的所有查詢恢復成 NOERROR——包含 cache miss 的新查詢、否定回應。	NTA 期間 DNSSEC 安全承諾歸零，攻擊者可在 .de 上 spoof 紀錄而不被察覺。
EDE RFC 8914	Resolver 在 SERVFAIL 等回應中附帶結構化錯誤碼，自動產生。	讓下游能讀到「EDE 6 (DNSSEC Bogus)」並關聯到具體 RRset，讓事故 IR 能在分鐘級內定位根因。	無安全代價；但 1.1.1.1 這次誤碼成 EDE 22，誤導了下游 fallback 判斷。
DNS-OARC 非正式	DNS operator 加入 Mattermost / mailing list；事故時自發協調。	事故第一小時內，全球 resolver 操作者交叉確認 bogus 來源、互相通報「我也上 NTA 了」。	無正式 SLA、無單一指揮；依賴關鍵人物在線。但事實上是 DNS 生態最重要的 IR channel。
resolver override vendor-specific	大型公開 resolver（Cloudflare 1.1.1.1）內部部署的客製規則。功能上等價於 NTA。	Cloudflare 在 22:17 UTC 用這個機制把 .de 標為 insecure，比一般 NTA 晚 ~1.5 小時——反映大型 resolver 的決策審慎度。	同 NTA。Cloudflare 內部說法：「There is no user of 1.1.1.1 resolving a .de name right now who would prefer a SERVFAIL over an unvalidated response.」

點欄位標頭可排序。「機制」一欄按 RFC 編號／類別分組——可以排序看「哪些是自動的、哪些需要人為介入」。

Serve-stale (RFC 8767) 是 2020 年標準化的 recursive resolver 行為：權威無回應或驗證持續失敗時，繼續服務 cache 裡已過期紀錄。1.1.1.1 預設啟用。19:30 後「最近被查過一次」的 spiegel.de、db.de 仍能解析；Cloudflare 圖顯示 NOERROR 比例「remained relatively stable」，那條曲線就是 serve-stale 撐的。但 cache 沒有的紀錄救不了——「今天第一次查」的 .de 名字直接 SERVFAIL，且 stale 紀錄會逐步落出 window，SERVFAIL 比例三小時內持續攀升。

下方滑桿讓你拖 stale-serve window 設定（RFC 8767 的 serve-expired-ttl），看 0–180 分鐘外溢期間 cache hit 比例怎麼衰退——baseline 是「不開 stale-serve、純靠 native TTL」的對照曲線。

stale window = 24 h

有 stale-serve（依 window 設定） 無 stale-serve（純 native TTL 5 min）

另一條延長線是 NTA。RFC 7646 的 negative trust anchor 是 operational override：對特定 zone 暫時關閉 DNSSEC 驗證，相當於告訴 validator「這 zone 當 insecure」。代價：NTA 生效期間，攻擊者在 .de 上 spoof 紀錄 validator 不會發現——用安全性換可用性。

# Unbound 範例：對 .de 暫時掛 NTA
domain-insecure: "de."
# BIND 範例：
rndc nta -lifetime 6h de.
# Knot Resolver 範例：
trust_anchors.set_insecure({ 'de.' })

NTA 的 lifetime 必有上限——RFC 7646 建議 24 小時，多數實作預設 6 小時。NTA 是緊急止血，不該變成永久 workaround；zone 沒修好就強制 operator 主動續期。

讓 NTA 有效的是 DNS-OARC 這個業界協調管道。OARC Mattermost 從 19:30 後幾分鐘就有人 cross-check：「我也看到 .de 變 bogus」、「keytag 33834 的 RRSIG 對不上 DNSKEY」、「我準備上 NTA 了」。Cloudflare 事後寫：「Resolver operators across the Internet independently applied Negative Trust Anchors within an hour, restoring resolution.」沒有單一指揮，但事實上的協調發生在那個聊天室裡。

Cloudflare 22:17 UTC 才部署正式 override，比一般操作者晚——反映大型公開 resolver 的決策審慎度（停 DNSSEC 是有政策意涵的動作），也反映 stale-serve 把痛點壓得夠低，讓 Cloudflare 有空間先確認 DENIC 狀態再決定行動。22:30 前後 DENIC 修正簽章；NTA 與 override 在驗證恢復後陸續撤掉。

事後檢討——EDE 的可觀測性、rollover 的可逆性、NTA 的剛需化

DENIC 官方說法很短：「The outage is linked to a routine, scheduled key rollover. During this process, non-validatable signatures were generated and distributed.」並暫停後續 KSK rollover 直到根因清楚。對社群來說這意味著 .de 在可見未來會繼續使用同一把 KSK——延長 key 暴露時間，但避免在根因未明前再踩一次。

Cloudflare 點名自己一個缺陷：1.1.1.1 對部分查詢誤回 EDE 22 (No Reachable Authority) 而非正確的 EDE 6 (DNSSEC Bogus)。EDE 22 暗示「網路／權威問題」，EDE 6 才點名「密碼學失敗」——誤碼讓客戶端 fallback（例如「換一個 resolver 再試」）做錯誤決策。Cloudflare 描述問題在「The verifier detects a bogus signature it creates the DNSSEC Bogus EDE code, but this is never inserted into the response」——分類對了但沒寫進回應包，是 propagation bug 不是分類 bug。

Cloudflare 承諾改善 DNSSEC 失敗時 EDE 碼的傳播精確度，是這次事件對 1.1.1.1 自身行為的主要改動。對其他 zone 操作者，可學到的有幾項：

• Rollover 的可逆性是一線議題：DENIC 把無效簽章「推出去」之後，要等 TTL 自然過期才能完全撤回。設計 rollover 流程時，「能不能快速撤回上一步」應該與「能不能往前推下一步」一樣被 drill。具體做法是讓上一輪的 RRSIG 保留在生產備援，緊急時 30 秒內能切回。
• Pre-publish 驗證不可省：在簽章被推送到 public secondary 之前，內部 validator 應該對新生成的 RRSIG 做端到端驗證——這次事件的本質是「驗證步驟在發布鏈中遺漏了」。實作上是在 sign → publish 之間插一個 query loop：對自家權威伺服器做正常 query，validator 角色驗證 RRSIG，PASS 才繼續推。
• EDE 是 DNS 可觀測性的剛需：如果中間商 / resolver 不傳遞 EDE 結構化錯誤碼，使用者只看到 SERVFAIL，根本判別不出是 DNSSEC 失敗、權威死掉、還是網路問題。RFC 8914 從可選的 nice-to-have 變成了「事故 IR 必備」。內部 monitoring 應該對 EDE 6 / 7 / 9 / 10 等 DNSSEC 相關碼設專屬告警。
• NTA 是一把雙刃刀：它是事件當下唯一能在分鐘級內全球生效的緩解工具，但它也讓 DNSSEC 的安全承諾在那段時間內歸零。任何 resolver 操作者都應該預先把 NTA 的部署/撤除流程寫進 runbook，包含「最長保留時間」這個自我約束。不要讓 NTA 變成「我們忘了關」的長期狀態。
• DNS-OARC 是 IR channel：對任何運行 recursive resolver 的組織來說，OARC 的 Mattermost 應該是 oncall 預設加入的群組。在事故發生時，你需要的不是「自己看 dashboard」，而是「跟其他 resolver 操作者交叉確認自己看到的不是局部現象」。

The lesson： DNSSEC bogus 是一條沒有妥協的規範線， TLD 級的簽章錯誤會把整棵子樹推下這條線； 真正能在現場救場的， 是把 stale-serve、 NTA、 EDE、 與 DNS-OARC 這類業界協調管道當成 IR 一級工具， 而不是 nice-to-have—— 這次 .de 三小時的代價， 是這套組合確實能撐住的證據， 也是它必須撐住的提醒。