Skip to main content

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

La organización de la ICANN hoy anunciará que no traspasará la KSK de la zona raíz en el primer trimestre de 2018.

Hemos decidido que aún no tenemos la información suficiente para fijar una fecha específica para el traspaso. Deseamos dejar en claro, no obstante, que la organización de la ICANN está comprometida con el traspaso de la KSK de la zona raíz y seguiremos debatiendo acerca de este proceso importante con la comunidad, recopilando sus aportes, y proporcionaremos a todas las partes interesadas notificación con antelación de al menos un trimestre calendario cuando fijemos la fecha para el traspaso.

Asimismo, estamos solicitando aportes de la comunidad para ayudar a determinar, de ser posible, los criterios objetivos adecuados para medir el posible impacto negativo del traspaso de la KSK de la zona raíz en los usuarios de Internet, y valores aceptables para dichos criterios antes de un traspaso. Esto está en conformidad con el modelo ascendente de múltiples partes interesadas que ha sido tan exitoso para el desarrollo de políticas de la ICANN.

El 27 de septiembre de 2017, la organización de la ICANN anunció que estaba posponiendo el traspaso de la KSK de la zona raíz durante al menos un trimestre, dejando abierta la posibilidad de que el traspaso de la KSK de la zona raíz pueda llevarse a cabo en el primer trimestre de 2018. Nos hemos dado cuenta que nuestro análisis y nuestra preparación requerirán tiempo adicional.

En una publicación anterior, describimos nuestro análisis de la información de configuración de anclaje de confianza de un resolutor recursivo informada mediante el protocolo definido en el documento RFC 8145Señalización del conocimiento de anclaje de confianza en las Extensiones de Seguridad del DNS (DNSSEC). Nuestro análisis reveló que alrededor del 4 % de los aproximadamente 12.000 resolutores de validación de DNSSEC que informaron durante el mes de septiembre de 2017 estaban configurados solo con KSK-2010 (la abreviatura de la KSK de la zona raíz actual) y no hubieran podido resolver consultas del DNS después de realizado el traspaso.

La decisión de la organización de la ICANN de posponer el traspaso se basó en la preocupación de que no entendíamos por qué esos resolutores no estaban configurados adecuadamente y necesitábamos tiempo para investigar.

Desde entonces, hemos intentado contactarnos con los operadores de 500 direcciones que habían informado una configuración de resolutor con solo KSK-2010 en vez de la configuración correcta de KSK-2010 y la nueva KSK, KSK-2017. Idealmente, esa investigación hubiera revelado un conjunto de causas claras de la configuración no adecuada, lo que hubiera permitido orientar más comunicación y acciones hacia el abordaje de esos problemas específicos. Pero finalmente, el análisis no fue tan concluyente como hubiéramos esperado.

En nuestro intento inicial, recibimos una respuesta de operadores de aproximadamente el 20 % de las 500 direcciones. De esas direcciones a cuyos operadores pudimos contactar, el 60 % provenía de rangos de direcciones conocidas para dispositivos host con direcciones dinámicas, tales como enrutadores de usuarios de banda ancha domésticos y máquinas virtuales efímeras, lo que hace que estos resolutores sean extremadamente difíciles (si no imposibles) de rastrear. Alrededor del 25 % de las direcciones correspondía a un resolutor que reenviaba en nombre de otro resolutor que informaba solo KSK-2010. Dado que la dirección del dispositivo que informaba la configuración incorrecta no era el resolutor fuente verdadero, es extremadamente difícil (si no imposible) de identificar la dirección fuente verdadera del resolutor que informaba solo KSK-2010.

Para proceder con el traspaso de la KSK de la zona raíz, la organización de la ICANN debe estar segura de que el traspaso no tendrá un impacto negativo inaceptable en los usuarios de Internet. El desafío que hemos enfrentado desde que comenzamos a analizar los informes de configuración de anclaje de confianza de RFC 8145 de los resolutores es evaluar el impacto en los usuarios.

Podemos realizar diversas suposiciones: por ejemplo, no es probable que un resolutor recursivo que se ejecuta en una dirección dinámica pueda admitir una gran cantidad de usuarios dado que no ofrece una dirección estable para ningún dispositivo al cual enviar consultas para su resolución. Pero, a fin de cuentas, determinar el posible impacto en los usuarios en función de los datos que tenemos disponibles es difícil y, por lo tanto, estamos solicitando aportes de la comunidad.

Los aportes y discusiones sobre los criterios aceptables para proceder con el traspaso de la KSK tendrán lugar en una lista de correo electrónico existente que ya está siendo utilizada para debatir sobre el traspaso de la KSK de la zona raíz. Alentamos a cualquier persona interesada en contribuir a unirse a la lista de correo electrónico visitando la página web aquí.

La organización de la ICANN supervisará esta lista de correo electrónico y, a partir del 15 de enero de 2018, desarrollaremos un plan preliminar para proceder con el traspaso de la KSK de la zona raíz en función de los aportes recibidos y la discusión en la lista de correo electrónico. El plan será publicado para el 31 de enero de 2018 y será sometido a un proceso formal de comentario público de la ICANN para recopilar más aportes. Realizaremos una sesión en ICANN61 en San Juan, Puerto Rico, para debatir el plan y escuchar las opiniones de la comunidad en persona. Nuestro intento es tener un plan revisado disponible para revisión y comentario público de la comunidad antes de ICANN62 en la ciudad de Panamá, Panamá, y publicar un plan final posteriormente.

A lo largo del proceso seguiremos manteniendo informada a la comunidad sobre el progreso del proyecto de traspaso de la KSK de la zona raíz.

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."