Resumen

  • La zona catálogo es un artefacto de configuración ejecutable: puede decidir qué zonas miembro aparecen o desaparecen de un conjunto de servidores autoritativos.
  • La autenticación protege la procedencia del cambio, no su intención; por eso la aceptación requiere inventario independiente, límites del consumidor, conservación del estado y consultas reales.

El caso más peligroso no necesita un paquete corrupto. Basta con una generación impecable.

Imaginemos que el proceso que compone el catálogo termina sin errores. Publica SOA y NS, escribe una sola versión 2, incrementa el serial y entrega la zona mediante una transferencia autenticada. El consumidor no encuentra PTR duplicados ni propiedades imposibles. Tampoco encuentra miembros.

El conjunto válido es cero.

RFC 9432 diferencia esa situación de un catálogo roto. Si la estructura estuviera mal, el consumidor conservaría los miembros de la última generación válida. Si la estructura es correcta y los miembros han desaparecido, debe retirar las zonas que nacieron de ese mismo catálogo, junto con su estado asociado. El propio RFC advierte que un script que produzca un catálogo vacío puede hacer desaparecer millones de zonas de los secundarios en segundos. La advertencia ilustra el mecanismo; no documenta un incidente concreto.

La paradoja es útil: el canal puede demostrar perfectamente quién envió la orden mientras el sistema sigue sin saber si la orden refleja la realidad comercial y operativa.

Transferir una lista que cambia la máquina

AXFR e IXFR solucionan la sincronización de los registros de una zona. No solucionan el alta de esa zona en todos los servidores que deben alojarla. Sin una capa adicional, un operador añade la zona al primario y después modifica la configuración de cada secundario.

La zona catálogo transporta esa capa. Sus PTR bajo zones.$CATZ nombran zonas miembro; una etiqueta única permite asociar propiedades. Al recibir una actualización, el consumidor puede crear o eliminar configuraciones automáticamente. Después solicita los datos de cada miembro y empieza a servirlos.

Ese orden importa. El catálogo no prueba el contenido de la zona miembro. Tampoco prueba que la delegación del padre sea correcta. Decide primero si el consumidor incorporará la zona a su perímetro de servicio. Es una orden sobre configuración que viaja dentro de un contenedor DNS.

RFC 9432 reconoce la transferencia de poder: el control administrativo de las zonas servidas pasa al propietario del catálogo. A la vez, aconseja que el consumidor limite los nombres admisibles, ya sea con patrones o con una comprobación contra otra base. El formato común no elimina la autonomía local; la vuelve comprobable.

Tres negativas que no deben mezclarse

Un catálogo puede ser estructuralmente inválido. Falta la versión, hay más de una, la versión no es compatible, dos etiquetas apuntan al mismo miembro o una propiedad conocida tiene una cardinalidad ilegal. El consumidor no procesa esa generación. Si el catálogo antes era correcto, mantiene las zonas existentes; si expira, deja de interpretarlo sin borrar el mundo.

Un catálogo también puede ser auténtico pero no autorizado para un miembro. El nombre está bien formado y llegó desde el productor esperado, pero no pertenece al contrato, al cliente o al segmento que el consumidor está dispuesto a aceptar.

Por último, un catálogo puede ser autorizado y aun así tener un cambio operacionalmente inaceptable: demasiadas bajas de una vez, pérdida no prevista de claves o divergencia entre cohortes de software.

Estas tres negativas requieren razones diferentes. BROKEN protege la gramática. La autenticación protege la custodia del mensaje. La política local protege el perímetro y el impacto. Sustituirlas por un único semáforo verde entrega al productor más autoridad de la que el protocolo necesita.

Una etiqueta sin significado que conserva la historia

La etiqueta única de cada miembro no es un identificador jurídico. Sin embargo, su continuidad determina el tratamiento del estado. Cambiarla significa retirar y volver a añadir la zona. El consumidor puede eliminar datos, claves DNSSEC, diarios y temporizadores asociados antes de recrearla.

Para migrar entre catálogos, coo permite que el antiguo señale al nuevo. El consumidor espera a que la zona exista en el destino y vuelve a confirmar la señal de salida. Si se conserva la etiqueta, el nuevo propietario del catálogo puede heredar el estado. Si cambia, el estado se reinicia.

De ahí que una revisión basada solo en el nombre del dominio sea incompleta. Debe comparar etiqueta, catálogo de origen, propiedades y destino de cada pieza de estado. Un cambio de un registro puede equivaler a una sustitución de identidad operacional.

La migración sin soporte homogéneo para coo añade otra carrera. La adición puede llegar antes que la retirada. El consumidor detecta una colisión y descarta el nuevo miembro. El RFC no define una recuperación universal; puede hacer falta esperar la retirada y forzar otra transferencia. La coordinación termina donde comienza la evidencia de la implementación.

El mismo RRset no produce el mismo servicio

group no es un lenguaje de política compartido. Su significado se acuerda entre las partes. Un valor desconocido se ignora; si hay varios, una implementación puede usar todos, algunos o ninguno. Las extensiones privadas bajo *.ext tampoco prometen interoperabilidad.

Las guías oficiales muestran consecuencias distintas. BIND organiza catálogos por vista y ofrece un intervalo mínimo de aplicación. PowerDNS exige determinados backends y declara límites en plantillas de grupo y extensiones. Knot DNS recomienda validación externa, documenta purga inmediata de miembros retirados en su implementación actual y expone restricciones al migrar metadatos.

Por eso un expediente de cambio debe registrar el software, la versión, la vista o plantilla, los valores reconocidos, la persistencia y el resultado final. Comparar únicamente el hash del catálogo demuestra igualdad de entrada, no igualdad de interpretación.

La criptografía protege el camino, no la decisión

TSIG autentica e integra transacciones entre entidades que comparten una clave. En una transferencia de varios mensajes encadena la verificación a lo largo de la sesión. XFR sobre TLS puede proteger además la confidencialidad y autenticar los extremos. Es importante porque el catálogo revela qué zonas sirve un proveedor y, quizá, cómo las clasifica.

Ninguna de esas propiedades interroga la fuente del generador. La clave no sabe si una consulta devolvió cero filas por un fallo. TLS no sabe si un lote de bajas incluyó a todos los clientes. La entrega exacta de una decisión equivocada sigue siendo una entrega exacta.

La cadena de prueba empieza antes del catálogo: instantánea del inventario autorizado, identidad del cambio, recuento esperado, versión del generador y hash de entrada/salida. Continúa con serial, diff semántico, etiquetas, propiedades, identidad del canal y veredicto local. Termina con la configuración cargada, AXFR/IXFR de cada miembro, SOA y claves, respuestas directas desde cada segmento y estado de la delegación padre.

Si el padre sigue publicando NS y un secundario ya no sirve la zona, el catálogo no ha «limpiado» la delegación: ha creado un destino sin autoridad efectiva. El impacto público se prueba con respuestas, no con el éxito de la transferencia del catálogo.

Fuentes