Skip to main content

Plan de gestión de incidentes de colisiones de nuevos gTLD – Preguntas frecuentes

Esta página está disponible en:

Conforme a su misión y valores fundamentales, la ICANN debe preservar y mejorar la estabilidad, confiabilidad y seguridad operativas, y la interoperabilidad global, del sistema de identificadores únicos de Internet (nombres, números IP y parámetros de protocolo). En pos de lograr estos objetivos, y de conformidad con las instrucciones de la Junta Directiva, como también teniendo en cuenta los consejos del Comité Asesor de Seguridad y Estabilidad, la ICANN encomendó un estudio de los impactos potenciales de las cadenas de caracteres de nuevos gTLD que se han solicitado. El estudio tuvo por objeto considerar si podrían producirse colisiones de nombres entre las cadenas de caracteres de nuevos gTLD solicitadas y los nombres de dominio que puedan estar siendo utilizados en espacios de nombres privados ("TLD no delegados"). Otro de los objetivos del estudio era analizar la posibilidad de incidentes de colisiones de nombres que surgieran del uso de nombres internos para los cuales se hayan emitido certificados digitales X.509.

Una colisión de nombres se produce cuando, sin saberlo, los usuarios acceden a un nombre que ha sido delegado en el DNS público, cuando la intención del usuario era acceder a un recurso identificado por el mismo nombre pero en una red privada. Circunstancias de esta índole, en las cuales los límites administrativos de los espacios de nombres públicos y privados se superponen y la resolución de nombres arroja resultados no deseados, generan preocupación y, en lo posible, deberían evitarse. Sin embargo, los incidentes de colisiones en sí mismos no son alarmantes, sino el hecho de que estas colisiones puedan causar un comportamiento inesperado o un daño, además de la naturaleza del comportamiento inesperado y del daño, y la gravedad de sus consecuencias.

El 5 de agosto del 2013, la ICANN publicó un estudio sobre colisiones de nombres <http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf> [PDF, 3.34 MB] ("el estudio") en el cual se identifican categorías de cadenas de caracteres según las consultas producidas, observadas en las muestras de registro del servidor raíz obtenidas de la iniciativa del DNS-OARC denominada "Un día en la vida de Internet" (DITL). El estudio se basó en los siguientes aportes: 1) muestras de solicitudes al DNS transmitidas a los servidores raíz (tomadas de la iniciativa DITL), complementadas con 2) información de las autoridades de certificación acerca de la emisión de certificados de nombre internos (por ejemplo, certificados TLS/SSL para nombres no delegados). En la sección 3.4 del estudio figura una descripción completa de la metodología aplicada.

En el estudio también se incluyeron opciones de mitigación de riesgos; sin embargo, no se formularon recomendaciones específicas para cada una de las categorías. Sobre la base del estudio, entre el 5 de agosto y el 17 de septiembre del 2013, el personal de la ICANN publicó para comentario público una propuesta para la gestión del riesgo de colisiones de nombres f<http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf> [PDF, 166 KB].

El 7 de octubre del 2013, el Comité para el Programa de Nuevos gTLD de la Junta Directiva de la ICANN adoptó una propuesta revisada <http://www.icann.org/es/groups/board/documents/resolutions-new-gtld-07oct13-es.htm#1.a> en la cual se describe un plan para gestionar incidentes de colisiones de nombres entre los nuevos gTLD y los usos privados ya existentes de las mismas cadenas de caracteres.

