ICANN 宣布，全球 DNS 信任錨換金鑰將於 2026 年 10 月 11 日進入正式切換，KSK-2024 屆時會取代 KSK-2017 為 DNS 根區簽名。這次 DNS 信任錨換金鑰由 ICANN 透過 IANA 職能協調，影響範圍涵蓋全球執行 DNSSEC 驗證的遞歸解析器。企業需要留意的是，APNIC 在 2026 年 4 月的用戶側測量中，較嚴格樣本只有 12% 顯示已信任 KSK-2024。本文從業務連續性、數據落差、香港網絡環境與下一輪演算法升級拆解這次更新的影響。
這次風險不在普通用戶，而在企業解析器是否已準備好
DNSSEC 的作用，是讓解析器確認 DNS 回應未被竄改，避免用戶在輸入正確網址後被導向偽冒網站。IANA 說明，Root KSK 是 DNSSEC 在根區的信任錨，驗證型解析器會依靠它檢查根區資料的可信度。按照 IANA 時間表，KSK-2024 已於 2025 年 1 月 11 日加入 DNS 根區，2026 年 10 月 11 日會開始簽署根區；到那一天，驗證型解析器必須已更新信任錨，否則可能無法繼續驗證根區資料。ICANN 的說法亦很清楚：多數一般用戶不會感覺到改變，但 DNS 軟件營運者必須在切換前確認系統已信任新金鑰。
樂觀與保守數據並存，CIO 不能只看單一指標
目前最容易引起誤解的是「就緒率」。Verisign 工程專家 Duane Wessels 在 2025 年 3 月的觀察指出，在採用 RFC 8145 並有回報的解析器樣本中，91.3% 已顯示信任 KSK-2024。這是一個正面訊號，反映不少解析器已透過 RFC 5011 自動更新或其他方式載入新信任錨。不過，APNIC 首席科學家 Geoff Huston 提醒，這類數據不能直接推算終端用戶覆蓋率，因為一台解析器可能只服務一人，也可能服務數百萬人。APNIC 採用 RFC 8509 Sentinel 觀察用戶側狀態後，2026 年 4 月下旬的嚴格測試只有約 12% 確認信任 KSK-2024，另有 7% 顯示不信任。換言之，這次 DNS 信任錨換金鑰的真正風險，不是技術社群是否知道這件事，而是企業、ISP 與託管環境是否真的完成驗證。
香港企業的關鍵問題，是混合網絡環境容易出現盲點
香港企業大量使用跨境雲端、SaaS、CDN、支付平台和海外託管服務，DNS 解析路徑往往分散在自建機房、雲端 VPC、ISP 與第三方安全服務之間。Internet Society Pulse 2026 數據顯示，香港有 28% DNS 查詢受 DNSSEC 保護，低於亞洲平均 35%；而 .hk 下有 7% 域名受 DNSSEC 保護，高於亞洲平均少於 1% 的水平。這組數字說明，香港並非沒有 DNSSEC 部署，但採用程度並不均勻。對企業決策人而言，最危險的情況是總部、分公司、雲端工作負載和災備環境使用不同解析器，其中部分仍停留在舊版軟件或手動信任錨配置。到了 2026 年 10 月 11 日，故障未必以「安全事故」形式出現，而可能變成網站打不開、API 連線失敗、電郵延遲或內部系統無法解析外部服務。
換鑰只是第一步，根區演算法現代化已經排上日程
這次 DNS 信任錨換金鑰不是演算法更換，而是金鑰值輪換。IANA 資料顯示，KSK-2017 於 2016 年 10 月 27 日生成，並自 2018 年 10 月 11 日起簽署根區；KSK-2024 則於 2024 年 4 月 26 日生成，預計取代 KSK-2017。更長遠看，ICANN 已在 2026 年公開徵詢根區 KSK 演算法輪換方案，方向是由現行 RSA/SHA-256 逐步轉向 ECDSA P-256/SHA-256，並把操作準備度、解析器相容性和未知風險列為徵詢重點。不過，這不應被誤讀為後量子防護；ECDSA P-256 是較現代、效率較高的 DNSSEC 演算法選項，但不是量子安全演算法。這意味企業現在建立 DNSSEC 盤點和變更測試流程，將來面對演算法輪換時會更有把握。
現在處理，是把 10 月的事故變成例行維護
為何 DNS 信任錨換金鑰意味企業必須立即行動？答案很直接：DNS 是網站、電郵、雲端登入、API 和供應鏈系統的共同入口，一旦驗證型解析器未更新，業務部門看到的是服務中斷，而不是一個容易辨認的密碼學問題。記者查核 ICANN、IANA、APNIC、Verisign 及 Internet Society 公開資料後，未見證據顯示一般終端用戶需要自行操作；相反，責任集中在 ISP、企業網絡管理員、雲端平台與 DNS 託管供應商。企業現在應要求供應商證明遞歸解析器已載入 KSK-2024，確認 RFC 5011 自動更新可用，並把 2026 年 10 月 11 日納入變更凍結與監控計劃。真正的問題不是 ICANN 會否換鑰，而是企業是否知道自己的每一條 DNS 解析路徑由誰管理。[最後更新：2026 年 5 月 21 日]
資料來源：ICANN官方新聞稿 · IANA DNSSEC Trust Anchors and Rollovers · APNIC Blog · Verisign Blog · Internet Society Pulse
