DNS大事件：10月11日更換Root KSK，未更新將無法使用網際網路
內容來自：akamai
連結：https://blogs.akamai.com/sitr/2018/09/root-ksk-roll-replacing-the-root-of-trust-for-the-dns.html
輪換Root KSK：更換DNS的信任根
9月16日，ICANN理事會通過了一項決議，指示ICANN組織按計劃繼續輪換Root KSK，定於2018年10月11日16:00 UTC更換Root KSK。
2018年10月11日，根金鑰簽名金鑰（Root KSK）即將更換――這是歷史上第一次，這是用於驗證所有DNSSEC響應的單一信任根。還沒有了解並開始使用新金鑰的驗證解析系統將把所有響應視作無效，因而導致它們停止回答所有查詢，從而讓使用者無法正常訪問網際網路。
你準備好了嗎？
引言/DNSSEC是什麼？
域名系統安全擴充套件（DNSSEC）於1997年推出，首次描述DNSSEC的RFC2065同年釋出。DNSSEC為域名系統（DNS）的使用者使用公鑰加密來驗證響應提供了一種方法。在1997年到2010年7月1日，DNSSEC被一些DNS授權運營商所使用。然而，當時沒有一個信任錨（trust anchor），這是可用來驗證響應的權威實體。2010年7月1日，網際網路名稱與數字地址分配機構（ICANN）、Verisign以及國家電信和資訊管理局（NTIA）完成了對DNS根區域進行簽名的過程。這樣一來，單個信任根就可以用來驗證所有DNSSEC響應，假設DNS鏈上的每個區域都已簽名。
自2010年7月以來，DNSSEC信任根（又叫根金鑰簽名金鑰，Root KSK）沒有變過。 DNSSEC驗證中其他地方使用的許多金鑰已經輪換――類似網站的TLS證書，這對於任何公鑰系統來說很常見。在引入目前使用的金鑰KSK-2010的前後，負責維護DNS根區域的組織：網際網路號碼分配機構（IANA）編制了《根區域KSK運營商DNSSEC實踐宣告》文件。該文件概述了根區域的DNSSEC操作，呼籲5年後輪換Root KSK。與之相仿，在2013年，ICANN的安全性和穩定性諮詢委員會發布了一份公告，呼籲輪換Root KSK。輪換Root KSK的過程應該在2015年開始，但直到2016年10月才開始。促使KSK-2017建立的Root KSK生成過程開啟了Root KSK的輪換，原計劃在2017年10月完成。
有一種自動方法可以驗證解析系統以瞭解和安裝新的Root KSK（RFC5011）。然而，驗證解析系統不僅需要支援更新方法，還需要能夠觀察金鑰至少30天，並將該金鑰儲存在永久儲存裝置中。在某些情況下，解析系統無法寫入到永久儲存裝置，也無法保留新金鑰。如上所述，不使用新金鑰的驗證遞迴解析系統將停止回答查詢，從而讓使用者無法正常訪問網際網路。由於無法可靠地衡量有多少解析系統沒有安裝新金鑰，因此ICANN理事會作出了決定：推遲部署，以便做好更多的研究和通知工作。延期一年；現在我們離2018年10月11日這個重大日子越來越近了。
諸有關方已認真考慮了輪換Root KSK的計劃，包括ICANN下面的首席技術官辦公室以及安全性和穩定性諮詢委員會（通過ICANN託管的KSK Roll郵件列表）。意見不一，有的強烈支援今年輪換金鑰，有的強烈反對。爭論雙方都發現需要更多的資料、外聯和方法，幫助減小對終端使用者造成的影響。 ICANN理事會正在考慮他們在下一次理事會會議（到時做出要不要搞的決定）之前徵集的意見，會在下週的某個時間告知社群。決定公佈後，我們會更新此文。
會發生什麼？
如果Root KSK輪換按計劃進行，信任錨Root KSK將從2018年10月11日開始由KSK-2010換成KSK-2017。這將導致響應由根DNS域名伺服器來處理，返回現在與新的Root KSK聯絡起來的響應。由於根域名伺服器的響應中設定了48小時的生存時間（TTL），因此一些終端使用者可能會在10月11日到10月13日的某個時間段受到影響。受影響的時間主要取決於解析系統上的快取到期失效的速度多快。受影響的終端使用者可能一開始會遇到主機未找到錯誤或表明DNS解析無法正常工作的其他徵兆；隨著更多快取條目到期失效，故障似乎會擴散到其他域。對於遇到故障的使用者來說，使用ping之類的工具、找到IP地址而不是域名有助於排除常規的連線問題。對於管理員來說，訪問資源時使用IP地址可以用作某些應用的權宜之計，直到解析故障被解決。
ICANN的首席技術官辦公室及其他機構估計，由於此次輪換，Root KSK輪換將給互聯使用者帶來不到1%的拒絕服務（DoS）。這些報告承認，由於根本上無法衡量DNS的某些方面，存在一定程度的不確定性。過去兩年已作出了努力以改進衡量，但新資料不如我們預期的那樣具有結論性。
我如何準備Root KSK輪換？
如果你是終端使用者，就得依賴DNS服務提供商（通常是你的ISP），或公共開放解析系統服務，比如Google DNS（8.8.8.8）、Open DNS（208.67.222.222和208.67.220.220）或Quad 9（9.9.9.9），以便正確處理金鑰輪換。如果使用者使用Akamai的ETP、AnswerX託管平臺以及最新版本的AnswerX（v2017.1或更高版本）或啟用DNSSEC驗證功能的Nominum產品，會發現新的Root KSK信任錨已配置好，輪換髮生時，解析應該會繼續順利進行。
想測試自己會不會受Root KSK輪換的影響，第一步可以嘗試訪問http://dnssec-failed.org。如果你能夠解析並載入網頁，表明你用於測試的那臺計算機未配置驗證解析系統，Root KSK輪換應該對該系統沒有影響。請注意，這僅驗證訪問URL的裝置是不是在使用DNSSEC驗證，物聯網裝置等其他裝置可能使用不同的遞迴解析系統，沒有簡單的方法來測試。
對於使用驗證的解析系統的使用者來說，有一個IETF草案，通常名為KSK Sentinel，它定義了一組特別設計的查詢，終端使用者可以用這些查詢來檢查解析系統是否為Root KSK輪換做好了準備。已設立了網站https://www.ksk-test.net，幫助終端使用者測試解析系統是否驗證DNSSEC、是否支援KSK Sentinel，以及是否已配置好了新的信任錨。KSK Sentinel比較新，僅部署到了少數遞迴解析系統。使用這個方法好不好，就看運氣了，但到目前為止，除了聯絡你的遞迴解析系統運營商外，它是唯一可用來測試遞迴解析系統是否為Root KSK輪換做好準備的方法了。
如果你是遞迴解析系統運營商，ICANN提供的網頁可幫助你逐步檢查及/或更新大量解析系統平臺上的信任錨。運營商可能還應該考慮檢查自己的平臺是否支援RFC5011，這種協議可自動更新和配置新的信任貓。如果這次Root KSK輪換按計劃進行，RFC5011更新將無濟於事，因為該協議需要30天才能完成，因此2018年9月10日是可以啟用該功能的最後一天。
此外，網路運營商應檢查電子郵件，看看有沒有主題行是“關於ASXXXXX中未準備好的DNSSSEC驗證解析系統的重要DNS資訊”的郵件，其中XXXXX換成你的自治系統（AS）編號。這類電子郵件讓運營商對於出現在根域名伺服器的日誌中的解析系統有一番瞭解，這些伺服器對於是否支援新的Root KSK並不確定。一些根域名伺服器處理的請求常常與可能沒有為Root KSK輪換做好準備的驗證解析系統關聯起來，這些伺服器已看到出現在這些報告中的IP地址。收到這些報告的管理員應利用ICANN提供的程式來檢查及/或更新解析系統。由於客戶端可能通過非驗證遞迴解析系統發出同樣的查詢，因此可能會出現誤報。
面對Root KSK輪換，權威域名伺服器的運營商受客戶端使用的遞迴解析系統的支配，這意味著無法通過修改權威服務來糾正解析故障。
宣告：本文來自安全內參，版權歸作者所有。文章內容僅代表作者獨立觀點，不代表安全內參立場，轉載目的在於傳遞更多資訊。如需轉載，請聯絡原作者獲取授權。