Cloudflare／官方：根區金鑰十月十一日換鎖——KSK-2024 接管簽署；未更新信任錨點的 DNSSEC 解析器或陸續斷網，香港 ISP 亦須核對

重點摘要

Cloudflare 官方博客十月六日提醒：互聯網根區金鑰簽署金鑰（KSK）定於二零二六年十月十一日進行史上第二次更換，新鑰 KSK-2024（金鑰標籤 38696）將取代自二零一八年十月起簽發根區金鑰集的 KSK-2017（標籤 20326）。已啟用 DNSSEC 驗證、卻尚未把新信任錨點寫進解析器的營運者，轉換後可能在約四十八小時內陸續出現 SERVFAIL，網站與郵件等服務看起來像「斷網」。一般網站營運者及使用 Cloudflare DNS、1.1.1.1 或 Gateway DNS 的用戶無須額外操作；自建或企業遞迴解析器則應立刻核對信任錨點。香港互聯網註冊管理有限公司（HKIRC）早前亦已籲本地 ISP 與快取 DNS 營運者於轉換前完成檢查。本文已對照 Cloudflare 官方文、IANA 根錨點 XML、ICANN 二零二六年五月新聞稿與七月操作指引，以及 HKIRC 新聞稿，來源真實性已驗證。

Cloudflare／官方：根區金鑰十月十一日換鎖——KSK-2024 接管簽署；未更新信任錨點的 DNSSEC 解析器或陸續斷網，香港 ISP 亦須核對

Cloudflare 官方博客十月六日提醒：互聯網根區金鑰簽署金鑰（KSK）定於二零二六年十月十一日進行史上第二次更換，新鑰 KSK-2024（金鑰標籤 38696）將取代自二零一八年十月起簽發根區金鑰集的 KSK-2017（標籤 20326）。已啟用 DNSSEC 驗證、卻尚未把新信任錨點寫進解析器的營運者，轉換後可能在約四十八小時內陸續出現 SERVFAIL，網站與郵件等服務看起來像「斷網」。一般網站營運者及使用 Cloudflare DNS、1.1.1.1 或 Gateway DNS 的用戶無須額外操作；自建或企業遞迴解析器則應立刻核對信任錨點。香港互聯網註冊管理有限公司（HKIRC）早前亦已籲本地 ISP 與快取 DNS 營運者於轉換前完成檢查。本文已對照 Cloudflare 官方文、IANA 根錨點 XML、ICANN 二零二六年五月新聞稿與七月操作指引，以及 HKIRC 新聞稿，來源真實性已驗證。

Cloudflare／官方：根區金鑰十月十一日換鎖——KSK-2024 接管簽署；未更新信任錨點的 DNSSEC 解析器或陸續斷網，香港 ISP 亦須核對

互聯網域名系統安全擴展（DNSSEC）的信任鏈，最終錨固在根區的金鑰簽署金鑰（Key Signing Key，KSK）。十月十一日，這把「總鎖匙」將進行自二零一八年以來的第二次更換：新鑰 KSK-2024 開始簽署根區 DNSKEY 集合，舊鑰 KSK-2017 停止簽署。Cloudflare 十月六日以「The keys to the Internet change on October 11」為題公開操作提醒，並提供以 RFC 8509 信任錨哨兵協定為基礎的線上就緒測試；ICANN／IANA 時間表與本地 HKIRC 業界通告與此一致。本文整理技術機制、誰要行動、香港視角與企業應對，並已核對官方原始文件。

一、核心事件：第二次根區 KSK 換鎖進入倒數

技術細節

根據 IANA「DNSSEC Trust Anchors and Rollovers」頁面與根錨點 XML（data.iana.org/root-anchors/root-anchors.xml），現行狀態大致如下：

  • KSK-2017：金鑰標籤 20326，自二零一八年十月十一日起簽署根區金鑰集，狀態為 Active。
  • KSK-2024：金鑰標籤 38696，於二零二四年四月生成、二零二五年一月十一日預發布進根區，狀態為 Pre-Publication，預計十月十一日接管簽署。
  • 兩者均為 RSA／SHA-256、二千零四十八位元；今次是「換鑰、不換演算法」。ICANN 另有預計約二零二九年的演算法更換（ECDSA）計劃，屬另一獨立日程。

