¿Qué es la Exportación de Registro-Estado para Recursos Número de Internet?

La exportación del estado de registro es el concepto de crear una copia autenticada, portátil y auditable de la información esencial del registro asociada con un recurso número de Internet. Para un bloque IPv4 , prefijo IPv6 o número de sistema autónomo, que la exportación podría incluir información como:

• el recurso del número de Internet;
• información reconocida de los titulares;
• objetos de contacto pertinentes;
• registro;
• historial de transferencia;
• información de las delegaciones;
• d) Invierta la información DNS ;
• Metadatos relacionados con la RPKI ;
• o situación de conflicto;
• la historia del cambio material; y
• los registros de auditoría necesarios para comprender el estado actual verificado.

El propósito no es simplemente crear un archivo de copia de seguridad. Una exportación útil del estado de registro debe hacer posible responder a una pregunta más importante:

Si el sistema que mantiene actualmente un registro de recursos se vuelve indisponible, controvertido o incapaz de prestar servicios esenciales, ¿puede el estado de registro legítimo ser comprendido y reconstruido de forma independiente?

Eso hace que la exportación del estado de registro sea una cuestión continuidad, auditabilidad y portabilidad, no sólo descarga de datos. También es importante distinguir el concepto de protocolos existentes como RDAP . RDAP proporciona acceso estructurado a la información de registro de Internet, pero una exportación completa del estado de registro podría contener información adicional de continuidad, contexto histórico, relaciones de autorización y datos de auditoría necesarios para reconstruir el estado verificado de un recurso. En otras palabras: RDAP le ayuda a consultar datos del registro. La exportación del estado del registro ayudaría a preservar el estado necesario para la continuidad.

¿Por qué importa la exportación del Estado-Registro?

Los recursos del número de Internet pueden seguir funcionando durante muchos años. Durante ese tiempo:

• las empresas pueden cambiar nombres;
• las organizaciones pueden fusionarse;
• se pueden transferir recursos;
• las direcciones pueden ser alquiladas o delegadas;
• Los proveedores pueden cambiar;
• el enrutamiento puede moverse entre ASN s;
• los contactos técnicos pueden cambiar;
• La información RPKI puede cambiar;
• DNS inverso puede moverse; y
• pueden surgir controversias.

El recurso en sí puede permanecer incrustado en una red de funcionamiento a lo largo de esos cambios. Eso significa que el estado útil de un recurso número de Internet es más que una sola fila en una base de datos. Puede ser el resultado de años de cambios verificados. Si esa historia se vuelve inaccesible, los operadores de red pueden saber todavía que se está ejecutando un bloque IPv4 , pero reconstruir por qué el estado actual del registro es legítimo puede ser mucho más difícil. Una exportación de estado de registro tiene por objeto reducir esa dependencia. El principio es directo: La información crítica del registro debe seguir siendo duradera incluso cuando la organización, la plataforma o la infraestructura que mantiene actualmente sus cambios.

Función del registro es diferente de la institución del registro

Esta distinción es fundamental para comprender la exportación del estado de registro. Internet requiere ciertas funciones de recursos de número. Las redes necesitan:

• identificadores únicos a nivel mundial;
• información precisa sobre registro;
• información de contacto fiable;
• c) Registros de transferencia;
• d) La continuidad del DNS inversa;
• - información sobre la seguridad en el enrutamiento;
• cambios auditables; y
• mecanismos para resolver las reclamaciones conflictivas.

Esas funciones importan. Pero... función y el institución que desempeña actualmente la función no son necesariamente lo mismo. Una plataforma de bases de datos puede cambiar. Una organización puede reestructurarse. El software puede ser reemplazado. Las responsabilidades operacionales pueden moverse. Un entorno de registro puede experimentar perturbaciones técnicas, financieras, jurídicas o de organización. Ninguno de esos eventos debe hacer automáticamente imposible reconstruir el estado histórico de los recursos del número de Internet. Por eso Fallacia de continuidad del Registro distingue la continuidad del libro mayor de la permanencia de la organización que la opera. La exportación del estado de la Secretaría sigue el mismo principio:

