Skip to main content

La historia detrás de la decisión de la ICANN de retrasar el Traspaso de KSK

La mayoría ahora conoce la decisión anunciada por la ICANN de posponer el cambio de la clave criptográfica que ayuda a proteger el Sistema de Nombres de Dominio (DNS). Este cambio o "traspaso" estaba originalmente programado para el día 11 de octubre.

Quisiera ofrecer algunos detalles adicionales sobre aquello que consideramos para nuestra decisión de retrasar el traspaso. Se podría decir que es la historia detrás de la historia.

Históricamente, no ha habido ninguna manera de determinar cuáles anclajes de confianza para la validación por Extensiones de Seguridad del DNS (DNSSEC) han sido configurados, dificultando la evaluación del posible impacto del Traspaso de KSK (Clave para la firma de la llave de la zona raíz).  Pero recientemente eso ha cambiado y recibimos algunos datos nuevos que simplemente no podíamos ignorar.

El "conocimiento de la señalización del anclaje de confianza en las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC)" (definido en RFC 8145) es una extensión de protocolo reciente que permite a un validador informar qué anclajes de confianza ha configurado para una zona en los servidores de nombres de esa zona.

El protocolo se finalizó recientemente, en abril de 2017, aunque sólo está soportado por las versiones más recientes de algunos softwares de resolución ampliamente utilizados (BIND 9.10.5b1 y 9.11.0b3 y posteriores y Unbound 1.6.4 y posteriores). Inicialmente, no se esperaba que este protocolo fuese desplegado en forma suficientemente amplia como para proporcionar información útil para el primer Traspaso de KSK de la zona raíz.

Sin embargo, algunas investigaciones muy iniciales (realizadas por Verisign y más tarde por la ICANN) encontraron un número creciente de validadores que informan sobre la configuración del anclaje de confianza a los servidores raíz. Los datos de seis direcciones de servidor raíz indican que, para el mes de septiembre de 2017, aproximadamente 12.000 direcciones IP de origen único enviaron informes de configuración del anclaje de confianza. La cantidad de informes está creciendo y ahora se aproxima a 1.400 direcciones únicas por día.

Esos informes entrantes indican que aproximadamente el 5% de los validadores totales y alrededor del 6%-8% en cualquier día, informan que están utilizando la KSK-2010, que es la KSK de la zona raíz que actualmente firma el RRset (conjunto de registros de recursos) de DNSKEY (Clave del Sistema de Nombres de Dominio) de la raíz. Es importante destacar que estos validadores no se resolverían correctamente después del traspaso de KSK de la zona raíz planificado.

Sobre la base de esta nueva información, decidimos posponer el traspaso de KSK de la zona raíz por al menos un trimestre.

A lo largo del proyecto hemos enfatizado que la KSK de la zona raíz está siendo traspasada bajo condiciones operacionales normales y se ha procedido con cautela y sin prisa. La decisión de posponer el traspaso se tomó con ese espíritu de cautela, dado que no hay ninguna presión operativa para proceder debido a nuestra confianza continua en la seguridad de la clave actual, KSK-2010.

Existen varias razones por las que un validador podría informar sólo la KSK-2010: una configuración antigua con un anclaje de confianza configurado estáticamente (por ejemplo, la declaración "trusted-key" de BIND) o un fallo al actualizar automáticamente el anclaje de confianza utilizando el protocolo de actualización automatizada RFC 5011 debido a un defecto de software, un error del operador u otra razón.

Dado el porcentaje relativamente alto de validadores que sólo cuentan con la KSK-2010, la ICANN considera que es importante entender las razones antes de proceder con el Traspaso de KSK de la zona raíz. Pronto publicaremos la lista de validadores que informan sólo la KSK-2010 y solicitaremos ayuda a la comunidad operativa para identificar, diagnosticar y corregir estos sistemas.

Apreciamos la comprensión de la comunidad y esperamos su ayuda en la recolección de la información necesaria para avanzar con el Traspaso de 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."