ルートゾーンKSK/ICANN/Mattについて、ここに記述してください。 疑問に思ったことの多くが説明されている。(当初のプランが急ぎすぎだということを除いては） ISC BIND 9.110b3が出たのは約一年前だ。 -- ToshinoriMaeno <> https://lists.dns-oarc.net/pipermail/dns-operations/2017-September/016766.html However, initial research by Verisign and then by ICANN has found a growing number of validators reporting trust anchor configuration to the root servers. Based on data from six root server addresses, approximately 12,000 unique source IP addresses have sent trust anchor configuration reports so far in September 2017. The number reporting is growing and now approaches 1400 unique addresses per day. Significantly, approximately 5% of the total validators and about 6%-8% on any given day report only KSK-2010, the root zone KSK currently signing the root's DNSKEY RRset. These validators would not resolve correctly after the planned root KSK roll. ---- There are various reasons a validator might report only KSK-2010. One reason is an old configuration with a statically configured trust anchor (e.g., BIND's "trusted-key" statement). ICANN has always known that a small percentage of validators would not be ready for the rollover because they had manually configured their trust anchor, and that operators of those validators would need to take action when the root KSK rollover happened. Another reason is a failure to automatically update the trust anchor using the RFC 5011 automated update protocol because of a software defect, operator error or other reason. Based on our research and preliminary investigation, we also believe it is possible that some operators believe that they are ready for the rollover because they configured their validator to use RFC 5011 automated updates, but will not trust KSK-2017 when the rollover happens due to configuration issues or software defects. ---- Given the relatively high percentage of validators with just KSK-2010, ICANN believes it is important to better understand the reasons before proceeding with the root KSK roll. We will soon be publishing the list of resolvers reporting only KSK-2010 and will ask for the operational community's help in identifying, diagnosing and correcting these systems. ---- Throughout the project we have emphasized that the root KSK is being rolled under normal operational conditions and have proceeded cautiously and without haste. The decision to postpone was taken in that spirit of caution because there is no operational pressure to proceed given our continued confidence in the security of KSK-2010. {{{ Matt Larson, VP of Research ICANN Office of the CTO }}}