Atualiza para uma zona dinâmica do BIND que é compartilhada entre visualizações atrasadas

8

Aqui está o rápido e sujo: No BIND9 com uma zona dinâmica compartilhada entre views , fazendo um nsupdate, atualizando / criando / deletando um registro irá funcionar bem se eu consultar esse registro de um cliente que se encaixe na mesma view da qual eu fiz o nsupdate.

Consultar a partir de uma visão que não é a mesma que eu usei para atualizar lançará NXDOMAIN (se adicionar um novo registro) ou mostrará informações de registro antigas no caso de uma mudança / atualizar até que um período de tempo arbitrário (digamos 15 minutos) seja ultrapassado, ou eu forço $ rndc freeze && rndc thaw . $ rndc sync parece não fazer absolutamente nada para resolver o problema - eu esperava que fosse apenas uma coisa de arquivo de diário, já que os liberações de diário estão documentados para serem liberados em torno de 15 minutos.

Se isso não estiver claro, aqui está um pseudo código para começar:

Exibições do 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";
};

Exemplo de linha 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 ]

Em outro lugar, um host com a mesma visão do nsupdate

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

Em outro lugar, o host entra em uma diferente exibição como o nsupdate

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

Nesse ponto, se tiver paciência, o problema acabará se resolvendo (talvez 15 minutos), mas frequentemente não tenho o luxo de ter paciência, por isso sou forçado a $ rndc freeze && rndc thaw no servidor de nomes a forçar a correção do problema.

Por outro lado

No lado perfeitamente invertido, se eu fizer o nsupdate contra o servidor a partir de um endereço que caia na visão "cdn-redir", o problema se inverte. Consultas subseqüentes de clientes correspondentes a "cdn-redir" obtêm o registro correto imediatamente após o nsupdate sem mexer em "rndc freeze / thaw", mas consultando endereços que estão fora da exibição de "cdn-redir" agora tem o atraso / rndc bobagem.

Minha pergunta final

Se fosse tão simples quanto 42, eu levaria isso de braços abertos ...

Gostaria de evitar "congelar e descongelar" por receio de perder uma atualização dinâmica do servidor DHCP. Alguém sabe como obter os registros atualizados sincronizados entre as visualizações de forma mais eficaz / eficiente ou pode lançar alguma luz sobre onde posso estar errado?

Editar: BIND 9.9.5 / Ubuntu 14.04, mas aconteceu em versões anteriores do Ubuntu e do BIND.

Obrigado a todos!

Conforme solicitado por Andrew B , veja a zona editada (e 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"
    
por enragedSquirrel 01.05.2014 / 15:56

2 respostas

6

Diferentes visões agem separadamente, é essencialmente uma conveniência sobre a execução de instâncias separadas de nomes. Se houver zonas com o mesmo nome em diferentes visões, isso é apenas uma coincidência, elas ainda são zonas totalmente separadas, não mais relacionadas do que quaisquer outras zonas.

Ter várias zonas separadas usando o mesmo arquivo de zona não funciona em situações em que a vinculação está atualizando o conteúdo da zona por conta própria (zonas escravas, zonas com atualizações dinâmicas, etc.). Não tenho certeza se há risco de corromper o próprio arquivo de zona.

Você pode definir algo como o que deseja fazer, fazendo com que a zona de uma vista seja escrava para a zona com o mesmo nome na outra vista. Esta será claramente uma configuração um pouco complicada, mas usando chaves TSIG para clientes de correspondência, bem como a notificação / transferência, acredito que seja factível.

Editar: o ISC publicou um artigo da base de conhecimento para este cenário, Como eu compartilho uma zona dinâmica entre múltiplas visualizações? , sugerindo o mesmo tipo de configuração mencionado acima.

Este é o exemplo de configuração deles com formatação aprimorada:

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 { ... };
    };
};
    
por 01.05.2014 / 18:13
1

Tendo problemas semelhantes com as visualizações, decidi me livrar delas e mover a autorização para as zonas.

Você pode substituir as exibições em perguntas por simples inclusões de ambos os arquivos de zona, deixar as zonas compartilhadas atualmente intocadas e adicionar a definição allow-query {} a "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 { .... };
    };

com isso, você atinge sua meta presumida de tornar o dynamic.zone acessível somente a partir de redes específicas e de ter outras zonas públicas.

    
por 07.05.2014 / 13:57