Resumen

  • El modelo final del RSS Governance Working Group contempla que, en una futura Governance Phase con plenas facultades, la función Security Incident Reporting suspenda las operaciones de un RSO en un caso extremo de incumplimiento que amenace de forma significativa al RSS. Esa autoridad aún depende de fases, hitos, consulta y votación; las fuentes públicas revisadas no muestran que esté activa.
  • La remoción permanente pertenece a DNR: investigación, oportunidades de corrección, recomendación al Council y retiro ordenado de las fuentes DNS descritas por RSSAC030. El documento no aclara si una suspensión afecta esas fuentes, cuál es su plazo, qué ocurre durante un recurso ni qué decisión restablece al operador.
  • Antes de Milestone 12 debería existir un recibo versionado de suspensión y retorno. Puede publicar autoridad, alcance, reloj, medidas correctivas, recurso y resultado, mientras reserva en un anexo protegido la evidencia que podría facilitar otro ataque.

Una potestad provisional sin estado de salida

El informe final entregado en febrero de 2026 no es una norma improvisada. Resume casi cuatro años de trabajo, 59 teleconferencias, diez reuniones públicas de ICANN y cuatro talleres. Su diseño busca pasar de la cooperación histórica de los operadores a una estructura con funciones reconocibles, controles y responsabilidades.

La función SIR aparece primero como una arquitectura de información: define incidentes, normaliza los avisos, revisa causas, desarrolla controles, audita, coordina mitigaciones y publica un informe anual. En la fase final, sus atribuciones aumentan. Podría pedir datos, exigir mejoras, imponer medidas correctivas y autorizar acciones de emergencia. En el supuesto más grave, podría suspender las operaciones de un Root Server Operator cuando el incumplimiento represente una amenaza significativa para el sistema raíz.

El umbral es estrecho y comprensible. Si un riesgo material no puede ser contenido, una estructura de gobernanza limitada a recibir informes sería decorativa.

La frase, sin embargo, no define el objeto de la suspensión. Puede referirse a la condición del operador dentro de la nueva estructura, a una obligación concreta, a ciertos componentes de red o a la prestación asociada a una letra de servidor raíz. También podría llegar a tener consecuencias en las fuentes públicas mediante las cuales los clientes conocen el servicio. El texto no elige entre esas posibilidades.

Tampoco aparece una figura de restablecimiento o reincorporación. Hay investigación, corrección, recurso y una vía separada de remoción. Falta la transición que convierte una corrección técnica en el cierre autorizado de una medida coercitiva.

La conclusión correcta no es que el sistema actual esconda una suspensión. Es que la arquitectura propuesta todavía debe completar su máquina de estados antes de ejercerla.

El modelo todavía no gobierna

La secuencia de implementación constituye una salvaguarda real.

Durante Initiation se formarían el Council y el Secretariat, con un ámbito deliberadamente limitado. En Establishment se definirían las cinco funciones, se redactarían sus cartas, se crearían las políticas de seguridad, los criterios de rendimiento, la financiación, el sistema de designación y remoción, el debido proceso y los recursos.

El paso a Governance exige que todas las funciones estén operativas y que las políticas centrales hayan sido ratificadas. Los Milestones 1–11 deben constar en una evaluación pública integral. Debe celebrarse una consulta pública. Las comunidades participantes deben ser consultadas para asegurar consenso, y el Council debe votar formalmente que la estructura está preparada. Solo entonces Milestone 12 activa la autoridad.

La documentación pública revisada se encuentra antes de ese punto. Brad Verd comunicó la aprobación consensuada del informe por el grupo de trabajo y lo entregó a las partes interesadas. Tripti Sinha agradeció el trabajo en nombre del Board de ICANN y habló del camino por delante. La carta no anuncia adopción ni puesta en marcha. Un plan operativo que anticipa una futura adopción tampoco equivale a la resolución que la ejecuta.

Por eso este análisis habla de una facultad que permitiría suspender. No la atribuye al Board actual, a RSSAC, a IANA ni a otra entidad existente.

La urgencia de SIR no es la sentencia de DNR

El informe divide la rendición de cuentas entre funciones con ritmos distintos.

SIR responde a un incidente de seguridad. Su trabajo comienza cuando disponibilidad, integridad o confidencialidad se encuentran materialmente afectadas. Puede necesitar una reacción inmediata, incluso mientras los hechos siguen incompletos.

