Ed Shryane explica el retraso DNS de RIPE

Un salto de línea atascó el espejo de RIPE: Ed Shryane explica 60 horas de retraso en el DNS inverso

Por qué importa

Al descodificar caracteres escapados, el proceso añadió una línea a un objeto RPSL. El servicio NRTM de RIPE NCC se interrumpió y las actualizaciones de DNS inverso quedaron pendientes hasta que el equipo reparó y comprobó el flujo.

Sofia Ren31 de octubre de 2026Tiempo de lectura 2 minÚltima actualización: 31 de octubre de 2026

Ed Shryane; su apariencia se basa en un retrato oficial del equipo de RIPE NCC Database. La sala de operaciones es imaginada.

Resumen

RIPE NCC sitúa el fallo de NRTM entre las 00:06 UTC del 2 de agosto y las 12:30 UTC del 4 de agosto: 60 horas y 24 minutos. Las actualizaciones de DNS inverso se retrasaron durante ese intervalo; después se procesó la cola pendiente.
En RIPE 93, Ed Shryane atribuyó el fallo a una conversión que añadió un salto de línea a un objeto RPSL. El equipo dejó de deshacer los escapes y comprobó los últimos 1.000 objetos y el cierre del flujo.

Análisis

El cambio podía estar en la base de RIPE y, aun así, no haber llegado al DNS público. El corte estaba en el paso intermedio: el sistema de provisión de DNS inverso también consume el servicio Near Real Time Mirroring, o NRTM, de RIPE NCC.

El mensaje que RIPE NCC envió el 6 de agosto al grupo de trabajo de la base de datos da el horario del impacto: desde las 00:06 UTC del 2 de agosto hasta las 12:30 UTC del día 4. Son 60 horas y 24 minutos. Durante ese tiempo se retrasaron las actualizaciones de DNS global; una vez aplicado el arreglo, RIPE NCC procesó todas las que estaban pendientes. La página oficial de estado clasificó el incidente como grave y registró después el regreso del DNS inverso a operación normal.

Ed Shryane, ingeniero de la base de datos, explicó el origen en la sesión Database de RIPE 93. El software descodificaba caracteres que debían seguir escapados. Al hacerlo insertaba una línea nueva y convertía el objeto RPSL en texto sintácticamente inválido, aunque RIPE NCC lo había aceptado. El RFC 2622 define la sintaxis de RPSL; aquí, una operación de representación alteró la estructura que el lector del flujo esperaba encontrar.

La corrección preservó los caracteres escapados. Después, el equipo volvió sobre los últimos 1.000 objetos, verificó que se pudieran analizar y comprobó que la respuesta de NRTM terminara con un pie de página coherente. Esa última comprobación cierra otra puerta: un consumidor debe saber que recibió un tramo legible y completo.

El recorrido operativo va del objeto de base al espejo, de ahí al aprovisionamiento del DNS inverso y finalmente a la zona publicada. Una decisión de decodificación en el registro terminó retrasando una actualización en el último paso. Las fuentes públicas no indican cuántos espejos o dominios quedaron afectados; ese recuento cambiaría la medida del alcance externo.