Actualizaciones a una zona dinámica BIND que se comparte entre vistas retrasadas

Aquí está lo rápido y sucio: en BIND9 con una zona dinámica que se comparte entre las vistas , hacer una actualización n, actualizar / crear / eliminar un registro funcionará bien si consulto ese registro desde un cliente que cae en la misma vista que hice la actualización n desde.

La consulta desde una vista que no es la misma que solía actualizar arrojará NXDOMAIN (si agrega un nuevo registro) o mostrará información del registro anterior en caso de un cambio / actualización hasta un período de tiempo arbitrario (digamos 15 minutos) pasa, o lo hago por la fuerza $ rndc freeze && rndc thaw. $ rndc syncno parece hacer nada en absoluto para resolver el problema; esperaba que fuera solo una cuestión de archivo de diario, ya que los vaciados de diario están documentados para enjuagarse alrededor de 15 minutos.

Si eso no está claro, aquí hay algunos pseudocódigos para comenzar:

Vistas BIND

view "cdn-redir" {
   match-clients { 10.1.1.0/24; 10.1.2.0/24; };
   include "cdn-zone.db";
   include "dynamic-zone.db";
};

view "default" {
   match-clients { any; };
   include "dynamic-zone.db";
};

Ejemplo de línea de comando

user@ns:~$ nsupdate -k rndc.key
> server localhost
> zone example.com.
> update add foohost.example.com. 600 A 10.5.6.7
> send
> quit

user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1)
  [ responds with correct answer 10.5.6.7 ]

En otro lugar, un host cae en la misma vista que nsupdate

user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
  [ responds with correct answer 10.5.6.7 ]

En otro lugar, el host cae en una vista diferente como nsupdate

user@10.1.1.50:~$ dig foohost.example.com (resolv.conf points to above nameserver)
  [ responds with NXDOMAIN even though I'm asking the same server ]

En este punto, si soy paciente, el problema eventualmente se resolverá solo (tal vez 15 minutos), pero con frecuencia no tengo el lujo de tener paciencia, por lo que me veo obligado a $ rndc freeze && rndc thawusar el servidor de nombres para solucionar el problema por la fuerza.

Por otro lado

En el lado perfectamente invertido de las cosas, si hago el nsupdate contra el servidor desde una dirección que cae en la vista "cdn-redir", el problema se revierte. Las consultas subsiguientes de clientes que coinciden con "cdn-redir" obtienen el registro correcto inmediatamente después de nsupdate sin manipular "rndc freeze / thaw", pero las consultas desde direcciones que quedan fuera de la vista de "cdn-redir" ahora tienen la tontería de delay / rndc.

Mi ultima pregunta

Si fuera tan simple como 42, lo tomaría con los brazos abiertos ...

Me gustaría evitar tener que "congelar rndc && descongelar rndc" por temor a perder una actualización dinámica del servidor DHCP. ¿Alguien sabe cómo sincronizar los registros actualizados entre las vistas de manera más efectiva / eficiente, o puede arrojar algo de luz sobre dónde puedo estar equivocado?

Editar: BIND 9.9.5 / Ubuntu 14.04 pero sucedió en versiones anteriores de Ubuntu y BIND.

¡Gracias a todos!

Según lo solicitado por Andrew B , aquí está la zona redactada (y parcial):

$ORIGIN .
$TTL 3600
example.com     IN SOA ns1.example.com. HOSTMASTER.example.com. (
                       2009025039 ; serial
                       900 ; refresh 15
                       600 ; retry 10
                       86400 ; expire 1 day
                       900 ; minimum 15 min
                )
                NS     ns1.example.com.
$ORIGIN example.com.
$TTL 30
AEGIS           A   10.2.1.60
                TXT "31bdb9b3dec929e051f778dda5abd0dfc7"
$TTL 86400
ts-router       A 10.1.1.1 
                A 10.1.2.1
                A 10.1.3.1
                A 10.1.4.1
                A 10.1.5.1
                A 10.1.6.1
                A 10.1.7.1
                A 10.1.8.1
                A 10.2.1.1
                A 10.2.2.1
                A 10.2.3.1
ts-server       A 10.2.1.20
ts-squid0       A 10.2.2.20
ts-squid1       A 10.2.2.21
$TTL 600
tssw4           A 10.2.3.4
tssw5           A 10.2.3.5
tssw6           A 10.2.3.6
tssw7           A 10.2.3.7
; wash rinse repeat for more hosts
$TTL 30
wintermute      A     10.2.1.61
                TXT   "003f141e5bcd3fc86954ac559e8a55700"

Las diferentes vistas actúan por separado, es esencialmente una conveniencia sobre la ejecución de instancias separadas de named. Si hay zonas con el mismo nombre en diferentes vistas, esto es solo una coincidencia, siguen siendo zonas completamente separadas, no más relacionadas que cualquier otra zona.

El hecho de que varias zonas separadas utilicen el mismo archivo de zona no funciona en situaciones en las que bind está actualizando el contenido de la zona por sí solo (zonas esclavas, zonas con actualizaciones dinámicas, etc.). No estoy seguro de si existe el riesgo de corromper el archivo de zona en sí.

Puede configurar algo como lo que quiere hacer haciendo que la zona en una vista sea esclava de la zona con el mismo nombre en la otra vista. Claramente, esta será una configuración algo complicada, pero usar las teclas TSIG para clientes coincidentes, así como la notificación / transferencia, creo que debería ser factible.

Editar: ISC ha publicado un artículo de KB para este escenario, ¿Cómo comparto una zona dinámica entre varias vistas? , sugiriendo el mismo tipo de configuración mencionada anteriormente.

Este es su ejemplo de configuración con un formato algo mejorado:

key "external" {
    algorithm hmac-md5;
    secret "xxxxxxxx";
};

key "mykey" {
    algorithm hmac-md5;
    secret "yyyyyyyy";
};

view "internal" {
    match-clients { !key external; 10.0.1/24; };

    server 10.0.1.1 {
        /* Deliver notify messages to external view. */
        keys { external; };
    };

    zone "example.com" {
        type master;
        file "internal/example.db";
        allow-update { key mykey; };
        also-notify { 10.0.1.1; };
    };
};

view "external" {
    match-clients { key external; any; };

    zone "example.com" {
        type slave;
        file "external/example.db";
        masters { 10.0.1.1; };
        transfer-source { 10.0.1.1; };
        // allow-update-forwarding { any; };
        // allow-notify { ... };
    };
};

Al tener problemas similares con las vistas, decidí deshacerme de ellas y mover la autorización a las zonas.

Puede reemplazar las vistas en las preguntas mediante la simple inclusión de ambos archivos de zona, dejar intactas las zonas actualmente compartidas y agregar allow-query {} a la definición de "dynamic-zone.db" como:

    zone "dynamic.zone" {
            allow-query { 10.1.1.0/24; 10.1.2.0/24; };
            type master;
            file "/etc/bind/zones/master/dynamic.zone";
            update-policy { .... };
    };

con esto logra su objetivo presunto de hacer que dynamic.zone sea accesible solo desde redes específicas y tener otras zonas públicas.