Mestre BIND não replicando para escravos

2

Eu tenho um servidor BIND mestre mantendo um punhado de zonas. Um exemplo de entrada no arquivo named.conf :

zone "example.com" {
        type master;
        file "example.com.zone";
        allow-update { 10.202.215.10; 10.202.215.11; 10.201.215.14; };
};

Existem três escravos. Uma configuração de exemplo que existe em todos os três:

zone "example.com" {
        type slave;
        file "slaves/example.com.zone";
        masters { 10.201.215.11; 10.202.215.10; 10.202.215.11; };
};

EDITAR

IPs e hostnames do mestre e dos escravos

Master: 10.201.215.11
Slave1: 10.201.215.14
Slave2: 10.202.215.10
Slave3: 10.202.215.11

END EDIT

Para o arquivo de zona no exemplo, eu incrementei o número de série no mestre e então executei rndc reload em todos eles (mestre e três escravos). O registro de data e hora nos arquivos de zona em cada escravo está sendo atualizado, no entanto, o número de série no escravo não é atualizado.

Os escravos estão atualizando, no entanto:

Oct 14 12:14:44 dns-slave01 named[12434]: transfer of 'example.com/IN' from m 10.201.215.11#53: connected using 10.202.215.10#44420

Por que a série não seria atualizada?

EDITAR

Com base no comentário de yoonix, removi todos, exceto o servidor que sei ser o mestre da zona:

zone "example.com" {
        type slave;
        file "slaves/example.com.zone";
        masters { 10.201.215.11; };
};

Eu também defini explicitamente notify yes apesar de estar habilitado por padrão.

Além disso, eu removi a opção allow-update no mestre para garantir que todos os hosts possam atualizar dinamicamente.

A replicação ainda não está ocorrendo.

Estou, no entanto, vendo que o mestre está enviando os anúncios NOTIFY:

Oct 17 00:48:00 dns-master01 named[5608]: zone example.com/IN: sending notifies (serial 2009091903)
Oct 17 00:48:13 dns-master01 named[5608]: zone example.com/IN: sending notifies (serial 2009091904)

Eu verifiquei através de telnet que eu posso conectar aos escravos do mestre pela porta 53.

EDIT 2 Uma coisa que fiz foi garantir que todos os escravos tivessem a mesma configuração, bem como consertar o registro que estava mal configurado. Cerca de três horas depois de modificar o arquivo de zona, a transferência aconteceu. Ainda não consigo entender por que isso não está acontecendo imediatamente.

Abaixo está o mestre named.conf . Existem várias outras entradas de zona, mas todas são idênticas, com exceção do domínio.

// generated by named-bootconf.pl
// 
// a caching only nameserver config
acl trusted_nets {
 10.201.96.0/20;
 10.202.96.0/20;
 10.201.215.0/24;
 10.202.215.0/24;
 12.130.200.0/24;
 174.47.15.0/24;
 199.108.193.0/24;
 199.108.195.0/24;
 72.165.204.0/24;
};
// 
options { 
        directory "/var/named";
        allow-recursion { trusted_nets; };
        notify yes;
        allow-transfer { 10.202.215.10; 10.202.215.11; 10.201.215.14; 199.108.193.20; 209.67.192.20; 10.201.215.10; };
};
logging {
    channel dns_log {
        file "/var/log/named.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category default {
        dns_log;
    };
};
controls { 
    inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." { 
    type hint;
    file "named.ca";
};
zone "localhost" { 
    allow-update { none; };
    type master;
    file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" { 
    allow-update { none; };
    type master;
    file "named.local";
};
zone "example.com" { 
    type master;
    file "example.com.zone";
    allow-update { 10.202.215.10; 10.202.215.11; 10.201.215.14; };
};
include  "/etc/rndc.key";

Cada um dos IPs na configuração allow-update é um dos escravos.

Exemplo de escravo. Novamente, existem várias outras zonas, mas elas são idênticas, exceto no domínio.

// generated by named-bootconf.pl
// 
// a caching only nameserver config
acl trusted_nets {
    10.201.96.0/20;
    10.202.96.0/20;
    10.202.92.0/20;
    10.201.215.0/24;
    10.202.215.0/24;
    12.130.200.0/24;
    174.47.15.0/24;
    199.108.193.0/24;
    199.108.195.0/24;
    72.165.204.0/24;
};
// 
options { 
    directory "/var/named";
    allow-recursion { trusted_nets; };
    allow-transfer { 10.202.215.10; 10.202.215.11; 10.201.215.11; 199.108.193.20; 209.67.192.20; };
};
logging {
    channel mtg_log {
        file "/var/log/named.log" versions 3 size 5m;
        severity info;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category default {
        mtg_log;
    };
};
controls { 
    inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { rndckey; };
};
zone "." IN { 
    type hint;
    file "named.ca";
};
zone "localhost" { 
    allow-update { none; };
    type master;
    file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" { 
    allow-update { none; };
    type master;
    file "named.local";
};
zone "example.com" { 
    type slave;
    file "slaves/example.com.zone";
    masters { 10.201.215.11; }; 
};
include  "/etc/rndc.key";

Com exceção da opção type , eles são idênticos. Eu não sei se é assim que eles devem ser configurados.

EDIT 3

O anúncio NOTIFY parece ser enviado apenas quando eu reiniciar o named . Eu tentei rndc reload e service named reload , mas não fiz nada. Apenas service named restart enviou o anúncio.

    
por theillien 14.10.2016 / 23:07

2 respostas

0

Da sua configuração, você tem vários servidores mestres. Os escravos podem consultar qualquer um dos mestres para uma atualização. Verifique se todos os mestres estão atualizados antes de tentar atualizar os escravos. Eu suspeito que você deve ter apenas um endereço IPv4 e / ou um IPv6 na lista.

Você provavelmente deve adicionar uma lista de notificação com os endereços IP de seus servidores escravos. Normalmente, esses devem ser os únicos hosts que podem fazer uma transferência de zona. Você também deve considerar a ativação da notificação para o seu servidor mestre.

    
por 15.10.2016 / 18:46
-2

Eu sugiro que você exclua os arquivos de zonas nos escravos e realize novas transferências de zona do mestre.

    
por 15.10.2016 / 12:00