Designation and Removal responde a la aptitud y condición del operador. Parte de problemas de rendimiento o incumplimiento, investiga, fija correcciones y observa su cumplimiento. Recomienda la remoción al Council solo si el RSO no alcanza los estándares tras oportunidades suficientes para corregir. La decisión definitiva pasa por el Council y la ejecución se coordina con IANA.

Esta separación impide que cada incidente se transforme automáticamente en un juicio sobre la existencia del operador. También impide que la lentitud de una causa de remoción bloquee una medida urgente.

Pero el expediente necesita cambiar de manos sin perder su estado. Una suspensión puede terminar porque el peligro desaparece, porque la corrección se verifica, porque prospera un recurso, porque una medida más acotada resulta suficiente o porque DNR abre una causa de remoción. El modelo no nombra el acto de entrega ni el titular del estado durante el tránsito.

Cumplir una medida correctiva no restablece por sí solo la autorización. Es un dato probatorio. Hace falta una decisión que aplique un criterio, compruebe la preparación operativa y cierre o modifique la suspensión.

RSSAC030 separa etiqueta, operación y fuentes

RSSAC030 identifica el punto donde una decisión institucional puede convertirse en una modificación técnica visible. El operador de las funciones IANA mantiene tres fuentes: el archivo root hints, la zona raíz y la zona root-servers.net. Allí se vinculan los nombres del servicio con direcciones bajo control de los RSO. La inclusión identifica a la organización como operador dentro del sistema común.

El modelo final cita RSSAC030 al describir el trabajo de DNR: coordinar un apagado ordenado y la remoción de un RSO de esas fuentes. La sección sobre la suspensión de SIR no contiene esa referencia.

La diferencia obliga a registrar tres capas por separado.

La primera es el estado de gobernanza: una autoridad declara suspendido al RSO. La segunda es el estado operativo: determinadas instancias, obligaciones o sistemas cambian durante la mitigación. La tercera es el estado en las fuentes: una instrucción autorizada modifica el archivo o las zonas mantenidas por IANA.

Una suspensión administrativa no debería interpretarse automáticamente como borrado de las fuentes. Una acción técnica durante un incidente no es, por sí misma, remoción definitiva. Y una modificación en las fuentes no debería ocultarse bajo una medida provisional si el propio diseño reserva la remoción a DNR y al Council.

El registro propuesto no prejuzga cuál de estas capas debe utilizarse. Obliga a decir cuál se utilizó.

Recurrir no equivale a volver

La propuesta ofrece apelación ante el Council para decisiones de SIR y un recurso directo para las decisiones de DNR. También incorpora revisión por pares, evaluación externa, informes y aprobación final del Council para la remoción.

Esas garantías controlan la decisión, pero no describen el estado operativo mientras se decide.

¿La mera presentación del recurso paraliza la suspensión? ¿Existe un mecanismo de medida cautelar? ¿Puede continuar una parte no afectada del servicio? Si el Council revoca la decisión, ¿el retorno es inmediato o queda sujeto a una prueba técnica? ¿Quién firma esa prueba? Si se corrigió una vulnerabilidad pero persiste otro riesgo, ¿se estrecha la medida o se reinicia el plazo?

No hay una respuesta universal, y precisamente por eso debe existir una regla previa. En una emergencia, SIR no puede esperar a que termine todo el proceso contradictorio. El Council tampoco debería resolver un recurso sin conocer el efecto operativo que sigue vigente. IANA y el RZM no pueden actuar sobre una conversación informal si su acción afecta las fuentes.

Un buen diseño separa contención, estado interino y decisión de fondo. Después los conecta mediante una custodia común.

La seguridad exige transparencia selectiva

RSSAC062 evita el falso dilema entre rendición de cuentas y secreto absoluto. Su guía sobre incidentes parte de una prioridad: informar no debe interferir con la mitigación; resolver el incidente viene primero.

El informe detallado puede incluir material que no deba hacerse público y usar las clasificaciones del Traffic Light Protocol. Deben excluirse los datos que ayuden a una futura agresión. Los canales necesitan autenticación y protección. A la vez, se recomienda una versión pública TLP:Clear en un plazo oportuno.

El recibo de suspensión puede aplicar la misma frontera. La capa pública indica quién actuó, bajo qué versión de la regla, qué categoría general de amenaza se invocó, qué alcance tuvo la medida, cuándo debe revisarse y en qué estado terminó. El anexo privado conserva claves, topología, registros de consultas, indicadores y vulnerabilidades.

