DNS驗證用的頂級DNSSEC根金鑰10月11日首次更換，紅帽提醒：一年前封裝的VM記得要更新金鑰

自2010年7月15日部署的DNS頂級DNSSEC根金鑰，將在10月11日進行更換，紅帽提醒，多數情況可順利轉換，但封裝超過一年，又曾啟用DNSSEC的VM或容器映像檔，都得記得更新金鑰，否則恐導致錯誤。

DNSSEC是一種防止DNS欺騙（Spoofing）的數位簽章系統，由網際網路工程任務小組（Internet Engineering Task Force，IETF）在1999年提出，到2005年才逐漸成熟的DNS解析技術，除了最基本的DNS系統外，DNSSEC還加上了數位簽章機制，以驗證DNS伺服器的解析結果。使用DNSSEC系統，讓DNS解析的來源變得不重要，因為DNS解析器或應用程式可以驗證DNSSEC簽章以確保DNS資料不被篡改。

而DNS是階層架構，也就是說父區域用簽章委派（Delegation of Signing，DS）的紀錄，來保證子區域使用的加密金鑰，而階層架構的頂端則是DNSSEC根金鑰，這個金鑰首次在2010年7月15日部署，計畫將於2018年10月11日16:00 UTC更換為全新金鑰，採用舊版映像檔部署的DNS服務，一旦重新從VM映像檔回覆時，可能因金鑰過時而發生問題。紅帽提醒，最好包括伺服器、虛擬機器，甚至是容器映像檔都得要更新。

管理者可以檢查系統是否存在新的DNSSEC根金鑰，當前DNSSEC根金鑰KSK-2010的ID為19036，而新的DNSSEC根金鑰的ID為20326，紅帽表示，這金鑰已經存在超過一年，正常情況下管理者是不需要重新啟動DNS服務的，除非DNS伺服器已經運作超過一年，而且不支援RFC 5011，才需要重新啟動，而符合這些條件的DNS軟體目前就是dnsmasq。

DNS社群、IETF、ICANN（Internet Corporation for Assigned Names and Numbers）、DNS業者以及作業系統業者已經互相協調，讓過程盡可能保持平順。雖然預測上不會有任何問題發生，但是萬一還是有故障狀況出現，管理者可以嘗試重啟DNS伺服器，並且使用dig+dnssec dnskey等指令修正DNSSEC，這樣的流程可以解決大多數的問題，但假設DNS伺服器仍然無法運作，可以先把流量切換到支援DNSSEC公共公共解析器的DNS服務上應急，選項包括Cloudflare的1.1.1.1、Google DNS的8.8.8.8、Quad9的9.9.9.9，還有Verisign的64.6.64.6。

IETF和ICANN正在測量新的DNSSEC根金鑰預採用率，他們使用RFC 8145方法發現，還是有將近5％的DNS未啟用新的DNSSEC根金鑰，紅帽提到，目前不清楚切確發生問題的原因，因為支援RFC 8145的軟體都附帶當前新的DNSSEC根金鑰，他們推斷，系統可能使用新版軟體但是舊的配置檔案，抑或是使用不完整的RFC 5011流程，管理者還需要仔細釐清問題所在。