Skip to main content

El reciente traspaso de la KSK: Resumen y pasos a seguir

Como esperamos que ya haya escuchado, la clave criptográfica principal para la zona raíz del DNS se cambió el 11 de octubre de 2018 en una serie de pasos elaborados y orquestados. El resultado fue sorprendentemente bueno: hubo mucho menos usuarios de Internet que se vieron afectados de forma negativa por el cambio (lo que comúnmente se denomina traspaso) de lo que nadie había previsto. Hay algunas cosas más que deben hacerse para que el proceso del traspaso se considere completo, pero la tarea principal se desarrolló sin problemas.

Un poco de antecedentes: el traspaso se había previsto desde que la zona raíz se firmó por primera vez con DNSSEC en 2010, y la planificación comenzó en serio en diciembre de 2014 cuando la ICANN solicitó voluntarios de la comunidad para participar con el equipo de diseño para desarrollar un plan de traspaso para la clave para la firma de la llave de la zona raíz, o KSK. (La KSK firma las otras claves en la zona, denominadas ZSK). Ese plan se publicó en marzo de 2016 y fue revisado por la comunidad. La organización de la ICANN convirtió el diseño en planes operativos específicos (detallados aquí) y comenzó a actuar a principios de 2017, en particular, con una extensa difusión dirigida a los operadores de resolutores para asegurarse de que estuvieran preparados.

El traspaso se había programado para el 11 de octubre de 2017, pero se postergó un mes antes debido a señales confusas que se observaron en el sistema del servidor raíz. Tras evaluar exhaustivamente esas señales, la ICANN propuso a la comunidad [PDF, 162 KB] que el traspaso se reprogramara para el 11 de octubre de 2018, y la Junta Directiva de la ICANN aprobó la nueva fecha en septiembre de 2018.

Una vez que llegó el 11 de octubre, revisamos los planes operativos paso a paso y, a las 16:00 UTC, la KSK utilizada para firmar la zona raíz se cambió a la nueva clave que se había generado en 2017. Anticipamos que algunos operadores de resolutores no estarían listos, independientemente de cuánto intentamos encontrarlos y comunicarnos con ellos con anticipación, pero a medida que la organización de la ICANN y la comunidad técnica del DNS observaron los informes posteriores a la transferencia, se puso de manifiesto que los operadores de resolutores estaban bien preparados. Incluso ahora, más de dos semanas después del traspaso, nos hemos enterado de que tan solo un puñado de resolutores se vieron afectados de forma negativa y, por lo que sabemos, todos pudieron recuperarse. La ICANN ha oído hablar de solo dos Proveedores de Servicios de Internet (ISP) que sufrieron interrupciones en el momento del traspaso y que podrían haberse visto afectados de forma negativa por el traspaso, pero no hemos podido hablar con las personas allí para determinar la causa raíz de sus problemas.

Todavía quedan algunas cosas por hacer. En primer lugar, la clave antigua se debe revocar formalmente. El 11 de enero de 2019, la clave antigua, que ha estado publicada en la zona raíz desde el principio, se cambiará para indicar que ya no es válida y que los resolutores deben eliminarla de sus configuraciones. Poco después, la ICANN publicará un extenso libro blanco que abarcará todo el proceso de traspaso, incluidas las lecciones aprendidas de la iniciativa. Luego, las diversas comunidades de la ICANN comenzarán a debatir lo que desean ver de futuros traspasos (con qué frecuencia deberían ocurrir, el uso de las claves de "reserva", el tipo de datos que desean ver antes de los traspasos, etc.), todo en base a lo que aprendimos del traspaso y el proceso previo a dicho traspaso.

Si está interesado en mantenerse informado sobre los pasos restantes del traspaso de la KSK raíz y el debate sobre futuros traspasos, suscríbase a la lista de correo electrónico de ksk-rollover.

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