Skip to main content
Resources

Traspaso de la KSK de la Zona Raíz

Esta página está disponible en:

Root Zone KSK Rollover

Descripción general
Recursos
Participe
Antecedentes
Cronograma preliminar
Planes operativos

Descripción general

La ICANN está planificando llevar a cabo el traspaso de la clave para la firma de la llave (KSK) de las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC) de la Zona Raíz como se requiere en la Declaración de Práctica de DNSSEC de Operador de KSK de la Zona Raíz [TXT, 99 KB].

El traspaso de la KSK significa la generación de un nuevo par de claves cifradas (pública y privada), y la distribución del nuevo componente público a las partes que operan los resolutores de validación, entre ellos: Proveedores de Servicios de Internet; administradores de redes empresariales y otros operadores de resolutores del Sistema de Nombres de Dominio (DNS); desarrolladores de software de resolutores del DNS; integradores de sistemas; y distribuidores de hardware y software que instalan o remiten el "anclaje de confianza" de la raíz. La KSK se utiliza para firmar criptográficamente la Clave para la firma de la llave de la zona raíz (ZSK) que utiliza la entidad encargada del mantenimiento de la Zona Raíz para firmar con DNSSEC la zona raíz del DNS de Internet.

Mantener una KSK actualizada es esencial para garantizar que los nombres de dominio firmados con DNSSEC continúen siendo validados tras el traspaso. La falta de tener la KSK de la zona raíz actualizada implicará que los validadores activados con DNSSEC no podrán verificar que las respuestas del DNS no hayan sido adulteradas y, por ende, resultarán en una respuesta de error a todas las consultas firmadas con DNSSEC.

Los planes de traspaso fueron desarrollados por los Socios en la Gestión de la Zona Raíz; la ICANN en su rol de entidad operadora de las funciones de la IANA, Verisign como la entidad encargada del mantenimiento de la Zona Raíz y la Administración Nacional de Telecomunicaciones e Información (NTIA) del Departamento de Comercio de los Estados Unidos como la entidad administradora de la Zona Raíz. Los planes incorporarán las recomendaciones del Equipo de Diseño del traspaso de la KSK de la Zona Raíz [PDF, 1.01 MB] y adaptarán dichas recomendaciones para cumplir con las limitaciones y los requisitos operativos. Ahora que los planes se han desarrollado de manera colaborativa, los futuros traspasos de la KSK serán realizados por la ICANN de conformidad con dichos planes.

Recursos

Puede encontrar información relacionada y recursos adicionales en:

Participe

Formule una pregunta
Envíe un correo electrónico a globalsupport@icann.org con la línea de asunto "Traspaso de KSK" para presentar una pregunta.

Asista a un evento
Consulte el calendario de eventos para conocer las próximas presentaciones sobre el traspaso de KSK.

Participe en las redes sociales
Use el hashtag #KeyRoll para unirse a la conversación: https://twitter.com/icann

Únase a la lista de discusión sobre el traspaso de la KSK
Suscríbase a la lista de correo electrónico para discusiones públicas sobre temas relacionados: https://mm.icann.org/listinfo/ksk-rollover

Difunda la información
Comparta esta página web con otras personas para ayudarlas a informarse sobre el traspaso de la KSK y cómo pueden verse impactadas.

Antecedentes

En 2009, los socios de RZM colaboraron para implementar DNSSEC en la Zona Raíz, lo que culminó con la primera publicación de una zona raíz firmada y validada en el mes de julio de 2010.

Los requisitos [PDF, 116 KB] para generar y mantener la KSK de la zona raíz, así como las respectivas responsabilidades de cada socio de RZM, fueron especificados por la NTIA. Los procedimientos a partir de los cuales la entidad encargada del mantenimiento de la Zona Raíz (Verisign) y la entidad operadora de las funciones de la IANA (ICANN) cumplen con estos requisitos se publicaron en Declaraciones de Prácticas (DPS) de DNSSEC independientes: DPS de servicio de firma de las DNSSEC de Verisign [PDF, 138 KB] and DPS del Operador de KSK de la Zona Raíz [TXT, 99 KB].

El Contrato de funciones de la IANA entre la NTIA y la ICANN se modificó en julio de 2010 para incorporar las responsabilidades asociadas con la gestión de KSK de la Zona Raíz, así como también aquellos requisitos que se habían aplicado en posteriores revisiones de aquel contrato.

El Acuerdo de Cooperación entre la NTIA y Verisign también se enmendó en julio de 2010 a fin de incluir las responsabilidades de Verisign como operador de ZSK de la Zona Raíz.

El Contrato de Funciones de la IANA requiere que la ICANN lleve a cabo un traspaso de KSK de la Zona Raíz, aunque no determina requisitos detallados ni un cronograma o plan de implementación detallado. La Declaración de Prácticas del operador de KSK de la Zona Raíz contiene esta declaración y establece el requisito de traspaso en la Sección 6.5:

"Toda KSK de la Zona Raíz realizará un traspaso mediante una ceremonia de claves según lo requerido por cronograma o cada cinco años de operación".

Cronograma preliminar

Estas fechas están sujetas a cambio en función de consideraciones operativas.

  • 27 de octubre de 2016: El proceso de traspaso de la KSK comienza cuando se genera la nueva KSK.
  • 11 de julio de 2017: Publicación de la KSK nueva en el DNS.
  • 19 de septiembre de 2017: mayor tamaño de respuesta DNSKEY por parte de servidores de nombres para la zona raíz.
  • 11 de octubre de 2017: La nueva KSK comienza a firmar el conjunto de claves de la zona raíz (el evento de traspaso real).
  • 11 de enero de 2018: Revocación de KSK anterior.
  • 22 de marzo de 2018: último día en que la antigua KSK aparece en la zona raíz.
  • Agosto de 2018: supresión de la antigua llave del equipamiento en ambas instalaciones de la ICANN dedicadas a la administración de claves.

Planes operativos

  1. Plan de implementación operativa de traspaso de la KSK 2017 [PDF, 741 KB] - Describe en detalle los pasos operativos para llevar a cabo el proyecto de traspaso de la KSK de 2017, incluido el cronograma del proceso compuesto por las ocho etapas.
  2. Plan de reversión del traspaso de la KSK 2017 [PDF, 506 KB] - Describe desviaciones previstas del Plan de implementación operativo en función de anomalías originadas durante la ejecución del plan operativo.
  3. Plan de prueba externa del traspaso de la KSK 2017 [PDF, 516 KB] - Abarca la preparación de entornos de prueba operativos, a los cuales el público general de Internet puede acceder, a fin de evaluar si los sistemas externos están listos para participar en el traspaso de la KSK.
  4. Plan de supervisión del traspaso de la KSK 2017 [PDF, 437 KB] - Describe el plan para supervisar los efectos de cambiar el anclaje de confianza para la zona raíz en el tráfico hacia los servidores raíz.
  5. Plan de prueba de sistemas del traspaso de la KSK 2017 [PDF, 519 KB] - Describe las acciones necesarias para evaluar los cambios a la infraestructura de la ICANN que participa en el traspaso de la KSK.
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."