Skip to main content

Anunciamos el plan preliminar para continuar con el traspaso de la KSK

Hemos abierto un periodo de comentario público formal dentro de la ICANN para recibir los aportes de la comunidad sobre un plan [PDF, 93 KB] preliminar para continuar con el proyecto del traspaso de la KSK. El periodo para presentar comentarios estará abierto hasta el 1 de abril de 2018 y recibiremos con agrado todo tipo de comentarios.

En el plan, se propone realizar el traspaso de la KSK de la zona raíz el 11 de octubre de 2018 (un año después de la fecha inicialmente prevista), continuar realizando una extensa campaña de difusión para notificar a la mayor cantidad posible de operadores de resolutores, y publicar más observaciones sobre datos del informe sobre anclaje de confianza de la RFC 8145. Pueden consultar el plan para mayor información.

También tenemos pensado realizar una sesión durante la reunión ICANN61 en Puerto Rico para continuar analizando el plan y obtener más comentarios.

El plan concuerda con nuestra publicación de fines de diciembre, en la cual la organización de la ICANN anunció los pasos a seguir para retomar el proyecto del traspaso de la KSK. Describimos nuestros esfuerzos en pos de ubicar a los operadores de resolutores del DNS que no estaban listos para el traspaso.

A través de un protocolo que se describe en la RFC 8145, estos resolutores problemáticos habían informado a los servidores raíz una configuración de anclaje de confianza que solo contaba con la KSK actual (conocida como KSK-2010), pero no con la nueva KSK (conocida como KSK-2017).

En nuestra publicación de diciembre, también detallamos la dificultad que implica contactar a los operadores, y señalamos que, cuando lográbamos contactar a un operador, nos enterábamos de una serie de motivos por los cuales la configuración del resolutor no estaba al día.

En conclusión, estos descubrimientos no nos permitían tener demasiada claridad sobre los pasos a seguir para mitigar las causas específicas, como tampoco nos daban orientación alguna sobre cómo transmitir el mensaje adecuado. Ante esta situación, anunciamos nuestra intención de solicitar aportes de la comunidad respecto de los criterios aceptables para avanzar con el traspaso de la KSK.

A partir de aquella publicación en diciembre, se llevó a cabo un exhaustivo debate entre los miembros interesados dentro de la comunidad. Durante los debates, se acordó que no hay manera de medir con exactitud la cantidad de usuarios que se verían afectados por el traspaso de la KSK, incluso bajo la presunción de poder contar con mejores mediciones para futuros traspasos de la KSK.

El consenso entre quienes participaron en los debates fue que la organización de la ICANN debería seguir adelante con el traspaso de la KSK de la zona raíz en el momento oportuno, y continuar con sus iniciativas de difusión y alcance para informar sobre el traspaso a un público lo más amplio posible.

Esperamos continuar trabajando con la comunidad de la ICANN para llevar a cabo el traspaso de la 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."