自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流程,管理者還需要仔細釐清問題所在。


Advertisement

更多 iThome相關內容