Bind obtém o status da transferência de zona depois de executar o rndc reload zonename

Question

Eu tenho um script que executa rndc reload <zone_name> in <view_name> em servidores secundários (escravos) nas zonas que são modificadas. Este comando retorna sucesso se o recarregamento for enfileirado com sucesso.

Eu queria saber se existe uma maneira de obter o status da transferência de zona real sem passar pelos logs em si. Eu quero ser capaz de manipular automaticamente o caso quando o recarregamento de ligação falhou com base no próprio erro. Atualmente, tenho que analisar os logs para obter o status da transferência de zona depois de executar rndc reload .

Alguém pode me ajudar a descobrir como posso obter o status da transferência de zona depois de executar rndc reload <zone_name> , o que é melhor do que analisar os próprios logs.

OBSERVAÇÃO [para adicionar mais clareza] : Eu sei que notificar pode ser usado para mestre para comunicar ao escravo sobre uma mudança. Minha pergunta é sobre saber se há alguma maneira de ser notificado quando a transferência de zona iniciada pelo escravo falhou devido a qualquer motivo sem analisar os logs.

Por exemplo Pode ser depois de notificar o escravo, o servidor mestre morreu devido a algum motivo. Nesse caso, quando o escravo inicia uma transferência de zona, ele falha ao obter o registro SOA do mestre. Quero ser notificado para esse tipo de erro que pode acontecer durante a transferência de zona sem realmente analisar os logs.

Deixe-me saber se mais informações são necessárias.

    

Answer 1

O arquivo de log (erro) é o único lugar onde o Bind registrará tais erros, portanto, se você não quiser analisar os arquivos de log em busca de erros específicos (embora possa usar algo como o Splunk para automatizar essa análise e geração) alertas relevantes) você precisa de algo mais.

Do ponto de vista do monitoramento, acho que seu foco em ser notificado sobre erros durante as transferências de zona não é o bastante. Não são realmente os erros que importam tanto, é o fato de tais erros indicarem um serviço reduzido, falho ou errôneo. Em vez disso, concentre-se no serviço.

Uma solução de monitoramento configurada corretamente detectará esse estado de serviço alterado e o alertará. Então seu engenheiro / operador pode facilmente procurar no arquivo de registro a causa relevante da redução / falha do serviço ...

Em um cenário mestre-escravo, seu monitoramento precisa garantir que:

• todos os escravos e os servidores de nomes principais respondem e retornam os dados da zona
• todos os escravos retornam dados que são consistentes com o mestre

Um bom registro DNS para monitorar uma zona seria o registro SOA, já que isso é algo que cada servidor de nomes deve sempre poder retornar para cada zona.

Segundo, o número de série no registro SOA deve informar se o escravo está sincronizado com o mestre. Se houver diferença nos números de série que podem ser causados pelo escravo ter perdido uma mensagem NOTIFY, mas se essa diferença estiver presente por mais tempo do que o intervalo de atualização SOA, um problema mais sério está à mão.

    

Answer 2

Crie um script slave.sh com:

#!/bin/sh

ns1="yourfirstdnsserver"
ns2="yourslavednsserver" 
serial='grep SOA |cut -d " " -f7'
domain=$1

rndc reload $domain

a='host -t SOA $domain $ns1 |grep SOA |cut -d " " -f7'
b='host -t SOA $domain $ns2 |grep SOA |cut -d " " -f7'

if [ $a = $b ];
        then echo "$domain : synchro ok";
        else "$domain : Error";
fi;

Basta usar ./slave.sh yourdomain.com .

Aproveite!

    

Answer 3

a='host -t SOA yourdomain.com yourns1.com |grep SOA |cut -d " " -f7' && b='host -t SOA yourdomain.com yourns2.com |grep SOA |cut -d " " -f7' && if [ $a = $b ]; then echo "synchro ok"; else "Error"; fi;