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流程，管理者还需要仔细厘清问题所在。