[lacnog] Fwd: [ksk-rollover] Update on root KSK roll project for December 2017
Carlos M. Martinez
carlosm3011 en gmail.com
Lun Dic 18 17:47:33 BRST 2017
vamos a tener que esperar un poquito mas.
> From: Matt Larson <matt.larson en icann.org>
> To: ksk-rollover en icann.org
> Subject: [ksk-rollover] Update on root KSK roll project for December
> Date: Mon, 18 Dec 2017 19:44:17 +0000
> Dear colleagues,
> I just posted an update on the root KSK roll project at
> The text is reproduced below for your convenience and please let me
> offer the customary apology if you receive duplicate postings of this
> message on multiple mailing lists.
> Matt Larson <matt.larson en icann.org>
> VP of Research, Office of the CTO, ICANN
> The ICANN org is today announcing that it will not roll the root zone
> KSK in the first quarter of 2018.
> We have decided that we do not yet have enough information to set a
> specific date for the rollover. We want to make clear, however, that
> the ICANN org is committed to rolling the root zone KSK and we will
> continue to discuss this important process with the community, gather
> their feedback and give all interested parties advance notice of at
> least one calendar quarter when we set the date for the rollover.
> Furthermore, we are soliciting input from the community to help
> determine, if possible, appropriate objective criteria to measure the
> possible negative impact of the root KSK rollover on Internet users,
> and acceptable values for those criteria before a rollover. This is in
> accordance with the bottom-up, multi-stakeholder model that has been
> so successful for ICANN policy development.
> On 27 September 2017, the ICANN org announced it was postponing the
> root zone KSK rollover for at least one quarter, leaving open the
> possibility the root KSK rollover might occur in the first quarter of
> 2018. We have since realized that our analysis and preparation will
> require additional time.
> In a previous post, we described our analysis of recursive resolver
> trust anchor configuration information reported using the protocol
> defined in RFC 8145, Signaling Trust Anchor Knowledge in DNS
> SecurityExtensions (DNSSEC). Our analysis revealed that about 4% of
> the approximately 12,000 DNSSEC-validating resolvers reporting during
> the month of September 2017 were configured with only KSK-2010 (the
> shorthand for the current root KSK) and would have been unable to
> resolve DNS queries after the rollover occurred.
> The ICANN org's decision to postpone the rollover was based on the
> concern that we did not understand why those resolvers were not
> properly configured, and we needed time to investigate.
> Since then, we have attempted to contact the operators of 500
> addresses that had reported a resolver configuration with only
> KSK-2010 instead of the correct configuration of both KSK-2010 and the
> new KSK, KSK-2017. Ideally, that investigation would have revealed a
> set of clear causes for the improper configuration, allowing further
> communication and actions to be targeted at addressing those specific
> issues. But in the end, the analysis was not as conclusive as we would
> have hoped.
> In our initial attempt, we received a response from operators of
> approximately 20% of the 500 addresses. Of those addresses whose
> operators we could contact, 60% came from address ranges known to host
> devices with dynamic addresses, such as routers of home broadband
> users and ephemeral virtual machines, making these resolvers extremely
> difficult (if not impossible) to track down. About 25% of the
> addresses corresponded to a resolver forwarding on behalf of another
> resolver that was reporting only KSK-2010. Since the address of the
> device reporting the incorrect configuration was not the actual source
> resolver, it is extremely difficult (if not impossible) to identify
> the true source address of the resolver that was reporting only
> To proceed with the root KSK rollover, the ICANN org must have
> confidence that the rollover will not have an unacceptable negative
> impact on Internet users. The challenge we have encountered since we
> began to analyze the RFC 8145 trust anchor configuration reports from
> resolvers is assessing the impact on users.
> We can make a number of assumptions: for example, it is unlikely that
> a recursive resolver running at a dynamic address could support a
> large number of users since it does not offer a stable address for any
> devices to send queries to for resolution. But ultimately, determining
> potential user impact based on the data available to us is difficult
> and we are therefore soliciting the community's input.
> Input and discussion on acceptable criteria for proceeding with the
> KSK roll will take place on an existing email list that is already
> being used for discussion of the root KSK rollover. We encourage
> anyone interested in contributing to join the mailing list by visiting
> The ICANN org will monitor this mailing list and beginning on 15
> January 2018, we will develop a draft plan for proceeding with the
> root KSK roll based on the input received and discussion on the
> mailing list. The plan will be published by 31 January 2018 and
> undergo a formal ICANN public comment process to gather further input.
> We will hold a session at ICANN61 in San Juan, Puerto Rico, to discuss
> the plan and hear from the community in person. Our intent is to have
> a revised plan available for community review and public comment prior
> to ICANN62 in Panama City, Panama, with a final plan published soon
> Throughout the process we'll continue to keep the community updated on
> the root KSK rollover project's progress.
> ksk-rollover mailing list
> ksk-rollover en icann.org
Más información sobre la lista de distribución LACNOG