Resumen

  • Frenar el abuso de un dominio no cierra necesariamente una investigación de ICANN. La respuesta del registrador también puede necesitar reparación.
  • ICANN declara más de 70 planes completados y un 87,5 % sin señales de recurrencia. Falta conocer cuánto tiempo estuvo a prueba cada uno.

Una prueba que llegaba demasiado tarde

Una denuncia de phishing puede atascarse en una pregunta aparentemente sencilla: ¿qué hace falta demostrar para que alguien actúe? Trustname.com había puesto el listón en la captura o transmisión de credenciales. No bastaba, con ese criterio inicial, con valorar si las pruebas disponibles apuntaban razonablemente a una suplantación destinada a obtenerlas.

ICANN consideró incorrecta esa exigencia. Según su aviso de terminación de la acreditación de Fewmoretaps OU d/b/a Trustname.com, el registrador acabó mitigando el abuso semanas después de los primeros avisos y tras la intervención del organismo. Había actuado, pero tarde.

Y no era la primera reparación prometida. Trustname.com había aplicado medidas en febrero de 2026 y presentado otras en junio y julio. Después llegaron más quejas y notificaciones de incumplimiento. Para ICANN, faltaba demostrar que los cambios servían. El aviso recoge las conclusiones contractuales del organismo sobre ese registrador: no es una sentencia ni permite atribuir la misma conducta a todos los proveedores.

Ahí está el problema que recorre la actualización del 15 de octubre de 2026. Un dominio deja de utilizarse para el abuso denunciado; el equipo que recibe las denuncias puede seguir decidiendo mal. Por eso un expediente puede permanecer abierto durante meses después de la mitigación. Se trata de comprobar la respuesta que encontrará la próxima queja, no solo de dar por atendida la anterior.

El botón de suspensión no lo arregla todo

La rapidez importa, pero suspender cualquier dominio denunciado tampoco sería una buena respuesta. En un sitio legítimo comprometido por un atacante, esa decisión puede llevarse por delante el correo, los subdominios y el contenido de quienes no hicieron nada. El ataque y el servicio que merece protección pueden compartir nombre.

El aviso de ICANN sobre las obligaciones frente al abuso de DNS, de febrero de 2024, pide ponderar ese daño colateral junto con las pruebas y las circunstancias. También importa quién recibe el aviso. El registrador —la empresa a la que se acude para registrar un nombre— debe tomar medidas rápidas y adecuadas para detener o interrumpir el abuso cuando dispone de pruebas que permiten actuar.

El operador de registro tiene otra función: mantiene la base de nombres de una terminación de Internet y publica su zona DNS. Su contribución mínima consiste en remitir los dominios y sus pruebas al registrador responsable, o en intervenir directamente cuando resulte apropiado. No son dos nombres para una misma obligación.

Si lo que falla es la forma de trabajar, tampoco hay una reparación universal. La parte contratada propone los cambios: procedimientos, formación, sistemas, vigilancia o supervisión de revendedores. ICANN examina el plan y su ejecución. Luego vuelve sobre las quejas nuevas, envía informes de prueba, observa tiempos de respuesta y mitigación y consulta datos del sector. Haber cambiado un procedimiento no demuestra, por sí solo, que la próxima denuncia vaya a recibir mejor trato.

Todo ello ocurre dentro de contratos, no de una potestad general sobre Internet. El Registrar Accreditation Agreement y el acuerdo base para registros de dominios genéricos no autorizan a ICANN a intervenir sobre cualquier intermediario o cualquier contenido perjudicial. Su definición de abuso de DNS comprende malware, botnets, phishing, pharming y spam cuando este distribuye alguna de las otras cuatro formas.

Setenta planes y una pregunta de calendario

El dato más prometedor del balance es también uno de los que más necesita un calendario: el 87,5 % de los más de 70 planes completados no mostraba indicadores de recurrencia hasta el momento del relato de ICANN. Los restantes recibieron una actuación de cumplimiento acelerada, incluidas notificaciones y, cuando correspondía, terminaciones.

La ausencia de repetición anima; no significa lo mismo tras un seguimiento breve que tras uno largo. El organismo explica cómo comprueba la eficacia, pero no publica una tabla completa por plan, los períodos individuales de observación ni una definición exhaustiva de esos indicadores. Tampoco fija expresamente el porcentaje en el 5 de agosto. No se puede dar a todos los planes la misma antigüedad ni convertir el dato en una garantía permanente.

El recuento de expedientes sí delimita una ventana: del 5 de abril de 2024 al 5 de agosto de 2026. En ella se abrieron más de 650 investigaciones y se resolvieron más de 570. Entre las resueltas, aproximadamente el 66 % llevó a medidas para detener el abuso y el 8 % a medidas para interrumpirlo. En el 21 %, la parte contratada no halló pruebas que permitieran actuar y presentó una explicación respaldada por pruebas. Son cifras redondeadas, no piezas con las que reconstruir recuentos exactos; la parte restante no está desglosada.

El balance del 2 de junio terminaba antes, el 5 de abril de 2026, con casi 530 investigaciones iniciadas y más de 480 resueltas. Entre ambos cortes pasaron cuatro meses. Restar dos totales aproximados no ofrece un incremento exacto, y menos aún una tendencia precisa.

Hay además un pequeño desajuste que importa. Octubre informa de ocho notificaciones de incumplimiento, una acreditación terminada y otros planes en preparación. El enlace sobre la terminación identifica a Trustname.com, pero su aviso lleva fecha del 27 de agosto y efecto desde el 11 de septiembre: ambas quedan fuera del corte del 5 de agosto. La publicación no explica el desfase. El caso sirve para entender el fallo de respuesta; no para encajarlo sin más en esa ventana estadística.

El lector tampoco tiene delante todos los planes. Solo se publican los del procedimiento formal, una parte menor de los asuntos de cumplimiento. Y el marco proactivo que ICANN prepara para complementar quejas y auditorías seguía en desarrollo en octubre; no se anunció una nueva regla ni un mecanismo final ya implantado.

En Trustname.com, la discusión empezó por lo que había que probar para lograr una respuesta. Acabó en si el registrador había aprendido a responder. Frenar el phishing resolvía la urgencia de aquellos dominios. La siguiente denuncia era la prueba que una corrección sobre el papel todavía tenía que superar.

Corrección. Entre los cortes estadísticos transcurrieron cuatro meses, no dos, como decía la versión anterior. El enlace de ICANN sí identifica a Trustname.com. El aviso posterior y el porcentaje de recurrencia no comparten una fecha de corte expresamente confirmada.