Protege la función del registro haciendo que el estado sea recuperable.

Eso es diferente de asumir que una institución debe permanecer invariable para siempre.

¿Qué debería tener un registro estatal de exportación?

Una exportación útil debe contener suficiente información para reconstruir el estado verificado pertinente del recurso. El formato técnico exacto necesitaría especificación, pero la información puede dividirse en varias categorías.

1. Información sobre los recursos del número de Internet

La exportación debe identificar claramente el recurso. Por ejemplo:

• Prefijo IPv4 ;
• Prefijo IPv6 ;
• Número del sistema autónomo;
• parentesco o relación de asignación pertinente;
• la situación de los recursos; y
• identificadores de registro aplicables.

Sin una identidad precisa de recursos, el resto de la exportación tiene poco valor. Por ejemplo:

IPv4 : 192.0.2.0/24

o:

ASN : AS64500

El recurso debe ser legible a máquina e inequívoco.

2. Información reconocida del titular

La exportación debe registrar la organización asociada al estado de registro reconocido. La información pertinente puede incluir:

• nombre de organización;
• identificador de registro;
• organización ID ;
• referencia jurídica o organizativa pertinente;
• fecha efectiva; y
• estado del registro.

Esto no significa que un registro de registro debe ser tratado como un documento de título legal universal. Significa que un sistema de continuidad necesita saber:

¿Quién reconoció el registro en el último estado verificado?

Esto proporciona una base de referencia desde la cual se pueden examinar los cambios posteriores.

3. Objetos de contacto

Los registros de los recursos de Internet suelen contener varios tipos de contactos. Estos pueden incluir:

• contactos administrativos;
• contactos técnicos;
• - los contactos de abuso;
• contactos de seguridad; y
• otros contactos operacionales.

Los sistemas actuales de registro-datos pueden exponer muchas de estas relaciones a través de WHOIS o RDAP . Sin embargo, una exportación de estado de registro debe preservar no sólo el contacto visible actual, sino suficiente información para comprender la relación verificada pertinente en el momento de la exportación. Esto se vuelve importante cuando el personal se va u organizaciones reestructuran.

4. Historial de transferencia y cambio

El estado actual es importante. La historia puede ser igualmente importante. Suponga un bloqueo IPv4 cambios de la Organización A a la Organización B. Una consulta de registro actual podría mostrar:

Organización B

Pero un sistema de continuidad también debería ser capaz de establecer:

• cuando se produjo el cambio;
• lo que era el estado anterior;
• qué tipo de cambio ocurrió;
• si la transición fue verificada;
• que la autorización la apoyaba; y
• cuando el nuevo estado entró en vigor.

Una exportación de estado de registro no necesita necesariamente exponer públicamente la información confidencial de las transacciones. Pero la arquitectura de continuidad debe preservar suficiente historia autenticada para establecer que la transición estatal ocurrió legítimamente. Esto convierte el registro de una instantánea en una libro mayor auditable.

5. Información de las delegaciones operacionales

El titular registrado y el usuario operativo de los recursos del número de Internet pueden ser diferentes. Por ejemplo: Soporte de recursos → menosor → lessee → proveedor de alojamiento → red aguas arriba Por lo tanto, un registro con capacidad de continuidad puede tener que registrar información apropiada sobre la delegación operacional reconocida. Ello podría incluir:

• prefijo delegado;
• usuario operacional;
• período eficaz;
• contactos delegados;
• la relación de enrutamiento;
• estado de autorización; y
• estado de vencimiento o terminación.

No todos los detalles comerciales necesitan convertirse en datos de registro. El objetivo es preservar la información pertinente para la coordinación de Internet. Esta distinción se explora más ampliamente en The Policy Mirror, cuando la delegación operacional se considera una realidad registrable cuando afecta materialmente cómo se utiliza o coordina el recurso. El principio importante es: El registro debe ser capaz de describir la realidad operacional legítima sin necesidad de controlar la relación comercial subyacente.

