Cloudflare 於官方部落格發文指出，互聯網 DNS 根於 2026 年 10 月 11 日更換其密鑰簽署金鑰（key-signing key，KSK），這是歷來第二次根區 KSK 輪換。[1][2] 密鑰簽署是 DNSSEC 信任鏈的關鍵，讓 DNS 解析器可用密碼簽署名稱欺騙答案；輪換後，需驗證的解析器必須在切換前信任新密鑰，否則正常網站可能變得無法連上。[1]
新鑰密鑰
文章指出，新密鑰為 KSK-2024（金鑰標籤 38696），會取代 KSK-2017（金鑰標籤 20326），成為根區 DNSKEY 記錄集的簽署者。[1]
DNSSEC 信任從何開始
Cloudflare 解釋，DNS 解析器會為查詢網站與其他服務的位址，DNSSEC 讓解析器檢查 DNS 記錄上的數碼簽名，以確認記錄真實且未被改動；解析器亦需驗證用以驗證簽名的公開金鑰屬於正確網域。以 cloudflare.com 為例，信任鏈由 DNS 根開始，經 .com 再到 cloudflare.com，每個層級都會發布 Delegation Signer（DS）記錄，內含子網域公開金鑰的指紋。[1]
但信任鏈需要起腳：根區之上並無上層確認其金鑰誰持，因此解析器在進行 DNSSEC 檢查時，需先持有一個已信任的根公開金鑰或其指紋，這把鎖稱為信任錨（trust anchor）。[1]
根區的簽署金鑰分兩種工作：區域簽署金鑰（ZSK）簽署根區的 DNS 記錄，包括 .com 等頂層網域的 DS 記錄；密鑰簽署金鑰（KSK）則簽署根區公開發布的公開金鑰清單（DNSKEY 記錄集）。解析器以信任的 KSK 驗證金鑰清單，再以清單中的 ZSK 驗證根區其他記錄。[1]
文章指出，雙公司此前關於 .de 與 .al 輪換失敗的慘文，說明 DNSSEC 檢查失敗的後果：網站運作正常，但仍可能無法連上。根區 KSK 輪換改變的正是這些檢查的起腳；若解析器不信任替換密鑰，其使用者可能無法連上任意頂層網域下的網站。[1]
解析器如何取得新根密鑰
Cloudflare 指出，RFC 5011 讓解析器自動學習新的根信任錨：根區會在新舊 KSK 並存的情況下發布新密鑰，舊 KSK 繼續簽署記錄集，令解析器可用已信任的金鑰驗證載有新密鑰的記錄。在接觸新密鑰成為信任錨之前，解析器需等待至少 30 天，並持續檢查根區已簽署的 DNSKEY 記錄；期內新密鑰必須一直存在於所檢查的記錄中，期滿後，解析器亦需再次成功驗證載有新密鑰的記錄，才接納該密鑰。[1]
文章指出，KSK-2024 自 2025 年 1 月 11 日起已發布於根區 DNSKEY 記錄集，讓設有自動信任錨更新的解析器有時間在 2026 年 10 月 11 日的簽署切換前發現並接納它；每個解析器的等待期由其首次看見並驗證新密鑰時開始計算。[1]
至於 Cloudflare 自家的解析器，該公司早在 2024 年 7 月已把 KSK-2024 直接加入檔案內建的信任錨，與 KSK-2017 並存，令運行更新檔的解析器由啟動即持有新錨。文章解釋，這做法源於首次輪換的經驗：檔案升級及機器之間遷移，曾令部分解析器失去所學到的信任錨狀態；把新錨預設進檔案可避免依賴每個解析器自行保留自動學到的密鑰。[1]
使用者需要做什麼
文章指出，大多數網站營運者毋需為這次輪換作任何改動。如果讀者運營需驗證的 DNSSEC 解析器，請檢查它是否信任新的根密鑰 KSK-2024，如果密鑰缺失，請按檔案商的指示更新信任錨。如果讀者以 Cloudflare 處理網域 DNS，或使用 1.1.1.1 與 Gateway DNS，則毋需採取任何行動，因為該公司系統已信任 KSK-2024。[1]
讀者可事先透過 Cloudflare 的輪換就緒測試（dnstest.dev/ksk-2024/）檢查：該測試向瀏覽器所用的解析器查詢是否信任新密鑰，並採用 RFC 8509《A Root Key Trust Anchor Sentinel for DNSSEC》，該公司已在 1.1.1.1 中於輪換前實作。[1]
參考資料
[1] Cloudflare 官方部落格 — The keys to the Internet change on October 11, 2026. Are you ready?