Skip to main content

Se prevé un impacto mínimo para el usuario por el traspaso de la clave para la firma de la llave de la zona raíz (KSK)

La organización de la ICANN cree que una actualización del anclaje de confianza de las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC) para el Sistema de Nombres de Dominio (DNS) global el 11 de octubre de 2018 afectará solo a un número muy reducido de usuarios del DNS. La decisión de traspasar la clave para la firma de la llave de la zona raíz (KSK) de la zona raíz se está realizando después de un esfuerzo de difusión significativo y una consideración cuidadosa de todos los datos disponibles.

Desde que la zona raíz del DNS se firmó originalmente en 2010, la Declaración de Políticas y Prácticas de las DNSSEC1 ha establecido la expectativa de que la KSK de la zona raíz cambiará. Afortunadamente, la mayoría de los resolutores de validación que observan una nueva KSK de la zona raíz deberían poder configurarla como un nuevo anclaje de confianza utilizando automáticamente "Actualizaciones automatizadas de anclajes de confianza de seguridad del DNS (DNSSEC)", definidas en RFC50112. Un operador de resolutores también puede actualizar su configuración de anclaje de confianza manualmente si toma conocimiento de que la KSK raíz está cambiando en base a los diversos esfuerzos de difusión de la ICANN.

No existe una forma estandarizada o determinista para medir de forma activa que un resolutor de validación tenga configurado el conjunto correcto de anclajes de confianza. El mejor método actualmente disponible es la "Señalización del conocimiento del anclaje de confianza en las Extensiones de Seguridad del Sistema de Nombres de Dominio" (documentado en RFC 81453) que se publicó en abril de 2017. En ese protocolo, los validadores emiten una consulta del DNS que contiene los identificadores de clave DNSKEY de los anclajes de confianza configurados en el nombre de la consulta. Estas consultas se pueden observar pasivamente en el tráfico en los servidores raíz. En septiembre de 2017, hubo un pequeño grupo de resolutores que utilizaron este protocolo y los anuncios de los anclajes de confianza mostraron un porcentaje más alto de anclajes de confianza mal configurados de lo que inicialmente se había anticipado. Sin embargo, la señal observada en ese momento no se entendía bien y, como resultado, la organización de la ICANN decidió posponer el traspaso de la KSK de la zona raíz para comprender mejor la señal con la ayuda de la comunidad técnica.

La investigación adicional realizada por el equipo de la Oficina del Director de Tecnologías (OCTO) de la organización de la ICANN, entre otros, revelaron preocupaciones con la calidad de los datos del documento RFC 8145. Por ejemplo, una consulta del DNS que indique que la información del anclaje de confianza que se envía a un remitente se trata de la misma forma que cualquier otra consulta y se enviará a un servidor raíz independientemente de si el remitente está validando o no. En un caso, la implementación de un resolutor popular del DNS señaló el anclaje de confianza aunque el resolutor no estaba configurado para validar y, por lo tanto, no tendría el nuevo anclaje de confianza. Esta decisión de implementación se revirtió en una versión posterior del software. En otro caso, una conocida biblioteca de resolutores del DNS señaló el anclaje de confianza pero no tenía un método para actualizar automáticamente su configuración de anclaje de confianza. Como resultado, una implementación única de una popular implementación de VPN de usuario único que utiliza esa biblioteca de resolutores del DNS emitiría la antigua señal de anclaje de confianza de diferentes direcciones fuente con el transcurso del tiempo. Wes Hardaker del Instituto de Ciencias de la Información de la Universidad del Sur de California descubrió este comportamiento y se informó al proveedor que utilizaba la biblioteca y actualizó su software. Este cambio ha reducido significativamente la cantidad de fuentes que informan el antiguo anclaje de confianza.4

Sin embargo, los datos de RFC 8145 solo informan los resolutores; no proporciona una indicación de la cantidad de usuarios finales que dependen de esos resolutores. Para comprender el tamaño de la población de usuarios detrás de la validación de los resolutores, el Registro Regional de Internet para la región de Asia Pacífico (APNIC) utilizó un sistema de medición que utiliza la red de publicidad de Google para consultar el DNS. Mediante el análisis de la intersección de las fuentes de señalización del anclaje de confianza de la ICANN con sus propias fuentes de resolutores y luego extrapolando, APNIC calculó que solo el 0,05 por ciento de los usuarios de Internet se vería afectado negativamente por el traspaso de la KSK raíz.5

En una visión prospectiva, la organización de la ICANN pronto contactará a los 1000 Proveedores de Servicios de Internet (ISP) con el tráfico de resolutores más activo que sugiera que la validación de DNSSEC se ha habilitado para asegurar que tomen conocimiento de que el traspaso de la KSK raíz ocurrirá el 11 de octubre de 2018. Esos ISP también serán encuestados sobre sus planes de preparación para el traspaso, lo que puede ocasionar que los operadores de resolutores tomen más conocimiento sobre el traspaso de la KSK.

Desde el primer anuncio sobre el desarrollo de planes para traspasar el anclaje de confianza en 2015, la organización de la ICANN ha mantenido una campaña de difusión que (hasta la fecha) incluyó casi 100 participaciones de oradores en conferencias internacionales, regionales y nacionales, y más de 150 noticias en la prensa técnica. La organización de la ICANN también ha publicado nueve artículos de blog relacionados con el traspaso del anclaje de confianza y continúa su difusión a los ISP que tienen resolutores de validación en sus redes pero que, a partir de los datos de RFC 8145, no parecen tener configurado el nuevo anclaje de confianza.

Como resultado de estos esfuerzos y de los datos que hemos podido recopilar, la organización de la ICANN ha aumentado la confianza de que el traspaso de la KSK raíz planificado para el 11 de octubre de 2018 tendrá el potencial de afectar únicamente a una pequeña fracción de los usuarios del DNS.

 


1 https://www.iana.org/dnssec/icann-dps.txt

2 https://datatracker.ietf.org/doc/rfc5011/

3 https://datatracker.ietf.org/doc/rfc8145/

4 http://root-trust-anchor-reports.research.icann.org/

5 http://www.potaroo.net/ispcol/2018-04/ksk.pdf [PDF, 184 KB]

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