Skip to main content

Gestión de incidentes de colisiones de nombres

El tema de las colisiones de nombres ha sido objeto de la considerable atención de las comunidades del DNS e Internet en los últimos meses. Una colisión de nombres se produce cuando se intenta resolver un nombre en un espacio de nombres privado (por ejemplo, un dominio de alto nivel no delegado, o un nombre breve y sin cualificaciones) y se obtiene como resultado una consulta del DNS al DNS público y se encuentra un nombre coincidente en el DNS público.

Los incidentes de colisiones de nombres no son nuevos; históricamente, han sido observados e informados como consultas que contienen TLD no delegados a nivel de la raíz del DNS [PDF, 507 KB]. Estos incidentes ahora vuelven a ser el foco de atención porque muchas de las cadenas de caracteres de nuevos TLD solicitadas son idénticas a las etiquetas en los espacios de nombres que se usan en redes privadas.

La ICANN y otras entidades han realizado estudios para evaluar el impacto potencial de esta situación sobre los usuarios de Internet [1 (PDF, 3.34 MB), 2]. A partir de estos estudios, podemos observar síntomasindicativos de consultas de nombres mal direccionadas, identificar las causas y los orígenes aproximados de estas consultas, y sugerir soluciones (medidas de mitigación).

Tratar la causa, y no el síntoma, de las colisiones de nombres

La sabiduría convencional, ya sea aplicada a la medicina o la seguridad de Internet, indica tratar la causa y no el síntoma. El bloqueo o sinkholing de dominios o URL para prevenir que el software malicioso de un dispositivo se comunique con un centro de comando y control de una botnet es un ejemplo del tratamiento de un síntoma [3 (PDF, 386 KB), 4]. Estas contramedidas alivian la situación y reducen el riesgo, pero la infección sigue estando presente, y continúa siendo una amenaza. Identificar los dispositivos infectados, retirar el software malicioso y desmantelar la botnet es un ejemplo del tratamiento de la causa [5]; es de esperar, y se prefiere, que esta solución sea permanente.

En el caso de las colisiones de nombres, bloquear o retrasar la delegación de un TLD solicitado es tratar el síntoma, pero también implica dejar de lado un factor importante: las colisiones de nombres son consultas no intencionales de TLD a nivel de la raíz del DNS público.Son instancias en las cuales los nombres “se filtran” del espacio de nombres privado al cual pertenecen.

El uso de espacios de nombres privados, o nombres breves y sin cualificaciones, constituye la causa principal de las colisiones de nombres. Estos usos tienen diversos orígenes, que incluyen elección de protocolo, conveniencia del usuario, y supuestos de diseño o aplicación. La confusión, la elección o el error de configuración también se suelen citar u observar como las causas de consultas involuntarias a la raíz. Estas causas persisten por una serie de razones. Independientemente de la razón, es probable que muchas organizaciones deseen mitigar las filtraciones de consultas de nombres de los espacios de nombres privados en los que deben estar.

La ICANN está adoptando medidas para aliviar los síntomas de las colisiones de nombres. Estas medidas fueron publicadas en un Plan de gestión de incidentes de colisiones en los nuevos gTLD y su objetivo es permitir que las organizaciones dispongan del tiempo necesario para implementar las siguientes acciones:

  • Investigar sus espacios de nombres internos para identificar si están enviando consultas que incluyen TLD no delegados en la raíz pública del DNS
  • Evaluar si estas consultas representan un riesgo inaceptable para sus organizaciones, y
  • Determinar cómo mitigarán el riesgo

El marco de medidas a ser implementadas por la ICANN y los solicitantes de nuevos TLD son medidas de diagnóstico y contención, pero no se ocupan de la causa subyacente. Ocuparse de la causa es decisión y responsabilidad de las organizaciones que usan nombres privados y/o nombres breves sin cualificación. Este es un hecho que, a menudo, también se pasa por alto en los debates acerca de las colisiones de nombres: solamente las organizaciones que están direccionando erróneamente consultas al DNS público pueden determinar correctamente si están en riesgo, y solamente estas organizaciones pueden implementar medidas de mitigación de riesgo que les resulten satisfactorias.

La ICANN ha consultado a expertos en la materia para confeccionar un informe sobre la mitigación de las causas asociadas al uso de nombres breves sin cualificación. La conclusión y recomendación principal que surge de este informe, titulado Guía para la identificación y mitigación de colisiones de nombres para profesionales de TI [PDF, 492 KB], es la siguiente:

Cuando la causa sea la resolución de nombres breves sin cualificación, la resolución de dominios totalmente cualificados mediante el DNS público es una solución adecuada y recomendable.

En el informe se describen los problemas que las organizaciones pueden enfrentar cuando sus nombres internos se filtran al DNS global, y se recomiendan soluciones prácticas y viables para muchas organizaciones. Asimismo, se analizan los espacios de nombres privados que se desprenden del DNS, los espacios de nombres privados que usan sus propios TLD, y los espacios de nombres privados creados mediante el uso de listas de búsqueda.

En el informe se recomienda que las organizaciones que aún no están usando los FQDN del DNS público debieran considerar la siguiente estrategia. En resumen, el informe les recomienda:

  • Monitorear sus servicios de nombres, compilar una lista de los TLD privados o de los nombres breves sin cualificaciones que usan internamente y comparar la lista que hayan confeccionado con la lista de cadenas de caracteres de los nuevos TLD.
  • Formular un plan para mitigar las causas de las filtraciones; por ejemplo, probablemente necesiten cambiar la raíz de su espacio de nombres privado para usar un nombre que hayan registrado en el DNS global, o bien cambiar los sistemas afectados y usar los FQDN.
  • Preparar a sus usuarios para el cambio inminente, notificándolos con antelación o brindándoles capacitación.
  • Implementar su plan de mitigación.
  • Continuar monitoreando el uso histórico de nombres privados, y el uso nuevo de los FQDN en los servidores de nombres y en el perímetro de su red, y usar estos datos para mitigar las causas que pudieran detectar una vez que hayan comenzado a mitigar las filtraciones.

Las mitigaciones de este tipo son necesarias, pero no son nuevas para los administradores de TI. Al igual que es necesario detectar las PC infectadas en una red periférica y eliminar el software malicioso, también es necesario detectar y eliminar las causas de vulnerabilidades de nombres internos en redes periféricas.  También es importante reconocer que las organizaciones que ya usan los FQDN del DNS público en su red no tendrán que considerar estas medidas. Estas organizaciones no notarán ninguna diferencia en cuanto al uso de nombres del DNS, independientemente de cuáles o cuántos nuevos TLD sean delegados.

Si bien es probable que haya otras soluciones temporarias o improvisadas, la migración al uso de los FQDN representa una ventaja a largo plazo: una vez que hayan implementado esta medida, estarán en condiciones de operar con todas las delegaciones de nuevos TLD.

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