Cloudflare 文中指出：大多數網站營運者無須改設定；若你營運啟用 DNSSEC 驗證的遞迴解析器，則必須確認已信任 KSK-2024，缺則依廠商指引更新信任錨點。使用 Cloudflare 為域名 DNS、或依賴 1.1.1.1 與 Gateway DNS 的用戶，官方稱系統已信任 KSK-2024，無需額外動作。

YSK 新聞於十月七日凌晨（香港時間）以 dig 抽查根區 DNSKEY：同時可見標籤 20326 與 38696 兩把 KSK，而目前簽署根 DNSKEY 集合的仍是 20326——與 IANA／has-the-ksk-rolled.com 所述「尚未切換」一致。對 Cloudflare 1.1.1.1 的 RFC 8509 哨兵查詢結果為：is-ta-38696 回 NOERROR、not-ta-38696 回 SERVFAIL，符合「已信任新鑰」的預期模式。

二、技術原理：信任錨、RFC 5011 與「為什麼網站會突然打不開」

DNSSEC 讓解析器以數碼簽章驗證 DNS 答案未被篡改。對 example.com 一類域名，信任由根 → 頂級域 → 權威區層層嵌套；根沒有「父區」可發布 DS 紀錄，因此解析器必須內建或學會一把根區公開金鑰（或其指紋），稱為信任錨點（trust anchor）。

根區有兩類鑰：

  1. ZSK（Zone Signing Key）：簽署根區一般紀錄（含各 TLD 的 DS）。
  2. KSK：簽署根區 DNSKEY 集合本身。解析器先用信任錨驗證該集合，再用集合中的 ZSK 驗證其他根區紀錄。

Rollover（換鎖）指的是：哪一把 KSK 負責簽署根 DNSKEY 集合發生切換。若解析器只信任舊鑰、卻要驗證新鑰簽出的集合，驗證失敗，常見表現是 SERVFAIL——應用程式看起來像網絡壞了，實際上是「答案驗不過」。

ICANN 二零二六年七月二十七日更新的《What to Expect During the Root KSK Rollover》進一步說明：

  • 根 DNSKEY 的 TTL 約為 四十八小時。轉換當刻舊快取仍可能繼續有效；未準備好的解析器往往在 TTL 過期後的數分鐘至約兩天內陸續「撞牆」。
  • 用戶若配置了多個解析器，其中只要有一個已準備，系統或會改用可用者，但可能變慢。
  • 臨時緩解可考慮暫時關閉 DNSSEC 驗證，或對根區設 negative trust anchor（RFC 7646），再盡快裝上 KSK-2024 並重新啟用驗證——具體步驟須跟從軟件廠商。
  • 根伺服器營運者預期會見到更多對 ./IN/DNSKEY（以及 .net/IN/DS 等）的重試流量，因為失敗答案無法被正確快取。

自動學會新錨的標準機制是 RFC 5011：新 KSK 與舊鑰並存於 DNSKEY，解析器以已信任的舊鑰驗證該集合，並至少觀察約三十天後才把新鑰納入信任錨。KSK-2024 自二零二五年一月起預發布，給出約二十一個月窗口，長於二零一八年首次換鎖。儘管如此，ICANN 博客（二零二六年七月二十七日）仍強調：不要假設自動更新一定成功——軟件升級、機器遷移、信任錨儲存目錄無寫入權限，都可能令「已學會」的狀態丟失。營運者應直接檢查信任錨檔是否含 key tag 38696，例如：

  • ISC BIND：bind.keys
  • Unbound／PowerDNS Recursor：root.key
  • Knot Resolver：root.keys

Cloudflare 這次額外把 RFC 8509 信任錨哨兵實作進 1.1.1.1，並開放 dnstest.dev/ksk-2024 就緒測試，讓用戶在瀏覽器或 dig 上提前問：「我這條解析路徑信不信 38696？」——補上二零一八年換鎖時「無法讓用戶自查」的缺口。

三、日常應用場景