6. Información del DNS inversa

DNS inverso puede ser operacionalmente importante para un recurso IP en funcionamiento. Por consiguiente, una exportación del estado de registro podría incluir información pertinente sobre:

• delegación de la zona inversa;
• autoritative nameservers;
• Estado de la delegación;
• organización responsable; y
• historial de cambio relevante.

Para IPv4 , el DNS inverso normalmente implica el in-addr.arpa jerarquía. Para IPv6 , utiliza ip6.arpa. El DNS inverso puede afectar:

• sistemas de correo electrónico;
• análisis de seguridad;
• logging;
• solución de problemas;
• sistemas de reputación; y
• operaciones de red.

Si se requiere la continuidad del registro, no se debe olvidar el DNS inverso. Un registro de recursos que sobrevive mientras su delegación de apoyo al DNS resulta imposible de reconstruir sólo proporcionaría una continuidad parcial.

7. Metadatos relacionados con RPKI

RPKI es otra capa sensible a la continuidad. El sistema RPKI contiene certificados de recursos y objetos firmados utilizados para apoyar la información de la trucha de seguridad como Autorizaciones de Origen de Ruta. Una exportación de estado de registro no debe confundirse con simplemente copiar claves criptográficas privadas. El manejo de llave privada requiere controles de seguridad separados. En cambio, la exportación podría preservar el estado pertinente, como:

• si el servicio RPKI está habilitado;
• relaciones significativas en materia de recursos;
• información actualizada sobre el ROA ;
• de origen autorizado ASN ;
• información de longitud máxima cuando corresponda;
• metadatos de publicación;
• información pertinente sobre la situación; y
• referencias suficientes para entender el estado de seguridad actual.

El objetivo no es duplicar toda la arquitectura RPKI . El objetivo es asegurar que la planificación de continuidad sepa:

¿Qué afirmaciones de seguridad se asociaron con el recurso en el estado verificado?

Esto importa porque una transición del registro no debe crear accidentalmente problemas innecesarios de seguridad de la routa para una red legítima.

8. Controversias y situación de conflicto

Una exportación de estado de registro se vuelve especialmente valiosa cuando se disputa el recurso. Imagina que dos partes reclaman autoridad sobre el mismo recurso. Simplemente exportando:

Holder = Organización A

puede que no sea suficiente si el estado actual en sí es impugnado. La exportación debe ser capaz de representar un estado de conflicto. Por ejemplo:

• existe controversia;
• se registró una controversia de fecha;
• los recursos afectados;
• último estado indiscutible o verificado;
• actual situación administrativa;
• restricción o estado de retención pertinente;
• cuando proceda; y
• referencias al rastro de evidencia.

El propósito no es decidir la disputa automáticamente. Es evitar que la disputa desaparezca de los datos. Un buen registro debe ser capaz de decir:

Este recurso está sujeto actualmente a un conflicto registrado.

en lugar de presentar silenciosamente un lado como realidad indiscutible.

9. El último Estado Verificado

Uno de los conceptos más útiles para la continuidad del registro es el último estado verificado. Supongamos que los datos del registro actual se disputan o corrompen. El sistema debe ser idealmente capaz de reconstruir:

1. el último estado considerado válido;
2. cuando ese estado entró en vigor;
3. qué pruebas lo apoyaron;
4. los cambios ocurridos después; y
5. que cambio introdujo la incertidumbre.

Esto hace que la investigación de controversias sea mucho más precisa. En lugar de preguntar:

¿Quién controla el recurso?

la investigación puede preguntar:

“¿Cuál fue el último estado verificado, y qué evidencia apoya la transición lejos de él?”

Esa es una pregunta mucho más auditable. La exportación del estado del registro hace que este modelo sea práctico porque el estado histórico pertinente se conserva en lugar de ser sobrescrito sin contexto.

10. Registros de auditoría

