Exportar y documentar una zona DNS: conservar el origen y registrar las brechas

Delimitar qué representa la exportación

Anota la zona, su alcance público o privado, el proveedor, el formato y el método autorizado antes de organizar una exportación posterior. Pregunta qué conjuntos y ajustes incluye el método documentado. Un archivo descargable, un hash coincidente o la aceptación de un analizador no responden por sí solos si la cobertura es completa, las funciones equivalentes o la restauración exitosa.

Conserva el original en almacenamiento protegido y autorizado. Si después se obtiene con autorización, registra la fecha, hora y zona horaria reales, método, tamaño en bytes y hash; no inventes esos datos a partir de un ejemplo. Edita una copia de trabajo separada. Preserva los comentarios relevantes y la procedencia: no todos los comentarios son prescindibles.

Empezar con un registro de evidencia en blanco

Portada: referencia de zona/alcance ____; proveedor de origen y documentación fechada ____; responsable y método autorizados ____; momento y zona horaria reales del origen ____; ubicación protegida, bytes y hash si se obtuvo ____; copia de trabajo ____; destino, modo de importación y documentación vigente ____; conjuntos esperados, registros individuales y exclusiones ____. Lo que no esté disponible queda como desconocido.

Ficha del anexo: función o cuestión de autoridad ____; documentación de origen y destino con fecha ____; comprendida, requiere conversión, no compatible o desconocida ____; diferencia esperada ____; responsable ____; criterio y evidencia de aceptación posterior, autorizada por separado ____. Una expectativa documentada no es una operación aceptada.

Leer por separado las reglas de origen y destino

La página de Cloudflare, actualizada el 16 de abril de 2026, documenta comentarios en línea y etiquetas reservadas cf- exportadas. cf-proxied:true y cf-proxied:false describen registros con proxy y solo DNS. Al importar, la etiqueta de cada registro tiene prioridad sobre la selección general; si falta, se aplica la selección general. Conserva ese contexto sin suponer que otro proveedor lo interpreta o ofrece un proxy equivalente.[2]

En su flujo documentado de importación, Cloudflare admite $ORIGIN, $TTL y $GENERATE, pero no $INCLUDE. La guía del portal Azure, actualizada el 11 de agosto de 2026, admite $ORIGIN y $TTL y rechaza $GENERATE y $INCLUDE. Que un archivo sea adecuado para un importador no lo hace adecuado para otro. Antes de operar, revisa producto, modo y límites vigentes.[2][1]

Azure distingue crear una zona al importar de combinar con una existente. En la combinación documentada suele conservarse el TTL del conjunto existente; un CNAME puede reemplazar otro CNAME, mientras que, ante conflictos con otro tipo, se conserva el registro existente. El host SOA y los datos NS del ápice siguen bajo control del proveedor; la guía distingue su comportamiento de otros parámetros SOA y del TTL NS del ápice. También puede cambiar la estructura de cadenas TXT. Son cuestiones de conversión acotadas, no prueba de restauración.[1]

Copper Lantern Archive: contar la evidencia que falta

Cuatro representados + uno específico + uno desconocido = seis filas esperadas. Cuatro + uno = cinco conjuntos presentes; seis − cinco = uno ausente. Se cuentan conjuntos, no líneas de archivo ni registros individuales. SOA y NS del ápice se excluyen deliberadamente y se anotan aparte. Los marcadores no son direcciones, políticas SPF ni valores de verificación válidos para publicar.

Separar brechas abiertas y expectativas de autoridad

G1: el texto de R3 está presente, pero la semántica del proxy en destino sigue sin resolver. Una fila CNAME no demuestra equivalencia funcional. G2: R6 falta en el origen descrito; la nota indica que hace falta evidencia, no autoriza publicar un valor. Lena debe conseguir evidencia de cobertura aprobada y una decisión sobre la función en destino. Dos brechas abiertas mantienen en espera, HOLD, la integridad y equivalencia exacta.

A1: el host SOA queda bajo control del proveedor. A2: también los datos NS del ápice. Son dos expectativas documentadas de conversión en destino, fuera de los seis conjuntos de aplicación/correo; no son filas ausentes adicionales ni conversiones realizadas. Cambiar la delegación requiere su propio plan autorizado. El archivo no demuestra continuidad del correo ni disponibilidad web.[1]

Definir la pregunta de aceptación posterior

Antes de una importación autorizada por separado, documenta producto y modo de destino, creación o combinación, límites pertinentes de directivas y tamaño, conflictos, conversiones y evidencia que aceptará cada responsable. Archivo y hash identifican bytes; la aceptación del analizador trata la sintaxis en ese contexto. Ninguno cierra G1/G2 ni demuestra autoridad, correo, proxy o servicios funcionando.

No etiquetes el paquete como respaldo completo de la cuenta. Cuentas, credenciales, claves privadas y configuración de servicios necesitan sus propios acuerdos autorizados de recuperación. Documenta qué ajustes están representados o referenciados; no supongas que toda exportación omite todas las funciones ni que alguna las contiene todas.

Entregar una decisión documental acotada

Entrega la referencia al original intacto, el inventario separado, el anexo de funciones/autoridad, exclusiones, responsables y criterios de aceptación posterior. Marca cada cuestión documentada, pendiente de evidencia o aceptada solo con respaldo fechado. En el caso ficticio el resultado sigue en espera, no autoriza importar. La secuencia del cambio, las dependencias del correo y la decisión de TTL pertenecen a sus guías vinculadas.