Dos sedes, una zona DNS privada: ¿quién posee los registros?

Añade un host en la sede verde, se resuelve para los usuarios verdes, y la oficina amarilla sigue recibiendo NXDOMAIN. No es un fallo de VPN ni un resolutor roto; es un hueco de propiedad dentro de la zona privada. Dos listas de registros editadas por separado no se convierten en una sola zona solo porque las sedes puedan alcanzarse. La solución es un plan de publicación, no otra regla de cortafuegos.

El síntoma nombra al propietario que falta

Cada sede probablemente tiene una anulación local, una entrada de Pi-hole o una línea de dnsmasq que alguien añadió cuando hacía falta un nombre. El registro verde solo existe en el resolutor verde, así que un cliente en la amarilla pregunta a su propio resolutor y recibe un "no existe ese nombre" veraz. Una respuesta obsoleta se ve distinta: el host se movió, una sede actualizó su copia y la otra sigue devolviendo la dirección antigua.

Ninguno de los dos patrones se corrige durante mucho tiempo vaciando la caché. La caché de un resolutor reenviador es una copia de una respuesta que recibió una vez, no una autoridad que publique nombres nuevos, así que una caché que funciona hoy no dice nada sobre el host de mañana. La documentación de BIND describe los papeles primario, secundario, recursivo y reenviador por separado exactamente por este motivo.

Así que la pregunta de diseño es estrecha y tiene respuesta: quién puede crear un registro y cómo llega ese registro a cada resolutor que debe responder por él.

Opción A: una zona autoritativa con secundarios

Ejecute un primario para internal.example.com y deje que los secundarios compatibles obtengan la zona en cada sede. El resolutor recursivo de cada sede consulta a su secundario local, así que las respuestas vienen de una fuente autoritativa y no de una caché, y un cambio hecho una vez se transfiere en lugar de reescribirse.

Ese arreglo necesita decisiones explícitas que son fáciles de posponer y caras de omitir. ¿Quién puede editar la zona? ¿Qué servidores pueden transferirla y por qué direcciones? ¿Qué deben ver los clientes mientras el túnel entre sedes está caído? Un secundario sigue respondiendo desde su última copia, que suele ser el comportamiento deseado, pero debe ser una elección declarada y no una sorpresa durante una caída.

Limite las transferencias de zona a los secundarios conocidos por dirección y use firmas de transacción donde la implementación las admita. Una transferencia abierta es una copia de su espacio de nombres interno para cualquiera que alcance el puerto.

El coste es la coordinación: una sola ruta de edición, una sola revisión de cambios y un entendimiento compartido de quién está de guardia cuando un registro es incorrecto.

Opción B: un subdominio por sede

Delegue green.internal.example.com a la sede verde y yellow.internal.example.com a la amarilla. Cada sede pasa a ser autoritativa para sus propios nombres y la zona padre solo lleva los registros de delegación. La disputa por un solo archivo desaparece y un equipo local puede añadir un host sin esperar un cambio central.

La delegación debe existir en la zona padre, con registros NS que apunten a los servidores autoritativos de la sede. Un reenvío condicional para el subdominio es una alternativa válida cuando una delegación completa no es práctica, pero es una configuración del resolutor y no un hecho publicado, así que cada resolutor necesita la misma regla.

El coste se mueve en lugar de desaparecer: la zona padre sigue necesitando un propietario, y crear una sede nueva ahora es un cambio en dos lugares en vez de uno.

Haga que cada resolutor siga la elección

Dé a los clientes el resolutor aprobado y el dominio de búsqueda mediante su configuración compatible, y asegúrese de que el resolutor tenga una ruta VPN permitida hacia cualquier servidor DNS remoto al que deba consultar. Las aplicaciones también necesitan rutas hacia las direcciones privadas que devuelven esas respuestas, porque un nombre correcto sin ruta sigue siendo una conexión rota.

Si Pi-hole proporciona resolución local, anote qué registros posee y qué consultas reenvía. Dos listas de Pi-hole editadas por separado siguen sin replicarse. En Pi-hole v6, las líneas personalizadas de dnsmasq se definen mediante opciones del lado del host como TOML, CLI o variables de entorno y no se exponen por la API; cargar archivos de /etc/dnsmasq.d/ es una opción aparte que está desactivada por defecto.

Luego pruebe desde ambos lados con un nombre que debería verse en todas partes:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

La respuesta SOA le dice si el resolutor amarillo cree que es autoritativo, si consulta a un secundario o si solo reenvía. Son diseños distintos con modos de fallo distintos, y la respuesta suele identificar cuál ha desplegado realmente.

Termine con tres casos de aceptación: un nombre de cada sede, un registro cambiado dentro de la hora y el enlace entre sedes no disponible. Un diseño que solo pasa el primero tiene un plan de publicación en el papel y una anulación local en producción.