Incluso la existencia y custodia del anexo puede ser verificable sin mostrar su contenido. La transparencia debe permitir auditar el poder, no reproducir el incidente.

La defensa más sólida conduce al mismo remedio

Hay razones fuertes para no sobrecargar el Functional Model con un manual de cada contingencia.

Las cartas y procedimientos de Establishment pueden incorporar experiencia operativa que un documento de alto nivel no posee. El umbral de suspensión es extremo. El modelo distribuye funciones, permite apelación, exige corrección antes de la remoción y somete la transición a una consulta y evaluación pública. La diversidad del RSS también permite que una intervención limitada proteja al conjunto.

La capacidad de emergencia, por tanto, no es el problema. El problema sería habilitarla sin comprobar su final.

Milestone 7 debe crear políticas, respuesta y escalamiento de seguridad. Milestone 8 debe definir remoción, debido proceso y recursos. Milestone 10 debe completar la responsabilidad y las revisiones adicionales. La evaluación anterior a Governance debería demostrar que esos tres hitos producen una sola cadena desde la acción inicial hasta el retorno o la remoción.

La idea de primacía del código en funcionamiento de Heng Lu ofrece una prueba útil: la declaración institucional debe corresponder a un efecto operativo mínimo, definido y verificable. No basta con que una autoridad diga que el RSO está suspendido si operadores, IANA y usuarios pueden asignar consecuencias distintas a esa palabra.

Su crítica a la falacia de continuidad aporta otra distinción. Lo que debe preservarse es el servicio colectivo, la cadena de seguridad y los usuarios, no necesariamente cada facultad de la institución ni cada posición del operador. Suspender a uno puede proteger a todos. Precisamente por eso la medida debe terminar en un estado explícito y no convertirse en una nueva fuente de incertidumbre.

Un recibo continuo desde la suspensión hasta el retorno

Antes de la plena habilitación, el Council debería ratificar un registro versionado común. Se abre de inmediato con pocos datos públicos y se completa sin obstaculizar la respuesta.

Debería contener:

  • identificador estable del caso y del RSO;
  • función decisora, autoridad y versión de la política;
  • categoría no sensible del desencadenante y carácter urgente u ordinario;
  • alcance sobre gobernanza, servicios, infraestructura y fuentes;
  • hora de entrada en vigor, duración inicial máxima y próxima revisión obligatoria;
  • salvaguardas de continuidad del RSS;
  • medidas correctivas y estado público de cumplimiento;
  • custodio y clasificación de la evidencia protegida;
  • recurso, petición de suspensión cautelar y decisión sobre ella;
  • criterios, autoridad y prueba técnica para el retorno;
  • revisión por pares o independiente;
  • cada prórroga con fecha, motivo y nueva autoridad;
  • resultado final: restablecido, acotado, sustituido o remitido a DNR;
  • cualquier instrucción separada a IANA o RZM y su reversión.

La semántica importa. Recurso presentado no es medida suspendida. Corrección completada no es regreso aprobado. Remisión a DNR no es remoción decidida. Remoción decidida no es fuentes modificadas.

Los nulos también deben hablar. “Sin acción en fuentes”, “sin recurso” y “decisión de retorno pendiente” son estados. Una casilla en blanco entrega el significado a la memoria de quienes estaban en la sala.

El recibo no crea un veto del operador ni un plebiscito público. No publica la mecánica del ataque. Conserva la velocidad de SIR, pero obliga a que toda medida tenga dueño, alcance, reloj y cierre.

Límites de la evidencia

Las fuentes revisadas no prueban que el Board de ICANN haya adoptado el modelo, que la Governance Phase haya comenzado o que un RSO haya sido suspendido. Tampoco permiten calificar a un operador actual como inseguro o incumplidor.

La ausencia de una palabra no demuestra que la fase de Establishment sea incapaz de crear el procedimiento. El hallazgo es preventivo: el procedimiento debe existir antes de la autoridad. El texto no define si la suspensión modifica las tres fuentes, por lo que este Artículo no afirma tal efecto.

La propuesta de transparencia se limita a autoridad y estado. La evidencia que facilite ataques o revele datos operativos legítimamente confidenciales puede permanecer protegida.

Fuentes

  1. ICANN — The Root Server System Governance Structure, 18 de febrero de 2026
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — entrega del informe final del GWG
  4. Tripti Sinha — respuesta de la presidencia del Board
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN — proyecto de plan operativo y financiero FY2027–2031
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile