Number Resource Society
Si falla el registro de IP, ¿quién garantiza la continuidad de tu red?
Una red puede seguir funcionando mientras su operador pierde la capacidad de gestionar sus recursos. Qué ocurre con los registros, el DNS inverso, RPKI y las transferencias, y por qué la continuidad no puede depender de una sola institución.
En esta página
Esta edición se ha reelaborado a partir del artículo de Ann Yong y conserva su fecha de publicación original. La revisión del 28 de octubre de 2026 distingue las reglas vigentes de las reformas que propone NRS; las fuentes se comprobaron ese mismo día.
Tus clientes no contratan un registro regional: contratan servicios que dependen de direcciones IP. Sin embargo, una crisis del organismo que mantiene sus registros puede acabar condicionando tu capacidad de prestar esos servicios. El primer síntoma no tiene por qué ser una caída de Internet. Puede ser un contacto que ya no se puede corregir, una transferencia paralizada o un cambio de seguridad que nadie puede tramitar. Por eso, preguntar si el registro sobrevivirá es insuficiente. La pregunta que importa a los operadores es cómo seguirán funcionando sus servicios, y cómo podrán gestionarlos, si ese registro deja de cumplir su función.
Diagrama del artículo original, con texto en inglés. El fallo de un registro no corta automáticamente el tráfico. Los apartados siguientes explican las distintas dependencias de gestión y seguridad.
El registro coordina recursos; no transporta todo el tráfico
Las direcciones IPv4 e IPv6 y los números de sistema autónomo, o ASN, son recursos de numeración. IANA coordina estos recursos a escala mundial; los registros regionales de Internet, los RIR, mantienen registros y prestan servicios asociados conforme a sus respectivos marcos. Sus datos permiten relacionar una dirección o un bloque con una organización, sus contactos y determinados antecedentes administrativos.
La gestión del DNS inverso y algunos servicios de seguridad del enrutamiento también dependen de estos acuerdos. Pero el registro no es un router central por el que circulan todos los paquetes. Registro, acceso a las cuentas, enrutamiento y seguridad son capas distintas. Una evaluación útil de los riesgos debe identificar cuál falla y cómo afecta a las demás.
Una avería del registro no desconecta automáticamente todas las direcciones
Los prefijos ya anunciados mediante BGP pueden seguir presentes en las tablas de enrutamiento. Los servidores siguen atendiendo peticiones y, en apariencia, nada ha cambiado. La caída de un servicio de registro no equivale por sí sola a una orden universal de retirar esos anuncios.
Lo que puede desaparecer antes es la capacidad de gestionar el recurso: actualizar contactos, recuperar una cuenta, documentar una reorganización o solicitar una transferencia. Si el registro deja de reflejar la realidad, una red que hoy funciona puede resultar cada vez más difícil de modificar o de acreditar como propia. Medir solo el tiempo de caída oculta esa pérdida de control.
Sin datos WHOIS fiables, resolver incidentes cuesta más
WHOIS permite consultar información de registro y contactos. Operadores, equipos de seguridad y responsables de verificaciones lo utilizan para localizar a una organización o a quien puede responder por un recurso. Un servicio caído, o unos datos que ya no se actualizan, dificultan la coordinación aunque las direcciones sigan siendo accesibles.
Una dirección de contacto obsoleta no se vuelve útil porque el servidor WHOIS continúe respondiendo. La continuidad exige conservar datos verificables y poder corregirlos con autorización. El objetivo no es mantener una página encendida, sino sostener una función en la que otros puedan confiar.
Guardar respuestas RDAP no equivale a poder reconstruir el registro
RDAP ofrece datos estructurados sobre recursos, organizaciones, contactos y eventos. La RFC 9082 define el formato de las consultas, no los procedimientos de provisión ni de actualización. Una copia de una respuesta pública puede ser una prueba útil, pero no contiene necesariamente todo lo que hace falta para recuperar el servicio.
La recuperación puede requerir la identidad del titular reconocido, cambios y transferencias anteriores, disputas abiertas, relaciones de autenticación y autorización y trazas de auditoría. Parte de esa información debe permanecer protegida. Hay que definir cómo se conserva y quién puede recibirla en una transición, sin confundir la consulta pública con una copia completa del estado del registro.
El DNS inverso puede seguir respondiendo y, aun así, quedar inmovilizado
El DNS inverso relaciona una dirección con un nombre mediante registros como PTR. Es relevante para el correo, la operación y el diagnóstico. Los servidores existentes pueden seguir contestando aunque el organismo encargado de procesar un cambio de delegación deje de hacerlo.
El negocio, entretanto, necesita cambiar servidores o proveedores. Un plan de continuidad debe explicar cómo se preservan las delegaciones, quién puede solicitar cambios y cómo se recupera la gestión de forma segura. Mantener la configuración de ayer no basta si nadie puede administrar la de mañana.
RPKI necesita continuidad de la confianza, no solo de los archivos
RPKI permite comprobar criptográficamente autorizaciones de origen de rutas. Intervienen los ROA, certificados de recursos, claves de firma, repositorios de publicación, manifiestos, información de revocación, anclas de confianza y validadores. La documentación del RIPE NCC sobre su ancla de confianza muestra cómo se articula esa cadena.
Copiar objetos no resuelve quién puede renovarlos o modificarlos, cómo se protegen las claves ni cómo continúa la emisión y publicación. El impacto en el enrutamiento depende de los objetos y certificados afectados, de los datos que reciben los validadores y de las políticas de cada red. No se puede deducir una invalidación mundial e inmediata de cualquier fallo institucional.
NRS defiende que la seguridad siga vinculada al control legítimo y comprobable del recurso, y no dependa de que un único operador sobreviva indefinidamente. Un conflicto de la institución no debería convertirse en un riesgo de enrutamiento para titulares ajenos a él. Es un objetivo de reforma; no una garantía de recuperación universal ya disponible.
Las empresas siguen cambiando aunque el registro se detenga
Durante una crisis pueden producirse adquisiciones, cambios de nombre, cesiones de activos y reorganizaciones. El contrato y la operación pasan a una nueva entidad, pero el registro puede seguir mostrando a la anterior porque nadie tramita la actualización.
Cuanto más se separan los documentos, la realidad empresarial y los datos del registro, más difícil resulta una verificación, una transferencia posterior o una disputa. La función de registro debe permitir documentar cambios respaldados por pruebas. La incapacidad de un proveedor no debería congelar indefinidamente la situación administrativa de los recursos.
Poder usar una dirección no significa tener una salida
Una cuenta inaccesible, una entidad mal identificada, restricciones de política, compromisos contractuales o una controversia también pueden bloquear un recurso. No todos esos problemas son averías del registro. Comparten, sin embargo, una dependencia: el titular sostiene su actividad sobre unas direcciones que no puede actualizar, transferir o gestionar con normalidad.
Renumerar una red establecida puede implicar costes y riesgos considerables. Cuando no existe una alternativa viable, la continuidad del negocio termina condicionada por decisiones de las que el operador no puede apartarse. Ese desequilibrio merece atención incluso si el tráfico sigue fluyendo.
La crisis de una institución no debería propagarse a las redes
Un fallo técnico, un litigio o una crisis de gobernanza tiene un ámbito propio. Si termina afectando indiscriminadamente a empresas que no lo causaron, el sistema está transmitiendo el riesgo institucional a la infraestructura de otros.
La continuidad debe diseñarse para limitar esa propagación: preservar la integridad de los datos, mantener funciones esenciales y ofrecer mecanismos de revisión y recuperación. No se trata de eliminar la responsabilidad del titular ni de ignorar resoluciones aplicables. Se trata de evitar que cualquier problema de un operador del registro se convierta en una amenaza general para quienes dependen de él.
La portabilidad permitiría cambiar de servicio sin perder la historia
La propuesta de portabilidad separa la identidad y el historial del recurso de un único prestador. Pretende que pueda cambiar la prestación del servicio de registro sin perder la unicidad, el control verificable o las pruebas, y sin imponer una renumeración innecesaria.
Eso exige resolver autoridad, autenticación, conflictos y seguridad; no basta con copiar una base de datos. Tampoco debe presentarse como un derecho general a elegir libremente cualquier RIR que ya exista para todas las direcciones. Es una dirección de reforma que debe contrastarse con las reglas efectivamente vigentes.
Nueve componentes que una recuperación debe preservar
Una recuperación seria debe considerar nueve componentes: el estado actual del registro; los antecedentes históricos; los datos de WHOIS y RDAP; las relaciones de autenticación y autorización; las delegaciones de DNS inverso; los objetos, claves y relaciones de confianza de RPKI; el historial de transferencias; la información sobre disputas; y las trazas de auditoría.
La lista combina datos, facultades de gestión y servicios en funcionamiento. No todos requieren el mismo tratamiento ni pueden publicarse. Para cada componente hay que establecer qué se conserva, cómo se verifica, quién puede utilizarlo y bajo qué autoridad continúa el servicio. La documentación de una recuperación no puede reducirse al inventario de archivos copiados.
La réplica sirve si permite verificar y recuperar
Conservar copias independientes y un historial auditable reduce la dependencia de una sola instancia y ayuda a detectar alteraciones. Pero una réplica desactualizada, incompleta o sin relaciones de autorización no garantiza una recuperación fiable.
La protección de información sensible, la trazabilidad de cambios y la reconciliación del estado deben formar parte del diseño. El sistema tiene que poder explicar qué versión es válida y por qué, y resolver diferencias sin borrar la evidencia. Replicar no significa publicar indiscriminadamente los datos de los titulares.
Una función esencial necesita un operador sustituible
La unicidad de las direcciones requiere coordinación. No demuestra que el mismo organismo deba prestar el servicio para siempre. Si una institución deja de hacerlo de forma fiable, debe existir una vía definida para que la función continúe sin perder datos, seguridad ni legitimidad.
La sustitución necesita condiciones, responsabilidades y pruebas previas. Una alternativa que solo se improvisa después de la crisis no ofrece la misma protección que un mecanismo conocido y practicado. La continuidad debe descansar en capacidades verificables, no exclusivamente en la confianza en la permanencia del operador.
Continuidad del registro y supervivencia institucional no son lo mismo
Una institución puede conservar su personalidad jurídica y, sin embargo, dejar de atender funciones esenciales. También puede cambiar quien presta el servicio sin que por ello desaparezcan las funciones. Confundir ambas continuidades lleva a proteger la estructura organizativa y dar por resuelta la protección de las redes.
En su Note 70, «The Registry Continuity Fallacy», Lu Heng plantea proteger el registro y su continuidad en lugar de convertir al operador en una dependencia insustituible. Es un análisis y una propuesta de reforma. Las capacidades actuales de cada región deben comprobarse por separado.
Concentrar dependencias concentra consecuencias
Cuando consulta, administración, transferencias y seguridad dependen de una misma estructura, una sola crisis puede afectar a varias funciones a la vez. La estabilidad diaria no revela necesariamente ese riesgo común.
Distribuir controles, conservar evidencia independiente y definir alternativas permite contener fallos. La descentralización no significa prescindir de coordinación: significa que la coordinación no tenga que fallar entera cuando una de sus instituciones deja de funcionar.
Qué puede revisar hoy un operador
Revisa quién figura como titular y quién conserva las pruebas; qué personas tienen acceso y cómo se recupera una cuenta; si los contactos están actualizados; quién controla el DNS inverso, los ROA y los objetos IRR; y qué procedimientos se aplicarían a una reorganización, transferencia o disputa.
Después examina la dependencia institucional: servicios críticos, mecanismos de escalado, compromisos de continuidad y alternativas realmente disponibles. Asigna responsables y documentación a cada respuesta. Que el prefijo responda hoy no demuestra que todos estos puntos estén resueltos, y una hipótesis de recuperación no debe anotarse como capacidad probada.
La resiliencia se prepara antes de necesitarla
Un sistema resiliente conserva un estado verificable, mantiene evidencia independiente, limita la propagación de disputas y prevé la continuidad de la seguridad y del DNS inverso. También define mecanismos de sustitución, portabilidad y resolución independiente antes de una crisis.
Los titulares deben poder entender esas garantías, comprobarlas y saber quién responde por ellas. No es razonable posponer estas preguntas hasta que los clientes sufran el resultado de una dependencia que nunca pudieron evaluar.
Protejamos la función, no la ausencia de alternativas
La calidad de un registro debe medirse por su capacidad de preservar datos, verificar el control, procesar cambios legítimos, contener disputas y mantener servicios esenciales. También por la existencia de una salida cuando su operador no puede cumplir esa misión.
Internet necesita números únicos, información exacta y autorizaciones fiables. Ninguna de esas necesidades exige que todas las empresas comprometan indefinidamente su futuro con un solo gestor. Las redes deben continuar. Si una institución falla, el sistema debe permitir que la función que presta continúe sin ella.
Preguntas frecuentes
¿Qué ocurre con los recursos IP cuando falla su registro?
El enrutamiento existente puede continuar mientras se ven afectadas consultas, actualizaciones, transferencias, delegaciones de DNS inverso o servicios RPKI. Hay que comprobar cada función; una prueba de conectividad no describe toda la situación.
¿La caída de un RIR provoca necesariamente una interrupción?
No. BGP y los servicios de registro son sistemas distintos. Las consecuencias dependen de los servicios afectados, los objetos de seguridad y las políticas de las redes. Una crisis prolongada puede impedir la gestión incluso antes de afectar al tráfico.
¿Puede funcionar la red sin WHOIS o RDAP?
Sí. Son servicios de consulta, no el mecanismo que transporta los paquetes. Sus datos siguen siendo importantes para coordinar incidentes, comprobar información y localizar responsables.
¿Por qué RPKI necesita su propio plan de continuidad?
Porque deben preservarse certificados, claves, ROA, repositorios y relaciones de confianza, junto con la autoridad para gestionarlos. Una copia de archivos no resuelve por sí sola una transición segura.
¿Qué significa aquí portabilidad?
La propuesta de poder sustituir el servicio de registro conservando unicidad, historial y control, sin renumeración innecesaria. No significa que cualquier recurso pueda cambiar libremente de RIR en la actualidad.
¿Por qué preparar la sustitución de un registro?
Porque la incapacidad de una organización no debería impedir indefinidamente las funciones que sostiene. La transición necesita reglas, responsables y pruebas anteriores a la crisis.
¿Bastan los datos RDAP públicos para recuperar el servicio?
No. Pueden aportar evidencia, pero la recuperación también puede necesitar historiales protegidos, habilitaciones, información de disputas y auditoría, y continuidad de las funciones de seguridad.
De entender el riesgo a participar en las decisiones
Si un problema de registro, acceso o servicio amenaza tu actividad, empieza por conocer el alcance de NRS Shield. Para contribuir a cambiar las reglas, consulta las acciones vigentes. Si quieres que NRS te represente en un asunto concreto, examina por separado el poder de representación, o POA: quién recibe el mandato, para qué, durante cuánto tiempo, cómo se revoca y qué responsabilidades asume. Pedir ayuda, hacerse miembro y otorgar un poder son decisiones diferentes. Una POA no garantiza la continuidad de la red, no transfiere la titularidad de las direcciones y no concede automáticamente derecho a voto; tampoco sustituye los procedimientos del organismo correspondiente. Quienes soportan estos riesgos deben poder participar en las reglas, impugnar decisiones y exigir responsabilidades.