A continuación, se presentan las preguntas frecuentes acerca del plan, junto con las respuestas de la ICANN.

  1. ¿Cómo compiló la ICANN la lista de Nombres de Dominio de Segundo Nivel (SLD) a ser bloqueados de la Vía de Delegación Alternativa?

    La lista de los SLD a ser bloqueados dentro de cada TLD está formada por los SLD consultados dentro del TLD durante los muestreos de DITL del 2006 al 2013, y los conjuntos de datos correspondientes a la implementación de DNSSEC en el 2010.

  2. ¿Qué criterios se aplicaron para determinar que un gTLD no es elegible para la Vía de Delegación Alternativa?

    Fueron considerados inelegibles los nuevos gTLD que tuvieron un comportamiento atípico en cuanto a las incorporaciones a su lista de SLD consultados de un año a otro. Es decir, la ICANN considera que un nuevo TLD es elegible para la Vía de Delegación Alternativa cuando la lista de los SLD cambia con frecuencia y en gran medida.

    Las fuentes de datos utilizados para recopilar las listas de variaciones en los SLD son los registros anuales de datos de consultas al DNS entre el 2006 y el 2012. El conjunto de datos del 2013 no fue incluido, ya que las cadenas de caracteres ya eran conocidas en ese momento (y efectuar diferentes actividades y estudios acerca de las cadenas de caracteres conocidas podría sesgar el análisis). En el caso de estas cadenas de caracteres, el incremento de los SLD consultados año tras año es un comportamiento atípico en comparación con la población de gTLD propuestos en: (a) al menos una de las comparaciones entre un año y otro, y (b) el año 2012 (indicio de rotación).

    Por ejemplo, un TLD que muestra un comportamiento atípico solamente en las comparaciones correspondientes a 2006-2007 seguirá siendo elegible. Sin embargo, un TLD con un comportamiento atípico en las comparaciones correspondientes a 2009-2010 y 2011-2012 no será elegible para la Vía de Delegación Alternativa.

  3. ¿La lista de nombres de dominio de segundo nivel (SLD) bloqueados será modificada como resultado del uso de otros conjuntos de datos para trabajar en el Marco Gestión de Incidentes de Colisiones de Nombres?

    No hay planes de modificar la lista de los SLD bloqueados para los nuevos gTLD como resultado del desarrollo del Marco. Sin embargo, si hubiera un nuevo descubrimiento durante el desarrollo del Marco, será tenido en consideración.

  4. ¿Está disponible el código fuente para la creación de las listas de bloqueo?

    El proceso para crear una lista de bloqueo está explicado en detalle en cada uno de los informes de la Vía de Delegación Alternativa para cada nuevo gTLD que haya firmado un acuerdo y que sea considerado elegible. En el siguiente enlace se puede consultar un ejemplo: http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm.

    El código utilizado para crear las listas se basa en el código publicado en https://github.com/JASdevteam/dns-oarc.

  5. ¿Cuánto tiempo deberían permanecer bloqueados los SLD que figuran en la lista de bloqueo?

    El bloqueo debería permanecer vigente hasta que se hayan aplicado las medidas de mitigación descriptas en la evaluación de colisión de nombre pertinente.

  6. Si para un TLD en particular figura el "nic" del SLD en los datos de DITL (indicando que podría haber una colisión de nombres), ¿por qué se permite el "nic" en el gTLD, y por qué este riesgo es más aceptable que el riesgo de cualquier otra colisión de nombres?

    El único nombre que debe utilizarse por contrato es "whois.nic.<tld>", a los efectos de ofrecer el servicio de registro de WHOIS, es decir, "whois.nic.<tld>". Al ponderar el riesgo de usar este nombre con la facilidad de uso que implica tener el servicio de WHOIS disponible en una ubicación conocida, la ICANN decidió no incluir "nic" en la lista de los SLD a ser bloqueados para cualquier nuevo gTLD. Sin embargo, hay un mecanismo de respuesta ante colisiones de nombres <http://www.icann.org/es/help/name-collision> al cual toda parte afectada puede recurrir para informar un daño significativo causado por ese nombre de dominio. Asimismo, hay que tener presente que el nombre se encuentra disponible únicamente para el operador del registro, lo cual significa que el registro tiene el control total del SLD.

  7. ¿La ICANN actualizará la lista de los SLD bloqueados para incluir el año en el que fueron consultados los nombres?

    La ICANN no tiene planes de actualizar la lista de los SLD bloqueados para agregar el año en el que fueron consultados los SLD. Sin embargo, si la comunidad estuviera interesada, la ICANN considerará agregar estos datos cuando los recursos se encuentren disponibles.

  8. ¿Cuál debería ser el curso de acción a seguir cuando se desbloquean los nombres que figuran en la lista de bloqueo de los SLD respecto del período pre-registro y los reclamos ante el Centro de Información y Protección de Marcas Comerciales (TMCH)?

    Los nombres en la lista de bloqueo correspondiente a un TLD deben ser incluidos en el período pre-registro y en los reclamos, conforme a las políticas usuales del registro, pero no pueden ser activados hasta que se hayan implementado las medidas de mitigación. Si un operador de registro asigna nombres de la lista de bloqueo de SLD durante los períodos pre-registro o de reclamos, debe informarle al registratario que el nombre no puede ser activado, y quizás nunca pueda serlo, conforme a la Evaluación de Incidentes de Colisiones de Nombres del TLD.

    Esta es una aclaración de la redacción de la sección 3.2 del Plan de Gestión de Incidentes de Colisiones de Nombres. El objetivo de la lista de bloqueo es frenar el comportamiento antes de que se delegue un nuevo gTLD (es decir, una respuesta NXDOMAIN en el DNS); este resultado se logra al no activar los nombres en la lista, sin importar su asignación.

  9. ¿Qué constituye un daño que amerite la desactivación de un nombre de dominio de segundo nivel que ocasione colisiones?

    Es posible que las incidencias de colisiones de nombres de ciertos nombres de segundo nivel que no figuraban en el conjunto de datos usado para confeccionar la lista de bloqueo de SLD puedan surgir una vez que un gTLD solicitado comience a funcionar. Para mitigar este riesgo, la ICANN ha implementado un proceso que permite que una parte afectada informe esta situación y solicite el bloqueo temporario del nombre de dominio recientemente activado que cause un daño demostradamente grave como consecuencia de la colisión de nombres.

    La ICANN será el único punto de contacto inicial para la presentación de estos informes, y coordinará la notificación con el operador del registro pertinente para garantizar que se adopten acciones expeditivas respecto de la situación informada. La ICANN realizará la evaluación inicial del daño caso por caso hasta que se definan criterios uniformes como resultado del trabajo para desarrollar el Marco.

  10. ¿Habrá un portal con información sobre las colisiones de nombres?

    La ICANN tiene la intención de que haya un portal con información sobre este tema.

  11. ¿Los distintos tipos de delegaciones de prueba están dentro del alcance del Marco de Gestión de Incidentes de Colisiones de Nombres?

    Si, tanto las delegaciones de prueba a nivel de los TLD (para los TLD que no son elegibles para la Vía de Delegación Alternativa) como en el segundo nivel para los SLD dentro de todos los nuevos gTLD, serán tenidas en cuenta durante el desarrollo del Marco. En el caso de que se las adopte, se espera que el Marco especifique la delegación de prueba para cada tipo de colisión en particular.

    Además, durante su reunión en Buenos Aires, la Junta Directiva de la ICANN aprobó una resolución en la cual imparte instrucciones al personal de la ICANN para que evalúe las recomendaciones del documento SAC 062 publicado por el SSAC, en el cual se pide explícitamente que la ICANN considere las delegaciones de prueba.

  12. ¿Cuál es el proceso para considerar el trabajo en curso para desarrollar un Marco de Gestión de Incidentes de Colisiones de Nombres y decidir si se lo adopta o no?

    Se espera que el contratista principal confeccione un Marco preliminar junto con la comunidad, tal como se explica en el siguiente anuncio: <http://www.icann.org/es/news/announcements/announcement-2-11nov13-es.htm>. El Marco preliminar será publicado para comentario público. Una vez finalizado el período de comentario público, los comentarios serán resumidos y el Marco preliminar será actualizado sobre la base de los comentarios recibidos. Finalmente, el Comité para el Programa de Nuevos gTLD de la Junta Directiva considerará la adopción del Marco Final.

  13. ¿En qué instancia se puede participar del desarrollo del Marco de Gestión de Incidencias de Colisiones de Nombres?

    Todos pueden participar en el desarrollo del Marco. El Marco se debatirá mediante una lista pública de correos electrónicos, disponible en: <https://lists.dns-oarc.net/mailman/listinfo/collisions>.

  14. ¿La gestión de colisiones de nombres se extenderá a los ccTLD?

    La cuestión de las colisiones de nombres fue informada por primera vez a la ICANN respecto del programa de nuevos gTLD. En vista de la cantidad esperada de nuevos gTLD, se ha priorizado orientar el trabajo hacia los nuevos gTLD. Tenemos presente que esta no es una cuestión exclusiva de los gTLD; por lo tanto, la ICANN le está planteando esta cuestión al Comité de Riesgo de la Junta Directiva para definir cómo abordar esta situación.


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