La auditoría es una de las partes más importantes de una exportación significativa. Un registro de auditoría podría preservar información como:

• timetamp;
• acción;
• objeto afectado;
• valor anterior;
• nuevo valor;
• actor autenticado;
• autorización de referencia;
• estado de verificación; y
• transacción o cambio de identificador.

No todos los detalles operativos deben ser públicos. Pero las transiciones estatales críticas deben ser explicables. Una ruta de auditoría ayuda a responder:

¿Quién cambió esto?

¿Cuándo?

¿De qué?

¿A qué?

¿Con qué autoridad?

¿Con base en qué pruebas?

Esas cuestiones cobran especial importancia cuando los recursos del número de Internet apoyan la infraestructura de producción o tienen un valor operacional importante.

Registry-State Export vs RDAP

La exportación del estado de registro no debe confundirse con la RDAP . RDAP ya proporciona un importante mecanismo estandarizado para acceder a los datos de registro. Pero los objetivos son diferentes.

Característica	RDAP	Registro-Estado de exportación
Consultar datos de registro actual	Sí.	Sí, potencialmente.
Protocolo normalizado	Sí.	No actualmente como norma general de exportación INR
Máquina legible	Sí.	Debe ser
Información sobre los titulares de recursos	Sí, donde esté disponible	Sí.
Contactos	Sí, sujeto a reglas de acceso	Estado de continuidad pertinente
Historial de transferencia completo	No es su propósito primario	Potencialmente
Estado histórico	Limitada / dependiente de implementación	Debería apoyarlo.
Registros de auditoría	No es el propósito básico de RDAP	Importante
Metadatos de controversias	Depende de la aplicación	Debería apoyarlo.
Metadatos de continuidad RPKI	Sistema separado	Podría referirse al estado pertinente
Estado de continuidad del DNS	Sistema separado	Podría incluir el estado pertinente
Failover / propósito de portabilidad	No	Sí.
Restaurar estado de registro verificado	No es su propósito principal	Objetivo básico

La distinción es importante. RDAP es un protocolo de acceso a datos de registro. La exportación del estado de registro es un concepto de arquitectura de continuidad. Los dos podrían complementarse. Un futuro formato de exportación de estado de registro podría reutilizar objetos RDAP estandarizados en lugar de inventar nuevos formatos innecesarios para información que RDAP ya representa bien.

Registro-Estado de exportación es más que un respaldo

Una base de datos responde:

¿Podemos restaurar esta base de datos?

Una exportación de estado de registro pide:

¿Se puede reconstruir independientemente el estado de registro legítimo de este recurso?

Esos son objetivos diferentes. Un respaldo tradicional puede:

• depende del software de base de datos propietario;
• contener datos para cada cliente;
• exigir la infraestructura de registro original;
• utilizar relaciones internas indocumentadas;
• contener información confidencial innecesaria; o
• ser difícil para un titular de recursos verificar independientemente.

En lugar de ello, una exportación de un registro de nivel de recursos debería ser:

• .
• autenticado;
• comprensible;
• legible por máquina;
• verificable;
• portátiles; y
• suficiente para la continuidad.

Eso lo hace más cerca de un paquete de continuidad para el recurso que una copia de seguridad de servidor convencional.

¿Por qué los titulares de recursos pueden necesitar la exportación del Registro-Estado

Un operador de red rara vez piensa en la falla del registro cuando todo está funcionando normalmente. Pero la infraestructura crítica debe diseñarse también para situaciones anormales. Los posibles eventos de continuidad pueden incluir:

• corrupción de bases de datos;
• - Extensión técnica ampliada;
• incidente de ciberseguridad;
• reestructuración de la organización;
• la insolvencia;
• pérdida de personal clave;
• registros controvertidos;
• migración de servicios; o
• transición a una plataforma sucesora.

