--- id: "name-collision" kind: "glossary-term" title: "colisión de nombres" language: "es" category: "Sistemas alternativos de nombres" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/es/glosario/colision-nombres/" translations: en: "https://tldlog.com/glossary/name-collision/" de: "https://tldlog.com/de/glossar/namenskollision/" fr: "https://tldlog.com/fr/glossaire/collision-noms/" it: "https://tldlog.com/it/glossario/collisione-nomi/" pt-BR: "https://tldlog.com/pt/glossario/colisao-nomes/" ru: "https://tldlog.com/ru/glossariy/kolliziya-imen/" zh-Hans: "https://tldlog.com/zh/cihui/mingcheng-chongtu/" --- # colisión de nombres Problema que surge cuando un nombre de red privada existe también en el DNS público y envía los ordenadores al lugar equivocado. La ronda de 2012 usó la interrupción controlada, un periodo de prueba que avisaba a las redes afectadas. En la Ronda de 2026, el Name Collision Risk Management Framework de la ICANN (marco de gestión del riesgo de colisión) prevé una evaluación inicial, una delegación temporal y soluciones para nombres de alto riesgo. Hay una colisión de nombres cuando un nombre pensado para un sistema de nombres, a menudo la red privada de una empresa, recibe respuesta de otro, normalmente el DNS público. El tráfico puede fallar o llegar a un destino que nadie quería. El riesgo aparece cada vez que se añade un nombre nuevo a Internet, y por eso la ICANN examina cada TLD solicitado. ## Qué es una colisión de nombres La Guía para el Solicitante (AGB) de la Ronda de 2026 la define como un nombre destinado a resolverse en un sistema de nombres que, por error, se resuelve en otro, lo que puede interrumpir o desviar la comunicación. El caso clásico: un usuario quiere llegar a un recurso de una red privada y, sin saberlo, llega al mismo nombre en el DNS público. No afecta solo a los nombres de nivel superior: según la ICANN, puede provocarla cualquier gTLD, ccTLD o nombre de segundo nivel nuevo. El Proyecto de Análisis de Colisiones de Nombres (NCAP) del SSAC recuerda que el problema se conoce desde hace décadas, «posiblemente ya desde finales de los años ochenta». ## Por qué ocurre: nombres privados y nuevos TLD Muchas organizaciones dieron a sus redes internas una terminación que no existía en el DNS público. Las consultas por esos nombres se escapan hacia la raíz pública. Cuando esa misma cadena se delega como nuevo gTLD, las consultas escapadas empiezan a recibir respuestas reales. Las listas de búsqueda agravan el problema: el dispositivo añade a un nombre corto, uno tras otro, los sufijos de una lista hasta que alguno funciona. El NCAP cuenta «quizá una docena o más» de causas de fondo. En la ronda de 2012, de unas 1.400 cadenas solicitadas, tres se consideraron de alto riesgo: .corp, .home y .mail. La ICANN aplazó su delegación indefinidamente en 2014, y el 7 de septiembre de 2024 la Junta Directiva descartó volver a evaluarlas. ## Nombres reservados y de uso especial Dos sistemas distintos mantienen nombres fuera de la raíz. - **El IETF** reserva los nombres de dominio de uso especial según la RFC 6761, en un registro que lleva la IANA. Entre las entradas de nivel superior están .test, .example, .invalid, .localhost, .local, .onion para la red Tor y .alt para sistemas de nombres ajenos al DNS. También figuran algunos nombres bajo .arpa, como home.arpa para redes domésticas. El propio .arpa es un dominio de infraestructura que gestiona la IANA, no un nombre de uso especial en su conjunto. - **La ICANN** mantiene en la AGB una lista de nombres bloqueados. Incluye todos los nombres de uso especial y cadenas como .internal, que la Junta Directiva reservó de forma permanente para uso privado el 29 de julio de 2024, tras el asesoramiento del SSAC. Las cadenas bloqueadas no pueden solicitarse en ninguna ronda. La RFC 8244 (octubre de 2017) señala que ningún proceso formal coordina ambos sistemas y que ninguna de las dos organizaciones puede impedir que un tercero use un nombre sin más. ## Cómo gestiona la ICANN el riesgo de colisión ### La ronda de 2012 Con el marco aprobado el 30 de julio de 2014, cada nuevo registro aplicaba al menos 90 días seguidos de interrupción controlada. Su zona respondía con la dirección 127.0.53.53, que no abre ninguna conexión, y con un registro TXT que decía «Your DNS configuration needs immediate attention» (la configuración de DNS necesita atención inmediata). Más tarde, el NCAP encontró pocos avisos, y solo uno exigió actuar a un registro. ### La Ronda de 2026 El 7 de septiembre de 2024, la Junta Directiva aprobó el Name Collision Risk Management Framework (marco para la gestión de riesgos de colisiones de nombres), que sustituye al de 2014. 1. **Evaluación inicial.** Tras el String Confirmation Day (día de confirmación de cadenas), una evaluación supervisada por el equipo de revisión técnica de la ICANN (TRT, Technical Review Team) examina cada cadena con registros de actividad de los servidores raíz y de los resolutores, entre otros datos. Su informe se somete a comentario público. 2. **Delegación temporal.** Las cadenas que no se consideran de alto riesgo se delegan en servidores de nombres gestionados por la ICANN para medir el tráfico real durante 90 a 365 días (a octubre de 2026). La raíz crece como máximo alrededor de un cinco por ciento al mes, unas 75 delegaciones mensuales al principio (a octubre de 2026). La contratación no empieza hasta que termina este paso. 3. **Cadenas de alto riesgo.** A octubre de 2026, pasan a una lista de cadenas de colisión. En los 90 días siguientes a esa designación (o a la resolución del conflicto de cadenas, si lo hay), el solicitante puede retirar su solicitud y recibir el reembolso íntegro de la tasa de evaluación, o presentar un plan de mitigación (hasta 180 días si lo pide) cuyas acciones duren como máximo dos años. Su revisión tiene una tasa estimada de 100.000 a 150.000 USD. Si el plan no se aprueba, la solicitud se da por terminada, salvo impugnación en 21 días. El reembolso excluye .corp, .home y .mail. En marzo de 2026, tras un periodo de comentario público, la ICANN decidió no aplicar interrupción controlada sobre IPv6, la versión 6 del protocolo de Internet, en la Ronda de 2026. Considera poco probable que las colisiones afecten a un número significativo de redes o usuarios, pero el riesgo sigue existiendo. ## Qué deben hacer los administradores de red La guía de la ICANN para profesionales de TI recomienda: - Tratar 127.0.53.53 en un registro de actividad como aviso de colisión. - Usar nombres de dominio completos (FQDN) en todas partes y dejar de depender de las listas de búsqueda. - Pasar los nombres privados a un subdominio de un dominio registrado y vigilar hasta que los antiguos dejen de usarse. - Sin dominio registrado, limitarse a las opciones reservadas: .internal, home.arpa para redes domésticas o .test para pruebas. - Avisar a la ICANN cuando haya motivos razonables para creer que existe un daño grave y demostrable. Un ejemplo: los portátiles de una empresa tienen corp.example.com en su lista de búsqueda, así que al escribir «intranet» llegan a intranet.corp.example.com, un nombre que controla la empresa. Con una terminación inventada, esas consultas se escaparían a la raíz y, si esa cadena pasara a ser un gTLD en interrupción controlada, los usuarios recibirían 127.0.53.53. ## Fuentes - [New gTLD Program: 2026 Round Applicant Guidebook, Module 7](https://newgtldprogram-2026-agb.icann.org/en/11-module-7-string-and-application-evaluation-procedures.html) - [Name Collision - ICANN](https://www.icann.org/name-collision) - [Guide to Name Collision Identification and Mitigation for IT Professionals](https://www.icann.org/name-collision/guide-for-it-professionals) - [Special-Use Domain Names (IANA registry)](https://www.iana.org/assignments/special-use-domain-names) ## términos relacionados - [Programa de Nuevos gTLD](https://tldlog.com/es/glosario/programa-nuevos-gtld/) - [raíz alternativa](https://tldlog.com/es/glosario/raiz-alternativa/) - [dominio blockchain](https://tldlog.com/es/glosario/dominio-blockchain/)