1. 開發者與技術團隊

  • 自建 Unbound／BIND／Knot／PowerDNS 遞迴、容器內嵌 stub、或硬編碼 DoH／私人解析路徑的應用，都應在十月十一日前用哨兵測試或直接讀信任錨檔核對 38696。
  • CI／CD、觀測平台若以「能否解析某域名」作健康檢查，換成「DNSSEC 驗證是否成功」更貼近真實故障面。
  • 記錄並告警 SERVFAIL、根 DNSKEY 抓取失敗，可縮短復原時間。

2. 企業與隱私敏感行業

金融、醫療、政府與大型企業常強制開啟 DNSSEC 驗證，風險反而集中在「驗證開了、錨點舊了」。應把信任錨盤點納入變更窗口：對照廠商版本、確認自動更新權限、在預發布環境做哨兵雙查詢（is-ta-38696／not-ta-38696）。使用托管 DNS／安全網關（如 Cloudflare Gateway）者，仍應向供應商索取書面就緒確認，並抽樣測試內部出口路徑。

3. 一般用戶

家用路由器若只轉發至電訊商 DNS、且電訊商已就緒，多數人不會察覺。若自行改用公共 DNS、安裝「安全 DNS」外掛，或 VPN 劫持解析，則瀏覽器測試頁反映的是該路徑而非系統預設，應分開核對。

4. 香港與亞洲市場視角

HKIRC 於二零二六年九月十日以中文新聞稿提醒業界：ICANN 將更換根區域加密金鑰，並呼籲網絡服務供應商、快取 DNS 營運機構及技術團隊檢查信任錨點、軟件版本與自動更新機制，於轉換前完成測試與持續監察。稿件以「十月十二日」表述轉換日期，而 IANA／ICANN／Cloudflare 官方時間表均寫 十月十一日；兩者指的是同一次換鎖，實際切換時刻以 IANA 公布為準，本地營運者宜以較早的十月十一日作為完成檢查的限期。HKIRC 稱自身早於二零二四年已完成新 KSK 相關更新，並籲 ISP 與 caching DNS 營運者避免轉換後服務中斷——對香港電訊商、數據中心、企業自建遞迴與跨境 SD-WAN 出口皆有直接操作意義。

四、專業評價與潛在考量

優勢

  • 定期換鎖限制單一私鑰長期暴露，並演練全球信任錨分發、驗證與退役流程，為日後後量子或演算法遷移鋪路。
  • 約二十一個月預發布、ICANN 多語指引、Cloudflare 哨兵測試與 HKIRC 本地通告，構成可核對的「官方—基礎設施商—本地註冊局」資訊鏈。
  • ICANN 指匯報解析器對 KSK-2024 的採納曲線接近二零一八年成功換鎖，逾九成五匯報樣本已識別並採納新鑰——對多數用戶屬低感事件。

需要留意的地方

  • 剩餘風險集中在長壽命、手動錨點、權限錯誤、嵌入式／容器內解析器；故障表現分散且可能延遲出現，排障成本高。
  • 演算法仍為 RSA；後量子（例如 Cloudflare 提及 1.1.1.1 已可驗證 ML-DSA-44）要等各層域名與根區全面採用後，信任鏈才算端到端抗量子。
  • 舊鑰撤銷、自根區移除與銷毀私鑰屬二零二七年階段工作，與十月十一日「換成新鑰簽署」是不同步驟，勿混為一談。

結語

十月十一日的根區 KSK 換鎖，不是「又一次抽象資安新聞」，而是全球 DNSSEC 信任起點的排程維護。對已就緒的公共解析與托管 DNS 用戶，事件應近乎無感；對仍只信 KSK-2017 的自建驗證解析器，則可能在 TTL 窗口內演變成大面積「打不開網」的假性斷線。建議香港企業與服務供應商本週內完成信任錨盤點與哨兵抽測，並把結果寫進變更紀錄。

若貴司正檢視香港站點的 DNS、零信任出口與雲端防護架構，可參考 YSK Limited 的雲端遷移與網絡安全（官網刊 99.99% SLA），以及需要遠端維運與主機面板時的遠端開發者外判方案（方案所含美國 VPS 預裝 YSK Server v1.1.27）。

參考來源

延伸閱讀 · 相關服務與產品

相關文章