Resumen

  • Una DNS Catalog Zone enumera zonas miembro y propiedades dentro de una zona DNS ordinaria. El consumidor interpreta esa lista como configuración y puede añadir, quitar o modificar servicio de forma automática; los datos autoritativos de cada miembro llegan por su propia transferencia.
  • Autenticar AXFR o IXFR demuestra la procedencia de la transacción observada. No demuestra que el inventario del productor sea correcto, que el nombre esté admitido localmente ni que el catálogo sea dueño del estado que pretende borrar.
  • La defensa operativa combina validación de versión 2, alcance local de miembros, registro de origen por catálogo y etiqueta, vista previa de cambios masivos, archivo recuperable, protocolo explícito para coo y sondas que comprueban lo que cada servidor realmente responde.

Poder remoto sin acceso remoto

RFC 9432 contempla una relación peculiar: el primario del catálogo y los secundarios consumidores pueden pertenecer a administradores distintos. El productor publica una zona; el consumidor la transfiere y, porque fue configurado para interpretarla, modifica su propio conjunto de zonas servidas. El productor no necesita una cuenta del sistema operativo ni una sesión en el panel del secundario.

La separación es valiosa. Un proveedor de DNS secundario puede incorporar miles de zonas sin repetir configuraciones manuales. Un cambio de inventario se distribuye con mecanismos DNS conocidos. El mismo diseño desplaza el control de qué zonas se sirven desde el operador del servidor hacia quien controla el contenido del catálogo.

El RFC no oculta esa transferencia. Después de describirla, recomienda que el consumidor limite los miembros admisibles con cualquier método apropiado: una expresión regular, otra base de datos o una política equivalente. Ese filtro es la frontera entre recibir un mensaje de un productor conocido y permitir que ese productor programe toda la superficie del servidor.

Una lista de configuración no es una copia de la zona

El catálogo utiliza PTR bajo zones para nombrar miembros. Cada miembro tiene una etiqueta única a la que se pueden asociar propiedades. La versión del esquema se anuncia en un TXT único con valor 2. Todo ello viaja como una zona DNS normal.

Sin embargo, el catálogo no lleva el contenido de example.net. No contiene sus direcciones, sus MX ni su material DNSSEC autoritativo. Una vez creado el miembro en el consumidor, otra transferencia obtiene esos datos desde los primarios configurados.

Esto divide la operación en dos planos. El plano de aprovisionamiento decide que el secundario debe conocer una zona. El plano autoritativo decide qué registros debe responder. Ver un IXFR exitoso del catálogo no demuestra que la transferencia del miembro terminó, que la zona se cargó o que todos los nodos anycast responden la versión esperada.

También explica por qué NOTIFY no equivale a autoridad de configuración. Un secundario puede recibir una notificación del miembro antes de que su catálogo lo haya admitido. La notificación acelera una comprobación; no crea el miembro ni supera la política local.

La escalera de cinco verificaciones

Primero se comprueba la forma. Debe existir exactamente una versión admitida. Un RRset PTR de miembro debe contener un solo destino. Dos etiquetas no pueden anunciar el mismo miembro. Una propiedad conocida con forma imposible rompe el catálogo. Un registro no soportado se ignora; no recibe semántica por intuición.

Luego se comprueba la procedencia. TSIG protege la autenticación de transacciones DNS. XFR sobre TLS puede proteger el canal y mantener confidencial una lista que revela clientes, zonas y propiedades. Estas garantías son decisivas frente a modificaciones inesperadas, pero solo llegan hasta el par configurado y el mensaje recibido.

La tercera verificación es la admisión. ¿Puede este productor aprovisionar este nombre en este consumidor? Una organización puede permitir únicamente un sufijo, una cartera contratada o una lista cruzada con su sistema comercial. La respuesta no está en el MAC de TSIG.

La cuarta es la titularidad del estado local. ¿Fue este catálogo el que creó la zona, los archivos, diarios, temporizadores y claves que ahora propone retirar o entregar? Sin ese dato, el borrado puede afectar una configuración independiente.

La quinta es la realidad de ejecución. ¿Qué versión del servidor aplicó el cambio? ¿Qué rechazó? ¿Se transfirió el miembro? ¿Qué responden las direcciones autoritativas desde fuera? Un registro administrativo y un paquete DNS no son la misma capa.

Dos tipos de catálogo que exigen respuestas distintas

Un catálogo roto contiene una contradicción definida por el protocolo: versión ausente o no admitida, PTR duplicado, propiedad conocida inválida. El consumidor no debe procesarlo. Si la versión anterior era válida, no debe retirar ni reconfigurar las zonas existentes; tras un reinicio debería seguir sirviendo el último estado válido.

Un catálogo peligroso puede no estar roto. Una lista vacía con versión 2 es legal. Una lista que elimina 50.000 miembros también puede ser legal. El generador pudo leer una tabla vacía, aplicar un filtro al revés o confundir la baja de un producto con la baja de una zona.

Por eso el control semántico debe examinar el diferencial normalizado antes de ejecutarlo. Cuente altas, bajas, cambios de etiqueta, grupos y extensiones. Compare sufijos, clientes, ventanas de cambio y una fuente independiente. Bloquee el catálogo vacío inesperado y cualquier retirada que supere un umbral ajeno al productor.