This does not imply that any particular registry is expected to fail. El mismo principio de resiliencia se aplica en toda la ingeniería de infraestructura: Si una función es importante, su camino de recuperación debe diseñarse antes de que ocurra el fracaso. Las redes mantienen copias de seguridad. Las bases de datos utilizan la replicación. DNS utiliza múltiples servidores autorizados. Routing utiliza caminos redundantes. Los sistemas de nube utilizan múltiples zonas de disponibilidad. La información del registro crítico merece la misma pregunta arquitectónica:

¿Cuál es el camino de recuperación?

Cómo el Registro-Estado de Exportación apoya la Portabilidad

La portabilidad se hace difícil cuando toda evidencia del estado actual de un recurso existe sólo dentro del sistema interno de un proveedor. Un sistema sucesor tendría que reconstruir el recurso de pruebas incompletas. Eso puede introducir incertidumbre sobre:

• - la identidad del titular;
• contactos;
• transferencias históricas;
• autorización;
• delegación operacional;
• RPKI state;
• DNS inversa;
• controversias; y
• cambios verificados previos.

Una exportación estandarizada y autenticada del estado del registro podría reducir este problema. Conceptualmente, la portabilidad podría funcionar como: Registro actual ↓ Exportación autenticada del estado del registro ↓ Verificación independiente ↓ Sistema de registro sucesor o continuidad calificado ↓ Identidad de los recursos y continuidad de los servicios El objetivo no es la duplicación incontrolada. Todavía debe haber un estado activo reconocido con fines de singularidad. La portabilidad debe preservar la singularidad, no socavarla.

Exportar no significa que dos registros pueden reclamar el mismo recurso

Esta es una limitación importante. La portabilidad del estado del registro no debe crear registros activos duplicados. Internet todavía necesita singularidad. Un modelo de failover necesita reglas para:

• qué estado de registro es autorizado;
• cuando se produce un desencadenante de continuidad;
• cómo se superpone el registro anterior;
• cómo se detectan los estados conflictivos;
• cómo se registra la transición; y
• cómo los sistemas de confianza descubren al sucesor reconocido.

Un archivo copiado solo no resuelve estas preguntas. La arquitectura necesita un mecanismo estatal de transición. El objetivo de la exportación es proporcionar las pruebas y los datos necesarios para ese mecanismo. No debe crear registros competidores para el mismo recurso.

¿Cómo sería una exportación autenticada?

Una útil exportación del estado de registro no debe ser una hoja de cálculo editable sin manera de verificar su origen. Un futuro diseño técnico podría utilizar potencialmente:

• JSON estructurado;
• objetos compatibles con RDAP estandarizados;
• Firmas criptográficas;
• timetamps;
• objeto hashes;
• números de versión;
• identificadores de cambio inmutables; y
• manifiestos de exportación verificables.

Por ejemplo, una exportación podría contener conceptualmente:

Campo	Ejemplo de propósito
Recursos	Identifique IPv4 , IPv6 o ASN
Secretaría	Identificar el registro fuente
Versión de exportación	Identificar la versión de formato
Tiempos de exportación	Establece tiempo
Objeto del titular	Titular reconocido
Contactos	Preserve contactos relevantes
Estado de registro	Preserve resource state
Historial de transferencia	Explicar las transiciones anteriores
Delegaciones	Relaciones operacionales récord
DNS inversa	Preserve relevant delegation state
Metadatos de RPKI	Describir el estado relacionado con la seguridad
Situación de los conflictos	Información sobre conflictos
Actos de auditoría	Explicar cambios materiales
State hash	Detectar modificaciones
Firma digital	Autentizar el exportador

La especificación precisa requeriría el diseño técnico y el examen comunitario. Pero el objetivo del diseño debe ser claro:

Un receptor debe poder verificar de dónde proviene la exportación y determinar si ha sido alterado.

¿Con qué frecuencia debe exportarse el Estado del Registro?

Hoy no hay intervalo universal porque la exportación del estado del registro no es un sistema operativo estandarizado. Una futura aplicación podría considerar las exportaciones:

