Gli aggiornamenti a una zona dinamica BIND condivisa tra le visualizzazioni sono in ritardo

Ecco il veloce e sporco: su BIND9 con una zona dinamica che è condivisa tra le viste , fare un aggiornamento, aggiornare / creare / cancellare un record funzionerà bene se chiedo per quel record da un client che rientra nella stessa vista che ho fatto il nsupdate a partire dal.

Effettuare una query da una vista che non è la stessa di quella che ho usato per aggiornare NXDOMAIN (se si aggiungeva un nuovo record) o mostrerà le informazioni del vecchio record in caso di modifica / aggiornamento fino a un periodo di tempo arbitrario (diciamo 15 minuti), o lo faccio forzatamente $ rndc freeze && rndc thaw. $ rndc syncnon sembra fare nulla per risolvere il problema: speravo fosse solo una questione di file di giornale poiché i risciacqui di giornale sono documentati per circa 15 minuti.

Se ciò non è chiaro, ecco alcuni pseudo codici per iniziare:

Viste 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";
};

Riga di comando di esempio

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 ]

Altrove, un host cade nella stessa vista di nsupdate

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

Altrove, l'host cade in una visione diversa come aggiornamento

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 ]

A questo punto, se sono paziente, il problema alla fine si risolverà da solo (forse 15 minuti), ma spesso non ho il lusso della pazienza, quindi sono costretto a $ rndc freeze && rndc thawrisolvere il problema con il server dei nomi.

Il rovescio della medaglia

Sul lato perfettamente invertito delle cose, se eseguo il nsupdate contro il server da un indirizzo che rientra nella vista "cdn-redir", il problema si inverte. Le successive query dei client che corrispondono a "cdn-redir" ottengono il record corretto immediatamente dopo nsupdate senza armeggiare con "rndc freeze / thaw", ma le query da indirizzi che non rientrano nella vista di "cdn-redir" ora hanno la stupidità delay / rndc.

La mia ultima domanda

Se fosse semplice come 42, lo prenderei a braccia aperte ...

Vorrei evitare di dover "congelare rndc && rndc thaw" per paura di perdere un aggiornamento dinamico dal server DHCP. Qualcuno sa come sincronizzare i record aggiornati tra le visualizzazioni in modo più efficace / efficace o può fare luce su dove potrei sbagliare?

Modifica: BIND 9.9.5 / Ubuntu 14.04 ma è successo nelle versioni precedenti di Ubuntu e BIND.

Ringrazia tutti!

Come richiesto da Andrew B , ecco la zona redatta (e parziale):

$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"

Viste diverse agiscono separatamente, è essenzialmente una comodità sull'esecuzione di istanze separate di named. Se ci sono zone con lo stesso nome in viste diverse, questa è solo una coincidenza, sono comunque zone completamente separate, non più correlate rispetto a qualsiasi altra zona.

Il fatto che più zone separate utilizzino lo stesso file di zona non funziona in situazioni in cui il bind sta aggiornando il contenuto della zona da solo (zone slave, zone con aggiornamenti dinamici, ecc.). Non sono sicuro che esista il rischio di corrompere il file di zona stesso.

Potresti essere in grado di impostare qualcosa di simile a quello che vuoi fare facendo in modo che la zona in una vista sia schiava della zona con lo stesso nome nell'altra vista. Questa sarà chiaramente una configurazione un po 'complicata, ma l'uso delle chiavi TSIG per i match-client e la notifica / trasferimento credo che dovrebbe essere fattibile.

Modifica: ISC ha pubblicato un articolo KB per questo scenario, come faccio a condividere una zona dinamica tra più viste? , suggerendo lo stesso tipo di configurazione di cui sopra.

Questo è il loro esempio di configurazione con una formattazione leggermente migliorata:

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 { ... };
    };
};

Avendo problemi simili con le viste, ho deciso di sbarazzarmi di loro e spostare invece l'autorizzazione nelle zone.

È possibile sostituire le visualizzazioni nelle domande con semplici inclusioni di entrambi i file di zona, lasciare intatte le zone attualmente condivise e aggiungere allow-query {} alla definizione "dynamic-zone.db" come:

    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 ciò raggiungi il tuo presunto obiettivo di rendere dynamic.zone accessibile solo da reti specifiche e di rendere pubbliche altre zone.