Resumen

  • ISC presentó en APNIC 62 la lista de zonas y la detección de números de serie distintos como funciones DNS actuales de Stork. Las fuentes no prueban un despliegue productivo de APNIC ni un incidente real de desactualización.
  • La señal solo abarca los servidores, vistas y configuraciones que Stork logró descubrir y capturar. Cero diferencias no equivale a cobertura total si hubo fallos, exclusiones, vistas no compatibles o datos almacenados demasiado antiguos.
  • Cada comparación debería conservar versiones, alcance esperado y observado, estado y hora de captura, valores SOA sin resumir, límite de vigencia y decisión aplicada a cada ausencia.

Un panel no cuenta lo que quedó fuera

Comparar números de serie en una sola pantalla es una mejora concreta. Si la misma zona aparece con dos valores SOA, el operador obtiene una pista inmediata de que las copias no están en el mismo punto. En la presentación de Stork en APNIC 62, Marcin Siodelski incluyó el listado y filtrado de zonas, el visor y la detección de diferencias de serie entre las capacidades disponibles. El resumen publicado por APNIC destacó la misma función.

El peligro no está en la fila marcada. Está en interpretar las filas que nunca aparecieron.

Stork construye su vista mediante agentes. El agente debe reconocer el proceso del servidor DNS, localizar la configuración que ese proceso usa y acceder a las interfaces necesarias. Según la documentación de Stork 2.4.1, BIND 9 no figura como demonio detectado si el agente no consigue encontrar su configuración. Además, el canal de estadísticas es obligatorio para obtener la lista de vistas y zonas que alimenta el visor. PowerDNS se integra mediante su configuración y API web.

Nada de eso convierte una ausencia en una avería. El sistema puede estar deliberadamente fuera del alcance de monitorización; un permiso puede ser restrictivo por diseño; una interfaz puede no estar habilitada. Pero el resultado debe conservar esa frontera. «No hubo diferencias entre lo observado» es una afirmación válida. «Todos nuestros servidores coinciden» exige demostrar que el conjunto observado coincide con el conjunto esperado.

La captura tampoco es continua. En Stork 2.4.1, la lista de zonas se guarda en la base de datos de Stork. Empieza vacía, el operador pulsa Fetch Zones y debe repetir esa acción para actualizarla. Los fallos quedan disponibles en Fetch Status. Por rendimiento, la lista no se renueva automáticamente. El momento de la captura forma parte del dato.

La propia interfaz ofrece dos denominadores. Zone Configs Count cuenta configuraciones: el mismo nombre en varias vistas aparece varias veces. Distinct Zones cuenta nombres distintos y reduce esas vistas a una sola zona. Una comparación que no conserve ambos números no permite saber si cambió el catálogo de nombres o la cantidad de contextos en que cada nombre se sirve.

Las vistas son una frontera operativa, no un adorno. Cuando Stork pide por AXFR el contenido de una zona BIND ubicada en una vista no predeterminada, necesita una clave TSIG que permita a BIND escoger la vista correcta. Las reglas match-clients y allow-transfer intervienen en esa selección. Para PowerDNS 5.0, Stork 2.4.1 declara que las vistas aún no son compatibles. Esa vista no debe registrarse como «coincidente» ni como «errónea»; debe quedar como no observada por una limitación conocida.

También conviene separar el inventario del contenido. Stork obtiene la lista y sus números de serie mediante las interfaces de cada servidor y la almacena después de Fetch Zones. El contenido detallado se solicita con Show Zone, viaja por AXFR y puede quedar en caché hasta que alguien elija Refresh from DNS. Un AXFR fallido puede impedir ver registros aunque el inventario conserve un número de serie. Un número de serie visible tampoco demuestra que el contenido completo se haya transferido.

El seguimiento de transferencias es una tercera superficie. Las diapositivas lo presentan como novedad de la versión de desarrollo 2.5.1. El manual del agente 2.5.1 indica que el rastreo de registros XFR solo cubre BIND, está desactivado por defecto y no puede seguir eventos disponibles únicamente en syslog. La página de ISC identifica 2.4.1 como versión estable y 2.5.1 como desarrollo. Por tanto, el número de versión debe acompañar a cualquier afirmación sobre visibilidad.

Los números SOA tampoco son contadores ordinarios. RFC 1912 explica que un secundario consulta la serie del primario para decidir si solicita nuevos datos. RFC 1982 define el orden circular de 32 bits: el valor vuelve a cero y existe una separación exacta de medio espacio para la que no hay orden definido.

Las fuentes revisadas sostienen que Stork destaca valores distintos. No documentan qué etiqueta de antigüedad aplica a todos los pares posibles. Por eso el registro debe guardar los dos números originales y, si el producto decide cuál es posterior, la regla y el resultado empleados. La desigualdad es una observación. «Este secundario está retrasado» añade una interpretación temporal y un rol de servidor.

Dos series iguales tampoco prueban que el contenido sea idéntico, que DNSSEC sea válido o que el usuario reciba una respuesta concreta. Esos límites ya exigen otras pruebas. La aportación específica de esta noticia es anterior: ninguna de ellas puede evaluarse con rigor si no se sabe qué filas entraron en la comparación.

Un recibo de cobertura puede ser pequeño. Debe registrar las versiones del servidor y los agentes Stork, la implementación y versión DNS, identidades de máquina, demonio, zona y vista, el manifiesto de alcance esperado, la ventana y resultado de la captura, ambos conteos de zonas, exclusiones, vistas no compatibles, valores SOA, hora de observación, máximo de antigüedad permitido, estado de comparación y correcciones posteriores.

Con ese recibo, el panel puede expresar cuatro estados: completo para el alcance declarado, parcial por filas ausentes, caducado por antigüedad o no comparable porque cambió el conjunto. Una diferencia detectada sigue siendo útil dentro de un resultado parcial. La ausencia de diferencias no puede abarcar más que la cobertura demostrada.

No es una crítica a la centralización de Stork. La centralización es precisamente lo valioso. Reúne señales que antes estaban dispersas en decenas de servidores. El paso institucional consiste en unir ese inventario observado con una lista independiente de lo que debía observarse. Solo entonces una pantalla limpia o una fila marcada puede sostener una decisión que otro operador sea capaz de reproducir.

Fuentes