• periódicamente;
• después de los principales cambios en los recursos;
• después de las transferencias;
• después de los cambios de organización;
• después de importantes cambios de delegación;
• después de que RPKI cambie;
• cuando comienza una disputa;
• antes de la migración del registro; y
• cuando ocurren eventos definidos de riesgo de continuidad.

La frecuencia correcta depende de lo rápido que el estado cambie. Un recurso que ha permanecido estático durante diez años tiene necesidades diferentes de una cartera con transferencias frecuentes y delegaciones. El objetivo debe ser mantener la exportación lo suficientemente reciente como para que pueda servir como prueba de continuidad significativa.

¿Quién debería ser capaz de recibir una exportación?

No todos los campos de registro deben ser necesariamente públicos. La privacidad, la seguridad y la confidencialidad siguen siendo importantes. Una arquitectura de estado de registro podría distinguir entre:

Datos del registro público

Information already intended for public coordination.

Datos sobre la continuidad de los recursos

Información adicional disponible para un titular de recursos autenticado.

Datos de garantía o registro sucesor

Información almacenada bajo condiciones controladas para fines de continuidad.

Pruebas restringidas

Registros sensibles disponibles sólo bajo autorización definida, disputa o procedimientos legales. Este enfoque con capas puede apoyar la continuidad sin convertir cada registro interno en datos públicos. El objetivo es portabilidad del estado necesario, no publicación indiscriminada.

Registry-State Export and Independent Escrow

La exportación se hace más fuerte cuando se combina con el escrow independiente. Si la única copia de una exportación de continuidad se almacena en la misma infraestructura que la base de datos del registro, ambos pueden fallar juntos. Por lo tanto, una arquitectura de continuidad podría preservar versiones autenticadas con un servicio independiente de garantía bloqueada o un mecanismo equivalente. Ese sistema podría mantener:

• versiones periódicas;
• integridad criptográfica;
• timetamps;
• historial de retención;
• control de acceso; y
• condiciones de liberación definidas.

Esto crea separación entre: funcionamiento del registro y: preservar las pruebas necesarias para restablecer la función del registro. La separación es valiosa porque la continuidad no debe depender enteramente del mismo dominio del fracaso.

Registro-Estado de exportación y continuidad RPKI

RPKI requiere atención especial. El sistema RPKI tiene su propia jerarquía de certificados, claves, repositorios de publicación y objetos firmados. Por consiguiente, la exportación de un estado de registro debería no ser tratado como un sustituto informal de la arquitectura criptográfica de RPKI . En cambio, la planificación de la continuidad necesita procedimientos explícitos de sucesión RPKI . Esos procedimientos pueden tener que responder:

• ¿Qué pasa con los certificados existentes?
• ¿Qué pasa con los ROA s publicados?
• ¿Cómo preserva o restablece una autorización válida un sucesor?
• ¿Cómo se manejan objetos revocados o superpuestos?
• ¿Cómo se comunica la transición a las partes que confían?

Una arquitectura de registro-continuidad debe trabajar con los mecanismos existentes de RPKI en lugar de intentar reemplazarlos. El principio sigue siendo: La continuidad de la Secretaría debe incluir la continuidad de la seguridad.

Continuidad DNS de la exportación del Estado del Registro y la

El mismo principio se aplica al DNS inverso. Un recurso puede permanecer debidamente registrado mientras que su DNS inverso no está disponible porque la información de la delegación no se conserva durante una transición. Por consiguiente, es necesario considerar un plan de continuidad completo:

• delegación de la zona inversa;
• nameserver information;
• autorización pertinente;
• tiempo de transición; y
• operación sucesora.

Esto demuestra por qué la continuidad del registro es más amplia que restaurar un servidor WHOIS o RDAP . El recurso tiene varias dependencias. Un sistema de continuidad debe entenderlos.

Lo que la exportación del Estado del Registro no debe hacer

Una exportación centrada del estado de registro no debe tratar de convertirse en una base de datos universal de todo lo que implica un recurso de número de Internet. No necesita contener:

