Skip to main content

Actualización sobre el Proyecto de traspaso de KSK de la zona raíz

Esta publicación es la primera de una serie de actualizaciones en curso sobre el estado del proyecto de traspaso de la Clave para la firma de la llave de la zona raíz (KSK). Tenemos la intención de mantener actualizada a la comunidad sobre nuestros esfuerzos para proceder con el traspaso.

El 27 de septiembre de 2017, la organización de la ICANN anunció que posponíamos el traspaso de la KSK de la zona raíz. Más recientemente, el 17 de octubre, publicamos un documento titulado Postergación del Traspaso de KSK de la Zona Raíz [PDF, 173 KB], el cual proporciona más detalles respecto a la información que recibimos sobre la configuración de algunos resolutores que influyeron en la decisión, nuestro análisis y nuestro razonamiento detrás de la postergación.

Tal como lo describimos en ese documento [PDF, 173 KB], las versiones más recientes de resolutores recursivos BIND y Unbound implementan un protocolo definido en el documento RFC 8145 [TXT, 27 KB], Señalización del Conocimiento de Anclaje de Confianza en las Extensiones de Seguridad del DNS (DNSSEC), que permite a un resolutor informar su configuración de anclaje de confianza. Un resolutor que admite esta característica informa sus anclajes de confianza configurados para la zona raíz a los servidores de nombres raíz. El análisis de estos datos del anclaje de confianza informados, en las semanas previas a la fecha de renovación programada previamente del 11 de octubre de 2017, generó la preocupación de que podría haber una población de resolutores no configurados con la KSK-2017 (nuestra taquigrafía para la próxima KSK de la zona raíz) como anclaje de confianza, mayor a la anticipada. Esos resolutores no podrán resolver las consultas del DNS cuando se produzca el traspaso.

El grupo de investigación en la Oficina del Director de Tecnologías (OCTO) analizó el tráfico a los servidores raíz B, D, F y L durante todo el mes de septiembre de 2017 y encontró 11.982 direcciones IP únicas (8.908 IPv4 y 3.078 IPv6) que enviaban información de configuración de anclaje de confianza. De ellos, 620 direcciones informaron que se configuraron sólo con la KSK-2010 (abreviatura de la actual KSK de la zona raíz). Tras un análisis posterior, pudimos eliminar algunos falsos positivos: Direcciones IP que, por diversas razones, no representaban a los resolutores recursivos que realizaban la validación del DNSSEC. Redujimos la lista a 500 direcciones de posibles resolutores recursivos mal configurados cuyos operadores nos gustaría contactar. Tenemos dos motivos principales para querer llegar a ellos: entender el motivo por el cual sus resolutores informan estar sólo configurados con la KSK-2010 y, si corresponde, para ayudarlos a corregir la configuración en pos del traspaso.

Inicialmente habíamos planeado hacer pública esta lista de direcciones para obtener la ayuda de la comunidad. Luego de una reflexión más profunda, nos dimos cuenta de que dicha lista podría sacarse de contexto como un intento de "nombrar y avergonzar" a los operadores con sistemas mal configurados, lo cual no es nuestra intención en absoluto. Hemos decidido hacer un primer intento para contactarnos con los administradores. Dependiendo del resultado, es posible que necesitemos publicar la lista de direcciones cuyos administradores no podamos contactar.

Según los datos de septiembre mencionados anteriormente, el 4,1% de las direcciones IP informan sólo la KSK-2010. (El porcentaje real de todos los resolutores en Internet con sólo la KSK-2010 podría ser mayor, dado que en la actualidad sólo un número muy pequeño informa la configuración del anclaje de confianza). A través de nuestra investigación y mitigación, deseamos hacer una mejora significativa en ese número. Dado que no sabemos a cuántos administradores podremos contactar, no queremos establecer un porcentaje objetivo aún.

Es importante tener en cuenta que el valor representa un porcentaje de resolutores, no de usuarios finales, y el impacto en los usuarios finales es lo más importante. Los criterios establecidos en el plan operativo publicado [PDF, 741 KB] para respaldar el traspaso, en caso de problemas, hacen referencia al efecto sobre los usuarios finales:

La ICANN considerará revertir cualquier paso en el proceso de traspaso de claves si el programa de medición indica que una cantidad considerable de la población estimada de usuarios finales de Internet se ha visto afectada negativamente por el cambio dentro de las 72 horas posteriores a que cada cambio haya sido desplegado en la zona raíz.

Estos criterios se derivaron en parte de las recomendaciones del equipo de diseño del traspaso de la KSK de la zona raíz que la ICANN convocó para ayudar a planificar dicho traspaso, cuyo informe [PDF, 1.2 MB] incluye esta recomendación que también se enfoca en los usuarios finales:

Recomendación 16: Se debería revertir cualquier paso en el proceso de traspaso de claves si el programa de medición indica que un mínimo del 0.5% de la población estimada de usuarios finales de Internet se ha visto negativamente afectada por el cambio dentro de las 72 horas posteriores a que cada cambio se haya implementado en la zona raíz.

A lo largo de este proceso, consideraremos el impacto sobre los usuarios finales como una consideración más importante que el porcentaje absoluto de resolutores que aún informan sólo la KSK-2010. Después de contactar a tantos operadores de resolutores como podamos, intentaremos determinar la cantidad de usuarios finales afectados por los resolutores restantes que aún no informen la KSK-2017. Es difícil determinar el número de usuarios finales que utilizan una resolución en particular, pero tenemos varias ideas y fuentes de datos que ayudarán con esta tarea.

En futuras publicaciones del blog informaremos más sobre estos esfuerzos y otros desarrollos, mientras mantenemos actualizada a la comunidad sobre nuestro progreso.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."