No se trata de pedir a un comité que interprete el RFC. Se trata de conservar la decisión futura en el lugar donde ocurre la consecuencia, tal como exige la idea de Localized Future Decision de Heng Lu.

El derecho a borrar tiene un origen concreto

La regla de retirada de RFC 9432 es más estrecha que una lectura superficial. Si una zona desaparece de un catálogo, el consumidor solo debe eliminarla y destruir su estado asociado cuando esa misma zona fue configurada inicialmente desde ese mismo catálogo. Si la zona nació por configuración estática u otro catálogo, la retirada entrante carece de ese alcance.

El consumidor necesita, por tanto, un libro de procedencia. Debe unir nombre, catálogo de origen, etiqueta del miembro, primera serie aceptada, perfil aplicado y almacenes creados. La mera presencia actual del nombre no demuestra quién puede quitarlo.

El RFC permite considerar un archivo temporal para recuperar errores. Ese archivo debe ser real y probado. ¿Incluye el archivo de zona? ¿El diario? ¿Las claves DNSSEC? ¿Los contadores o metadatos del producto? ¿Quién puede restaurarlo y durante cuánto tiempo? Mantener secretos sin fecha aumenta exposición; purgarlos de inmediato convierte una lista errónea en una pérdida permanente.

Un rollback que solo repone el PTR puede no recuperar nada. Si el producto ya eliminó el estado, el miembro reaparece como una creación nueva y deberá reconstruirse desde sus primarios, quizá sin las mismas claves ni historia.

coo: migrar nombre no es decidir custodia

La propiedad Change of Ownership coordina el traslado entre catálogos. El catálogo antiguo señala al nuevo. El consumidor espera que el nuevo publique también el miembro y vuelve a verificar la señal del antiguo antes de cambiar la propiedad. Es un acuerdo de dos observaciones, no una orden unilateral del destino.

La etiqueta única decide qué ocurre con el estado. Si el nuevo catálogo conserva la misma etiqueta, puede asumir el estado asociado. Si el antiguo propietario no desea esa entrega, debe provocar un reset mediante un cambio de etiqueta antes o al mismo tiempo que coo.

Así, “mover la zona” es una instrucción incompleta. Hay que decidir por separado el contenido transferido, los diarios, temporizadores, claves y datos privados del software. La continuidad puede reducir tiempo de recuperación, pero también puede cruzar una frontera entre organizaciones con material que nunca se pretendió compartir.

La auditoría debe registrar ambos catálogos, sus series, la señal todavía vigente, la etiqueta anterior y posterior y la decisión explícita sobre cada clase de estado.

Los grupos no son leyes universales

group permite que el productor anuncie un tratamiento distinto para ciertos miembros. Su cadena no tiene significado predefinido. El consumidor decide qué valores conoce, a qué perfil local corresponden y cómo actúa ante varios valores. Los desconocidos deben ignorarse.

Las propiedades bajo ext pertenecen al espacio privado. Su significado depende de cada implementación. IANA registra los prefijos comunes de versión 2—zones, version, coo, group y *.ext—pero la existencia del registro no convierte una extensión en autoridad interoperable.

Este diseño mantiene delgada la capa común. La sintaxis compartida ofrece coordinación y fallos deterministas. El acuerdo bilateral ofrece semántica adicional. El consumidor conserva la opción de no adoptar, ignorar o limitar. La publicación es una propuesta de estado; el código que la valida y ejecuta es la adopción real.

Tres productos, tres superficies operativas

BIND documenta que los cambios del catálogo se aplican para crear, retirar o reconfigurar miembros. Admite las versiones 1 y 2, el reset mediante etiqueta y coo. También ofrece un intervalo mínimo entre aplicaciones. Ese intervalo reduce velocidad, no verifica intención.

Knot DNS asocia grupos con perfiles configurados localmente y advierte que un miembro retirado se purga de inmediato, incluidos archivo, diario, temporizadores y claves DNSSEC, con la excepción de archivo que documenta. Una actualización puede además provocar una recarga más amplia de zonas. El radio de acción depende del producto.

PowerDNS documenta funciones de productor y consumidor para versión 2, además de coo, varios grupos y un valor único que señala reset. Los backends y propiedades soportados tienen sus propios límites.

Una flota mixta no puede auditarse con una casilla «RFC 9432 compatible». Necesita experimentos por versión: catálogo roto, catálogo vacío, colisión de nombre, grupo desconocido, retirada, cambio de etiqueta, migración incompleta, reinicio y restauración. La primacía del código en ejecución exige observar cada resultado y no atribuir al RFC lo que hace un binario particular.

La evidencia mínima para ejercer autoridad

Por cada serie conserve el hash del catálogo y un diferencial normalizado; productor y transporte; resultado de estructura; regla de admisión; origen y etiqueta de cada miembro; colisiones y propiedades ignoradas; aplicación por consumidor; transferencia y carga del miembro; y sondas autoritativas externas.

Para una baja añada el inventario de estado, el identificador del archivo, la hora de purga y la fecha límite de recuperación. Para coo, añada la observación de ambos lados, la continuidad o reset de etiqueta y la decisión de custodia. Los secretos y el catálogo completo no deben filtrarse a registros de uso general.

La prueba debe reconstruir la secuencia sin saltos: el productor habló; el canal estableció procedencia; el consumidor admitió; el catálogo tenía o no autoridad sobre el estado; el software ejecutó; el DNS servido produjo una consecuencia.

Fuentes