• planes de negocio de clientes;
• fijación de precios;
• - Estrategia comercial confidencial;
• cada configuración de red;
• tráfico de clientes;
• datos de aplicación;
• datos de cumplimiento no relacionados; o
• cada contrato con la organización.

Eso haría que la capa de coordinación fuera innecesariamente gruesa. En cambio, la exportación debería centrarse en la información realmente necesaria para preservar: singularidad control verificado exactitud del registro garantías de seguridad delegación del Estado auditabilidad Visión de controversias y: continuidad Esto es consistente con el modelo de coordinación delgada descrito en Primacía del departamentoUna exportación de continuidad debe ser lo suficientemente fuerte para proteger la función del registro sin convertirse en un repositorio para un control de organización no relacionado.

Una lista de verificación práctica de la exportación del Estado

Una exportación lista para la continuidad debe permitir que un revisor autorizado responda:

Recursos

• ¿Qué recurso IPv4 , IPv6 o ASN está involucrado?
• ¿Está identificado el recurso?

Holder

• ¿Quién es el último titular reconocido verificado?
• ¿Cuándo se estableció ese estado?

Contactos

• ¿Qué contactos son relevantes?
• ¿Son corrientes?

Historia

• ¿Qué cambios de estado material ocurrieron?
• ¿Se pueden reconstruir estados anteriores?

Transferencia

• ¿Se ha transferido el recurso?
• ¿Está disponible el historial de transición?

Delegación

• ¿Hay una delegación operacional pertinente?
• ¿Cuál es su estado actual?

Routing and security

• ¿Qué información de autorización relacionada con el enrutamiento importa?
• ¿Qué estado relevante de RPKI existe?

DNS inversa

• ¿Qué delegación de DNS inversa está asociada con el recurso?

Controversias

• ¿El recurso está actualmente en disputa?
• ¿Cuál fue el último estado verificado?

Auditoría

• ¿Quién hizo cambios materiales?
• ¿Cuándo?
• ¿Bajo qué autoridad verificada?

Autenticidad

• ¿La exportación está autenticada digitalmente?
• ¿Se puede detectar la modificación?

Recuperación

• ¿Podría la información apoyar un proceso legítimo de continuidad o sucesor?

Si la respuesta a la pregunta final es no, el archivo puede ser una exportación de datos, pero todavía no es significativo continuidad de las exportaciones.

Conclusión

Los registros del número de Internet cumplen una función que importa. Ayudan a preservar identificadores únicos a nivel mundial. Mantienen registros de recursos. Publican contactos. Apoyan la historia de transferencia. Interaccionan con DNS inverso y sistemas de seguridad de enrutamiento. Ayudan a las redes independientes a entender el entorno de número-recurso que comparten. Debido a que esas funciones importan, deben diseñarse para la continuidad. La exportación del estado de registro es una forma de pensar en ese requisito. Hace una simple pregunta de infraestructura:

Si el sistema de registro actual no está disponible, ¿todavía tenemos suficiente información autenticada para entender el estado legítimo del recurso?

Una respuesta seria requiere más que un registro actual de la WHOIS . Requiere:

• identidad de los recursos;
• reconocido Estado titular;
• contactos;
• historia material;
• c) Registros de transferencia;
• información de las delegaciones;
• Estado de seguridad;
• inversa DNS información;
• metadatos de conflictos;
• auditabilidad; y
• evidencia autenticada.

Esto no significa que ningún registro en particular se espera que falle. Significa que los sistemas importantes deben tener vías de recuperación. Internet aplica ya este principio a la routing, DNS , almacenamiento, bases de datos e infraestructura en la nube. La capa de recursos pueden beneficiarse del mismo pensamiento de resiliencia. La función de registro debe mantenerse recuperable a medida que evolucionan las tecnologías, las plataformas y las organizaciones. El libro debe seguir siendo comprensible. El recurso debe seguir siendo único. Y las redes de funcionamiento deben ser capaces de preservar la continuidad a medida que los sistemas que les rodean cambien.