根 DNSSEC 金鑰已輪替：自設 resolver 應檢查 KSK-2024
DNS 根區域已於 10 月 11 日轉用 KSK-2024 為根區域資料簽署。iThome 報道指出，這次是根區域繼 2018 年後再次輪替金鑰；若機構、學校、ISP 或技術用戶營運的 DNS resolver 啟用了 DNSSEC 驗證，卻仍只信任舊有信任錨，查詢有機會以 SERVFAIL 失敗。對最終用戶而言，表面現象可能只是某些網站突然無法開啟，即使網站本身及其伺服器均運作正常。
不過，這不應被理解為一次普遍性斷網風險。iThome 引述 IANA 的說法稱，多數使用者預計不會受影響，原因是新金鑰早已發布，支援 RFC 5011 並正常運作的 resolver 可自行更新信任錨。真正需要優先處理的，是使用自設遞迴 resolver、保留靜態信任錨設定，或長期缺乏維護的環境。對香港網絡管理員來說，重點在於核實自身 DNS 驗證鏈是否仍有效，而非假設所有外部網站都有問題。
一次金鑰更換，為何會影響開網站？
DNS 是把網域名稱轉換為連線所需資料的基礎服務，而根區域處於整個 DNS 階層頂端，提供如 .com、.org 等頂級網域的查詢資訊。DNSSEC 會以數碼簽章保護 DNS 資料來源及完整性，讓 resolver 可檢查回應有否被竄改。iThome 指出，根區域的 Key Signing Key（KSK）是這條信任鏈的起點；resolver 必須預先信任它，才可逐級驗證受 DNSSEC 保護的資料。
這種設計的取捨相當清楚：DNSSEC 為查詢結果增加可驗證性，同時也把信任錨維護變成營運責任。根區域改由新 KSK 簽署後，僅保存舊金鑰的 resolver 便無法驗證新簽章。它通常不會安靜地略過錯誤並繼續回傳資料，而是回報 SERVFAIL。換言之，問題未必在目標網站、瀏覽器或用戶手機，而可能在用戶所依賴的 DNS 驗證 resolver。
根據 iThome 報道，KSK-2024 的金鑰標籤為 38696，原有 KSK-2017 的標籤為 20326。切換後，新金鑰負責簽署根區域的 DNSKEY 記錄集，舊金鑰不再執行該簽署工作。這些編號對一般用戶沒有直接意義，對管理員卻是很實用的核對點：與其只看設定檔是否提及「DNSSEC」或「自動更新」，更應確認目前有效的信任錨確實包含 KSK-2024。
RFC 5011 是自動化機制，不等於毋須監察
iThome 指出，IANA 在 2024 年已發布新信任錨，並在 2025 年 1 月把 KSK-2024 加入根區域，為 resolver 更新預留時間。支援及啟用 RFC 5011 自動更新的 resolver，會在確認新金鑰後更新本地信任錨，管理員毋須在切換日逐台人手更換。這正是今次輪替預計不會波及大部分用戶的技術基礎。
但「支援」與「已成功持續運作」是兩回事。自動更新可能因設定被關閉、儲存狀態無法寫入、設備長期離線，或軟件版本及既有設定過時而失效。從營運角度看，RFC 5011 應視為降低人手維護成本的控制措施，而不是可以完全取消查核的理由。特別是校園、辦公室分支機構、實驗室、家居伺服器和防火牆內置 resolver，往往較容易因更新週期不一致而留下盲點。
對外提供 DNS 的機構亦要分清角色。若只是把查詢轉交給上游服務，而本地沒有進行 DNSSEC 驗證，受影響模式與自行驗證的遞迴 resolver 不同；若內部 resolver 才是驗證決策點，便應優先審核該節點。這是根據 iThome 所述驗證失敗機制作出的營運分析，目的在於避免把排查範圍不必要地擴大至所有網絡設備。
管理員可怎樣核對與排障
ICANN 經 iThome 提醒 DNSSEC 驗證 resolver 的管理員，檢查信任錨是否已包含 KSK-2024；若沒有，便應確認自動更新功能是否正常，或按所用 resolver 軟件供應商的指引更新。實際處理時，可先建立一份受管理 resolver 清單，涵蓋正式環境、備援節點、分支辦公室設備及實驗用途的獨立安裝，避免只檢查中央 DNS 而遺漏真正影響使用者的節點。
建議的核對次序可聚焦在幾項可驗證事項：確認系統是否啟用 DNSSEC 驗證；查看現行信任錨資料有否 KSK-2024 或標籤 38696；檢查 RFC 5011 的更新紀錄、狀態檔及錯誤日誌；再以受 DNSSEC 保護的網域進行受控查詢，觀察是否出現驗證錯誤或 SERVFAIL。若某一網絡內只有部分人無法開啟網站，也應比較他們實際使用的 DNS resolver，這通常比先懷疑網站故障更有效率。
排障時要避免一個常見但代價較高的捷徑：直接關閉 DNSSEC 驗證來恢復服務。這或可暫時縮小問題範圍，卻同時移除原有的資料完整性檢查。較合理的做法，是保留錯誤時間、受影響網域、resolver 日誌及信任錨狀態，先確認是否確為金鑰輪替造成驗證中斷，再依軟件供應商文件修正更新機制或信任錨。對一般家庭用戶，若只在某個 Wi‑Fi、公司或校園網絡遇到個別網站無法開啟，則可把「該網絡的 DNS 解析異常」列作向管理員回報時的線索。
舊金鑰尚未移除，窗口期應用來補課
依 iThome 轉述的 IANA 時程，KSK-2017 仍會留在根區域，預計 2027 年 1 月 11 日撤銷，並在同年 3 月 22 日移除。舊金鑰停止簽署並不代表可無限期依賴它，但其暫時保留為管理員提供了檢視配置與修復例外環境的時間。實務上，這段期間最有價值的工作，是找出未曾自動更新的 resolver、補上監察與變更紀錄，並把下一次信任錨輪替納入日常維運程序。
往後應持續找出仍在使用、但長期未維護的舊式 resolver，並核實其信任錨更新狀態。根 DNSSEC 信任錨輪替屬於少見但影響範圍很深的基礎設施變更；對大多數人它會悄然完成，對負責 DNS 的團隊則是一項提醒：自動化更新需要可觀察、可驗證，才能在關鍵時刻真正可靠。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — DNS根區域時隔8年更換簽章金鑰，未更新信任錨恐使網站無法連線 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
