Skip to main content

Seguimos adelante con la delegación de los dominios de alto nivel

Por Jeff Moss y John L. Crain

El Comité para el Programa de Nuevos gTLD (NGPC) de la ICANN aprobó una serie de resoluciones autorizándonos a seguir adelante con la expansión del espacio de nombres en Internet mientras mitigamos los problemas que pudieran derivar de esta expansión.

El documento en el que se describe el plan de mitigación se puede consultar aquí [PDF, 841 KB].

No hace falta decir que la ICANN se toma muy en serio su obligación de preservar la seguridad, estabilidad y flexibilidad de los sistemas de identificadores. De hecho, ese aspecto de nuestra misión es lo que primero se lee en los estatutos de la ICANN.

En los últimos meses, surgieron inquietudes acerca de posibles "colisiones" entre algunas de las cadenas de caracteres propuestas para los nuevos TLD y aquellas que se utilizan en espacios de nombres privados. La posibilidad de que ocurran colisiones en el DNS no es ninguna novedad. Las consultas correspondientes a cadenas de caracteres inexistentes son frecuentes en el DNS. Pueden ser el resultado de simples errores tipográficos, de errores de configuración, o del uso histórico o recomendado de ciertos nombres en aplicaciones de intranet. El DNS suele recibir consultas sobre estos nombres, y esta "fuga" de consultas provenientes de espacios privados sucede en volúmenes bastante considerables.

Siguiendo las instrucciones de la Junta Directiva, el personal de la ICANN encomendó un estudio para analizar la extensión del problema de las colisiones de nombres y considerar posibles métodos de mitigación de riesgos.

Tal como lo indicó gran parte de los miembros de la comunidad, resolver los incidentes de colisiones de nombres es mucho más fácil que evaluar el posible impacto de una colisión.

Los datos del DNS recopilados en la raíz y en otros lugares arrojan información interesante sobre las consultas correspondientes a las nuevas cadenas de TLD propuestas. Sin embargo, para evaluar el impacto preciso de estos incidentes, es necesario efectuar otro estudio que nos permita aprender más acerca de la extensión de estos incidentes y determinar cuáles son las cadenas de caracteres que aparecen con mayor frecuencia en las consultas. En definitiva, este nuevo estudio nos permitirá desarrollar estrategias de mitigación específicas.

El concepto base del plan de mitigación de riesgos aprobado por el NGPC consta de cuatro partes:

  • Documentar las colisiones correspondientes a cada TLD e identificadas en los estudios de la base de datos denominada "Un día en la vida de Internet" (DITL), y colocar todas las cadenas de caracteres de Dominios de Segundo Nivel (SLD) que hayan tenido colisiones en una lista de nombres reservados o bloqueados correspondientes a ese TLD en particular. No se permitirá el registro ni la resolución de estas cadenas de caracteres hasta tanto se conozcan los efectos de la colisión específica y se hayan desarrollado e implementado estrategias de mitigación apropiadas.
  • La ICANN desarrollará un proceso mediante el cual los actores afectados podrán informar y solicitar el bloqueo de un SLD que causa un daño demostrable como consecuencia de una colisión de nombres. El propósito de este proceso es mitigar el riesgo de incidentes de colisión que puedan causar un daño y no se hayan detectado en el estudio.
  • La ICANN desarrollará un marco para identificar la probabilidad y la gravedad del daño, para una mejor evaluación de las consecuencias de las colisiones de nombres. Recuerden: daño y riesgo no son lo mismo. Este marco será una herramienta importante no solo para determinar la probabilidad del daño, sino también para detectar técnicas de mitigación. Una vez que se hayan implementado soluciones de mitigación aceptables, se podrá autorizar el retiro de las cadenas de caracteres de la lista de nombres reservados o bloqueados.
  • Por último, promover la concientización y las estrategias de mitigación mediante una campaña de difusión específica servirá para que los actores que pudieran verse afectados identifiquen y gestionen las causas de los incidentes de colisiones que se originen en sus propias redes.

Creemos que estas propuestas nos permiten avanzar en forma equilibrada. El plan reduce al mínimo los riesgos de que las colisiones provoquen daños graves a través de la implementación de medidas que evitan el problema, mediante la mitigación de los riesgos pertinentes y el monitoreo constante de la situación.

Queremos agradecer a quienes presentaron trabajos de investigación, comentarios y devoluciones sobre ejemplos reales de colisiones de nombres. Los esfuerzos de la comunidad demuestran que podemos dejar de lado nuestro interés propio, estudiar un problema complejo y llegar a una solución para alcanzar un objetivo en común: asegurarnos de que el Sistema de Nombres de Dominio continúe prestando servicios a todos los usuarios en forma segura, estable y flexible, mientras sigue creciendo y actualizándose.

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