☰

Bind9: Master->Slave Notify IPv6 com fallback para IPv4

tag-icon • tag-icon bind ipv6 failover
Bind9: Master->Slave Notify IPv6 com fallback para IPv4

Eu tenho um pequeno esquema de DNS Master-> Slave configurado entre duas máquinas executando Debian 8 + Bind9 em pilha IP dupla.

O mestre e o escravo possuem um IPv4 e um IPv6 usados ​​por bind, reforçados pelos parâmetros de configuração listen-on listen-on-v6 transfer-source transfer-source-v6 notify-source notify-source-v6 query-source address query-source-v6 address.

Atualmente meu mestre está configurado para notificar o escravo como:

notify yes;
also-notify { xxxx:xxxx:xxxx:xxxx::xxx5; x.x.x.5; };

Como meu escravo tem uma configuração de zona algo como:

zone "example.dev" {
    type slave;
    masters { xxxx:xxxx:xxxx:xxxx::xxx2; x.x.x.2; };
    file "...";
};

Esta configuração funciona bem, porém, ao inspecionar os arquivos de log (e como eu esperava), o mestre notifica o escravo duas vezes em cada mudança de zona:

May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from x.x.x.2#52041: zone is up to date
May 20 20:57:53 salvedns named[8568]: zone example.dev/IN: notify from xxxx:xxxx:xxxx:xxxx::xxx2#51347: zone is up to date

Uma vez, em IPv4 e outra em IPv6.

Existe uma maneira de informar ao servidor de ligação que xxxx:xxxx:xxxx:xxxx::xxx5 x.x.x.5são de fato endereços para o mesmo servidor DNS e tentar notificá-lo primeiro por IPv6 e, se falhar, tente novamente por IPv4? Além disso, como fazer a mesma coisa na mastersdeclaração de salva?

Obrigado.

Responder1

Não acredito que exista uma opção de configuração que faça o que você pede. No entanto, também não acredito que as notificações duplas sejam realmente motivo de preocupação.

Embora seja redundante nesta configuração, a sobrecarga que isso causa é mínima e normalmente não há problema algum.

De modo geral, receber múltiplas mensagens de notificação não está fora da norma, originalmente principalmente de mestre + outros escravos, mas agora também de hosts de pilha dupla, a ponto de atéa especificação original esperava isso:

4.2. É provável que cada escravo receba várias cópias da mesma solicitação NOTIFY: uma do mestre primário e uma de cada outro escravo, à medida que esse escravo transfere a nova zona e notifica seus pares em potencial. O protocolo NOTIFY suporta esta multiplicidade exigindo que NOTIFY seja enviado por um escravo/mestre somente APÓS ele ter atualizado o RR SOA ou ter determinado que nenhuma atualização é necessária, o que na prática significa após uma transferência de zona bem-sucedida. Assim, salvo reordenamento de entrega, o último NOTIFY que qualquer escravo receber será aquele que indicará a última alteração. Como um escravo sempre solicita SOAs e AXFR/IXFRs apenas de seus mestres conhecidos, ele terá a oportunidade de tentar novamente sua QUERY para SOA após cada um de seus mestres ter concluído cada atualização de zona.

informação relacionada