Resumen

  • El informe inicial del PDP 1 propone que un registrador realice una Associated Domain Check cuando tenga evidencia accionable de que un nombre no comprometido se utiliza para el abuso del DNS definido en el RAA. La consulta sigue abierta y la obligación todavía no existe.
  • La recomendación 8 exige demostrar el cumplimiento, pero no hace obligatorios sus seis datos orientativos y veta un formato documental prescrito. Un recibo mínimo protegido permitiría comparar estados sin convertir la investigación en un algoritmo central.

El primer dominio denunciado puede ser sólo la puerta visible de una campaña. La pregunta normativa es qué debe hacer el registrador después de comprobarlo.

El 18 de agosto, el grupo de trabajo de la GNSO abrió a comentario público su informe inicial sobre DNS Abuse Mitigation PDP 1. Su propuesta principal es un giro dentro de la cartera de un mismo registrador. Cuando exista evidencia accionable de que un nombre se usa para phishing, malware, botnets, pharming o spam como vehículo de esas conductas, el registrador tendría que buscar otros nombres razonablemente vinculados.

El giro no alcanza a todos los dominios que compartan un dato. No exige coordinación entre registradores. Tampoco convierte una asociación en una conclusión de abuso. Los dominios legítimos comprometidos sin participación de su titular quedan fuera del disparador específico.

La arquitectura del informe es deliberadamente flexible. El registrador revisaría la información a la que accede normalmente: cuenta, datos del titular, patrones de nombres, servidores compartidos, secuencias de registro, análisis propio o indicadores que aporta un tercero. No tendría que crear datos que no están razonablemente disponibles. Si interviene un revendedor, el registrador conserva la responsabilidad contractual.

Esa flexibilidad protege más de lo que debilita. Un mismo nameserver puede alojar a miles de clientes. Un servicio proxy puede agrupar identidades que no tienen relación. Una regla automática demasiado amplia puede transformar la investigación de una campaña en daño colateral a usuarios legítimos. Por eso el informe separa la investigación de la mitigación y mantiene un estándar de actuación pronta adaptado a la gravedad, complejidad y urgencia de cada caso.

La dificultad no está en permitir decisiones distintas. Está en saber después si esas decisiones atravesaron los mismos estados.

Seis datos sugeridos no forman todavía una interfaz

La recomendación preliminar 8 ordena que los registradores puedan demostrar el cumplimiento con registros y documentación ordinarios. Enumera el disparador y su momento, la fecha de la revisión, la información consultada, el número de dominios asociados, la acción posterior y la justificación de que el proceso fue razonable y proporcional.

La lista es orientativa: esos datos pueden ser suficientes. El mismo apartado dispone que la política no prescriba un formato. Sólo obliga a mantener una descripción interna del proceso y entregarla a ICANN cuando la solicite.

Un expediente así puede ser auditable. Contractual Compliance puede leer los registros internos, solicitar piezas y evaluar un caso. Por tanto, no hay base para decir que la propuesta elimina la prueba o hace imposible la aplicación.

La limitación surge al comparar. ¿Cuándo empezó el reloj: cuando llegó el aviso, cuando se validó o cuando el analista abrió el ADC? ¿Un cero significa que no había dominios asociados o que la consulta no pudo acceder legalmente a un dato? ¿La suspensión de un nombre prueba la asociación o es una decisión posterior con otra razón? Sin estados comunes, las respuestas válidas quedan mezcladas.

La recomendación 7 hace visible esa necesidad. Propone revisar la eficacia dos años después de la implementación y encarga a ICANN org y al futuro IRT definir datos agregados y una línea de base. Además, reconoce que el volumen general de abuso no permite atribuir causalidad a una sola política. Para saber si el mecanismo funcionó, primero habrá que contar transiciones que signifiquen lo mismo.

El registro mínimo puede proteger el método

Un modelo estrecho tendría dos capas.

La capa del caso sería confidencial. Un identificador seudónimo enlazaría la versión de la política, clase y hora del disparador, condición del dominio comprometido, apertura y cierre, frontera entre registrador y revendedor, clases de señales usadas o no disponibles, alcance examinado, resultados de asociación, mitigación o no acción, salvaguardas de privacidad, huella del conjunto probatorio, función responsable, revisión y corrección.

Nada de eso requiere publicar dominios, titulares, denunciantes, reglas de detección o umbrales. Tampoco obliga a todos a buscar de la misma manera. El recibo describe el movimiento institucional: hubo un disparador, se abrió una revisión delimitada, se utilizaron o excluyeron ciertas clases de información, se tomó una decisión y cualquier cambio posterior conservó la identidad anterior.

La capa pública sería agregada. Podría mostrar cuántos disparadores válidos abrieron controles, cuántos terminaron en cada clase de disposición, en cuántos faltó legalmente una clase de datos y cuántas decisiones fueron corregidas. Harían falta supresión de celdas pequeñas, denominadores y advertencias sobre la mezcla de casos. No debería existir una tabla pública de acusaciones ni una clasificación simplista de registradores.

Así, ICANN tendría un expediente protegido para el cumplimiento y una base semántica para la evaluación. La comunidad obtendría indicadores sin recibir datos personales ni inteligencia operativa.

La obligación sigue siendo hipotética

Desde abril de 2024, las enmiendas globales ya exigen medidas prontas y apropiadas ante abuso del DNS bien evidenciado. El aviso de ICANN explica que Compliance puede pedir un listado concreto de registros. Los paneles mensuales publican quejas, notificaciones y motivos de resolución por categorías.

Esos paneles no contienen resultados de Associated Domain Checks. El de junio de 2026 antecede a la propuesta y no prueba su desempeño. Su importancia es institucional: ICANN no partiría de cero al crear una capa agregada futura.

El informe inicial tampoco cambia el RAA. La consulta cierra el 28 de septiembre; después vendrán la revisión de comentarios, el informe final, el Consejo de la GNSO, la posible adopción por la Junta y la implementación. Incluso la designación de Full Consensus que el presidente asignó a la recomendación 8 describe el acuerdo dentro del grupo, no una política vigente.

Precisamente porque el diseño está abierto, ahora puede corregirse con poco coste. Una vez desplegados cientos de registros internos incompatibles, ninguna traducción tardía recuperará un evento que nunca se distinguió.

Coordinar menos, pero coordinar lo necesario

La respuesta correcta no es centralizar la investigación. Es definir la mínima unión entre sus etapas. Disparador, revisión, resultado, acción y corrección deben poder relacionarse sin que ICANN dicte herramientas o criterios secretos.

Ésa es una forma disciplinada de gobernanza distribuida. El centro conserva sólo el lenguaje indispensable para atribuir una obligación común. Las decisiones sensibles continúan en el lugar que posee los datos, la competencia y la responsabilidad. Un ADC puede ser obligatorio y proporcional; para que también sea evaluable, necesita un recibo que sobreviva al sistema interno que lo produjo.

Fuentes

  1. Consulta pública de ICANN
  2. Anuncio de ICANN
  3. Informe inicial del DNSAM PDP 1, 18 de agosto de 2026
  4. Página del proyecto DNS Abuse Mitigation PDP 1
  5. Carta del DNS Abuse Mitigation PDP 1
  6. Enmiendas globales de ICANN de 2024
  7. Aviso de ICANN sobre obligaciones frente al abuso del DNS
  8. Panel de cumplimiento sobre abuso del DNS, junio de 2026
  9. Programa de ICANN para mitigar el abuso del DNS
  10. Proceso de desarrollo de políticas de la GNSO
  11. Procedimientos vigentes del Consejo de la GNSO