Skip to main content

Cambio de las claves a la Zona Raíz del Sistema de Nombres de Dominio (DNS)

Changing keys dns root zone 756x503 09may16 es

Garantizar la integridad del alto nivel del DNS a través de mejores prácticas de seguridad

En julio de 2010, la ICANN, Verisign y la NTIA agregaron un nivel de protección a la capa superior del DNS mediante una tecnología conocida como DNSSEC, que significa Extensiones de Seguridad del Sistema de Nombres de Dominio. Esta tecnología fue desarrollada para proteger a los usuarios de internet contra ataques que pueden resultar en el secuestro de nombres de dominio y ciertos tipos de servidores afectados. El uso de las DNSSEC aumenta la garantía de que la información obtenida del DNS no haya sido modificada durante el tránsito desde el origen de datos hasta la máquina mediante la formulación de la pregunta en representación de un usuario – esto se realiza mediante la firma digital y la validación de los datos del DNS. Esta validación depende de un "anclaje de confianza", o clave, que está asociado con la raíz del DNS.

Como sucede con cualquier clave, contraseña o sistema de seguridad, el anclaje de confianza debe ser actualizado de manera regular. Con el fin de mantener las mejores prácticas, el equipo de la ICANN que actúa como la Entidad operadora de las funciones de la IANA, junto con otros socios de gestión de la zona raíz (Verisign que actúa como la entidad encargada del mantenimiento de la Zona Raíz y la Administración Nacional de Telecomunicaciones e Información del Departamento de Comercio de los Estados Unidos (NTIA) que actúa como el administrador de la Zona Raíz), ha trabajado en la preparación del "traspaso" o el cambio del par de claves públicas-privadas criptográficas que es la Clave para la firma de la llave de la zona raíz (KSK), el lado público de lo que se usa como el anclaje de confianza de las DNSSEC. El traspaso de la KSK implica generar un nuevo par de claves y distribuir el componente público a las partes que desarrollan, distribuyen u operan en la validación de resolutores. El traspaso de la KSK puede describirse como cambiar las cerraduras de una casa. En los casos en que los nombres de dominio están firmados con DNSSEC, cada vez que un usuario de Internet intenta conectarse al servidor identificado por un nombre de dominio, se prueba la llave dentro de la cerradura para verificar si los datos asociados con ese nombre de dominio son auténticos. Sin embargo, si se cambia la cerradura pero no se han actualizado las llaves, la puerta no se abrirá, el nombre de dominio no se resolverá y el intento de conexión fallará. El posible impacto del traspaso destaca la necesidad de una distribución amplia y adecuada del anclaje de confianza para la nueva KSK. Para garantizar que la comunidad esté al tanto de las últimas actualizaciones sobre el traspaso de la KSK y el nuevo anclaje de confianza resultante, hemos creado esta página de recursos.

Cuando la comunidad de Internet primero desarrolló las DNSSEC en la raíz, los socios de Gestión de la Zona Raíz en consulta con la comunidad especificaron que "se planificará el traspaso de la KSK a través de una ceremonia de llaves según se requiera, o después de 5 años de funcionamiento". Si bien algunos miembros de la comunidad observaron esto como un plazo de cinco años, el cronograma de traspaso de la KSK debe depender de las realidades operacionales del panorama de Internet. Durante el año pasado más o menos, la transición de la custodia de la IANA ha sido la cuestión enfrentada más pública desde la perspectiva de las comunicaciones, pero se ha seguido trabajando en el traspaso de la KSK en paralelo. En el futuro, para garantizar que la comunidad esté al tanto de todo el trabajo y la debida diligencia en torno de las actividades del traspaso de la KSK, brindaré actualizaciones periódicas sobre nuestro progreso. Además, presidiremos sesiones en las reuniones de la ICANN y otros foros técnicos para brindar información detallada sobre el traspaso de la KSK y las acciones que necesitan realizan las personas implicadas a fin de garantizar que el traspaso de la KSK se realice sin problemas.

En las próximas semanas, brindaremos más detalles sobre el traspaso de la KSK, pero para darle noción del cronograma actual para el traspaso:

  • Octubre de 2016: Comienza el proceso de preparación de llaves nuevas para el traspaso de la KSK
  • Noviembre de 2016: Generación de KSK nueva
  • Julio de 2017: Inserción de KSK nueva
  • Octubre de 2017: Retiro de KSK anterior
  • Enero de 2018: Revocación de KSK anterior
  • Marzo de 2018: Finalización del proceso de traspaso de la KSK

Obviamente este cronograma está sujeto a cambio si las circunstancias justifican: el traspaso de la KSK, como cambiar periódicamente su contraseña, es una mejor práctica, pero debe realizarse con debido cuidado y consideración a fin de garantizar que no ocasione interrupciones al funcionamiento del DNS.

Si está interesado en participar en el traspaso de la KSK, puede unirse a la lista de correo electrónico para discusiones públicas en https://mm.icann.org/listinfo/ksk-rollover o si tiene preguntas, puede enviar un correo electrónico a globalsupport@icann.org cuya línea de asunto sea "Traspaso de la KSK".

Las DNSSEC y el traspaso de la KSK son aportes importantes para lograr un DNS más seguro y sólido. Nos comprometemos a trabajar estrechamente con nuestros socios de Gestión de la Zona Raíz, operadores del DNS y la comunidad de Internet en sí a medida que progresamos con este trabajo esencial durante el transcurso de los próximos dos años. A medida que nosotros - como una comunidad global de internet - preparamos el primer traspaso de la KSK, estamos emocionados por la oportunidad para mejorar aun más la seguridad de la Web y sentar las bases para tareas futuras sobre la evolución de internet.

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