Blogs de la ICANN

Los blogs de la ICANN brindan información actualizada sobre actividades de desarrollo de políticas, eventos regionales y demás novedades.

Gestión de incidentes de colisiones de nombres

6 de diciembre de 2013
Por Dave Piscitello

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.

Authors

Dave Piscitello