O escravo BIND não sincroniza com o mestre até que seja reiniciado

Question

Eu tenho dois servidores DNS executando o BIND9, um mestre e um escravo. Quando o arquivo de zona é atualizado no mestre, eu quero que o servidor escravo comece a servir imediatamente o (s) registro (s) alterado (s), mas o BIND está me dando algumas informações.

A transferência de zona DNS já está funcionando corretamente entre o mestre e o escravo. Eu posso entrar no servidor escravo e executar dig @dnsmaster myzone. AXFR e imprime todo o conteúdo da zona. Para que isso funcione, o mestre DNS é configurado com notify yes e also-notify { dnsslave } . Da mesma forma, o escravo é configurado com allow-transfer { dnsmaster } .

Quando o dnsmaster é atualizado, executo rndc reload e ele informa que as notificações estão sendo enviadas. Isso é confirmado no escravo inspecionando os arquivos de zona em /var/named/slavedata/ . Eles contêm os dados mais recentes, correspondendo ao que o mestre sabe.

Agora vem a parte estranha.

O servidor slave continuará a servir registros DNS antigos e obsoletos, ignorando completamente o fato de que novos dados estão disponíveis no disco após serem notificados pelo mestre. Estou usando dig para verificar os resultados com este comando: dig @slaveserver record.zone.tld .

Eu achei que o BIND poderia estar mantendo um cache na memória de suas zonas autoritativas, então eu configurei max-cache-size e max-cache-ttl para 0, mas isso não teve efeito.

Eu tentei outras maneiras de limpar esse suposto cache, executando comandos como rndc flush e rndc reload no servidor slave, mas ele ainda retorna os antigos registros obsoletos.

Finalmente, notei que MINTTL na zona foi definido para 86400 (24 horas), então alterei temporariamente o MINTTL para 15 segundos e reiniciei o servidor escravo. Sem efeito - o escravo só forneceria resultados de DNS atualizados após o serviço ser reiniciado.

O que está acontecendo aqui? Qual é o comportamento esperado do BIND9 ao receber notificação de que uma zona é atualizada? Ela sempre respeita TTL e MINTTL ? Eu diria que sempre usaria os dados mais recentes disponíveis.

A meu ver, estou pensando em criar um crontab para reiniciar os escravos do BIND de hora em hora, apenas para evitar a exibição de dados obsoletos. Existe alguma coisa melhor?

    

Answer 1

Pela sua descrição, não posso dizer exatamente o que é o problema, mas posso ajudá-lo a descartar várias coisas.

As configurações de tamanho do cache e as configurações de cache ttl são para dados de consulta recursiva em cache e (como você já suspeitava) não se aplicam a dados autoritativos. Da mesma forma, o rndc flush é inaplicável aqui.

Método de solução de problemas sugerido:

1. Verifique se as mensagens de notificação estão sendo enviadas pelo mestre conforme o esperado. Verifique os logs e / ou fareje o tráfego entre o mestre e o escravo.
2. Verifique nos logs que a mensagem de notificação está sendo recebida pelo escravo.
3. Se você não puder ver o escravo recebendo a notificação, solucione o problema como um problema de notificação, ou seja, verifique suas opções de notificação em named.conf no mestre, certificando-se de que elas estejam definidas como esperado, não sejam sobrescritas posteriormente e estejam com escopo adequado. Eu recomendo usar "notificar explícito"; com "também-notificar {slave-server;};"
4. Se o escravo estiver vendo a notificação, seu problema é descobrir por que o arquivo de zona não está sendo atualizado conforme o esperado. O que deve acontecer é após a notificação ser recebida, o escravo deve fazer uma consulta SOA, comparar com sua SOA atual e fazer um AXFR (ou IXFR se você tiver habilitado) para obter a cópia da zona atualizada (supondo que o SOA no mestre é maior.) Você deve ser capaz de observar tudo isso acontecendo com um sniffer e também deve estar vendo evidências disso nos logs em ambos os servidores.
5. Se as operações não ocorrerem como esperado, comece comparando manualmente os números de série SOA nos dois servidores (dig @server $ zonename SOA) para certificar-se de que você não forneceu acidentalmente ao escravo uma serial maior que o esperado número algum tempo no passado que agora é maior que o número de série do mestre.

Se isso não funcionar, considere postar mais informações, incluindo as seções named.conf do mestre e do escravo, e registre de ambos os servidores o que está ocorrendo depois de carregar uma zona editada recentemente no mestre.

    

Answer 2

Por favor, não se esqueça de incrementar o id serial dos arquivos de zonas quando você fizer mudanças no Master Server antes de recarregar o named, caso contrário os arquivos de zonas não serão replicados para o Slave Server.

    

Answer 3

Eu enfrentei a mesma situação. Minha pesquisa me levou à seguinte realização. Se você estiver usando views, então o dig @ local machine servirá apenas o que estiver no localhost-view. o localhost-view é atualizado somente durante a reinicialização do named. Mas o arquivo de zona mais recente (transferido do mestre) ainda está disponível no escravo e será exibido para todas as consultas provenientes de fontes externas ou exibições externas. Então, você precisa fazer arranjos para que sua visão localhost seja atualizada.