Summary

  • ICANN ensayó el relevo de emergencia de tres dominios genéricos en proceso de terminación entre 2016 y 2017. Sus diapositivas registran 44, 37 y 20 problemas, además de una indisponibilidad simulada del DNS de entre 11 horas y 55 minutos y un día, nueve horas y cinco minutos.
  • La recomendación SSR2 24.1 solicitó una prueba integral al menos anual, con datos, estados, plazos, rutas de excepción y resultados publicados. El Consejo la declaró plenamente implantada en noviembre de 2022 apoyándose en los ensayos anteriores y en acuerdos que contemplan ejercicios anuales.
  • La documentación de implantación de enero de 2023 y el informe de ICANN del segundo trimestre de 2026 no incluyen en sus apartados sobre 24.1 un resultado posterior fechado. Una comparación útil mostraría tiempos por función y cierre de los problemas anteriores.

Un dominio puede resolver antes de estar recuperado

El programa Emergency Back-End Registry Operator, EBERO, permite que ICANN declare una emergencia y coordine un operador temporal cuando un registro de dominio genérico no puede sostener alguna de cinco funciones críticas. Hay que servir el DNS, operar el sistema compartido de registro, ofrecer los datos del directorio, mantener depósitos de custodia y firmar correctamente la zona. La palabra «continuidad» mete en una sola caja cinco trabajos con dueños y relojes diferentes.

En ICANN60, en 2017, el organismo presentó un desglose que permite abrir esa caja. Los ejercicios comenzaron el 26 de enero de 2016, el 25 de abril de 2017 y el 21 de septiembre de 2017. Se hicieron con tres proveedores de emergencia distintos y con tres dominios cuyos acuerdos de registro estaban terminando. Cada dominio tenía un solo nombre registrado por el propio registro y carecía de titulares ordinarios. Los operadores consintieron la prueba antes de la retirada de la zona raíz. El punto de partida era un umbral de fallo simulado. Las cifras son tiempos del ejercicio, no una crónica de cortes sufridos por clientes.

La diferencia entre poner el DNS en marcha en el proveedor y modificar la raíz es decisiva. Los servidores de respaldo recuperaron DNS y DNSSEC a las tres horas y 46 minutos, nueve horas y 11 minutos y tres horas y 59 minutos. Los cambios correspondientes entraron en la zona raíz a las ocho horas y 22 minutos, un día, cinco horas y cinco minutos y siete horas y 55 minutos. ICANN calculó la indisponibilidad simulada total del DNS en 12 horas y 22 minutos, un día, nueve horas y cinco minutos y 11 horas y 55 minutos, descontando efectos de caché. No hay un botón único de «rescate».

Un servicio puede estar listo detrás del escenario mientras su dirección pública todavía apunta a otra parte.

Los datos tardaron más. Los depósitos de custodia llegaron a ICANN en un día, siete horas y 31 minutos; dos días, 19 horas y 36 minutos; y un día, 14 horas y 22 minutos. El sistema compartido de registro volvió después de casi dos, casi tres y más de cuatro días. Para el directorio RDDS, la medición total de interrupción fue de dos días, cinco horas y cinco minutos en el primer ensayo; tres días, dos horas y 14 minutos en el segundo; y cinco días, 17 horas y 58 minutos en el tercero.

La función de depósito se restableció al terminar los ejercicios: cinco días, 21 horas y 53 minutos; ocho días, dos horas y 34 minutos; y ocho días, tres horas y 21 minutos. La cadena completa se parece menos a un interruptor que a una carrera de relevos donde la última posta llega días después.

La presentación anotó 44, 37 y 20 problemas. Son 101 observaciones sumadas en tres pruebas, sin que la fuente permita contarlas como 101 fallos únicos. ICANN dijo que algunas cuestiones se habían resuelto y otras seguían en trámite. Aquella diapositiva no mostró una tabla de cierre y nueva prueba por incidencia. Que un ensayo saque a la luz problemas es buena ingeniería. Que la institución pueda enseñar cómo se corrigieron y cómo respondió el siguiente ensayo es buena gobernanza.

Lo que pidió la revisión y lo que aprobó el Consejo

La revisión SSR2 fue concreta. Su recomendación 24.1 pidió probar de extremo a extremo todo el proceso EBERO a intervalos predeterminados, como mínimo una vez por año. El plan debía fijar conjuntos de datos, estados de avance y plazos, coordinar las rutas de excepción con las partes contratadas y publicar resultados. Esa cadencia era el centro del encargo: repetir una medición después de que cambien proveedores, contratos, sistemas o personas.

El Consejo de ICANN decidió en noviembre de 2022 que la recomendación estaba plenamente implantada. Se basó tanto en los tres ensayos anteriores como en las cláusulas de los acuerdos con proveedores que permiten ejercicios de preparación cada año. También tomó en cuenta una aclaración: no se esperaba usar dominios activos con registrantes. Evitar poner a terceros en un simulacro es una decisión sensata; los tres ensayos sobre dominios en retirada mostraron otra forma de probar el proceso. El punto controvertido está en el estándar de prueba para una práctica que la revisión quiso recurrente.

El documento de implantación publicado en enero de 2023 describe aquellos ejercicios, cita las obligaciones contractuales y fija como fecha final la votación de noviembre de 2022. Deja la fecha de «implantación completada» en «n/a» y los hitos en «n/a». En su explicación no aparece una prueba posterior con fecha, tiempos y seguimiento de los problemas. El informe del segundo trimestre de 2026 conserva el estado de completada y vuelve a citar la posibilidad contractual de ejercicios anuales. Tampoco presenta en su apartado 24.1 una nueva medición.

La página pública actual de EBERO enumera proveedores, acuerdos y el manual de transición. Es información necesaria para saber quién puede recibir una función crítica. Su lista de recursos no contiene una serie anual fechada de resultados. Un acuerdo renovado puede demostrar continuidad contractual. Para saber si la entrega de un depósito sigue tardando más de dos días o si los errores del ensayo anterior se cerraron, hace falta otro tipo de documento.

El organismo publicó en 2017 justamente el tipo de prueba que permitiría juzgar su mejora. La fecha, el proveedor, los datos del ensayo, las cinco funciones, las rutas de excepción, el instante de cada recuperación y el destino de cada incidencia caben en un informe. Si ICANN adjunta ese registro al estado «completada», el lector podrá distinguir capacidad contratada de rendimiento observado. El Consejo ya cerró el expediente. El cronómetro del próximo relevo sigue siendo la pregunta que importa.

Sources