Por falta de um título melhor. Nosso ambiente requer ter subdomínios onde permitimos atualizações dinâmicas usando bind como o servidor DNS e seu utilitário nsupdate autenticando via keyfiles. Estamos procurando tornar isso mais redundante. Atualmente, temos um servidor de nomes principal para todos esses subdomínios e vários secundários para nosso domínio de nível superior (mas não para os subdomínios). Como exemplo, usando bar.com como TLD e foo.bar.com como o subdomínio. O arquivo de zona de subdomínio foo.bar.com teria entradas semelhantes a:
NS ns1.bar.com
A 1.2.3.4
MX mx1.bar.com
www A 1.2.3.5
...
e o arquivo de zona primária teria entradas para 'foo' como:
foo NS ns1.bar.com
Atualmente, os subdomínios não são replicados para outros servidores de nomes, ou seja, ns1 é o único servidor de nomes que pode resolvê-los, mesmo que ns2, ns3, etc. são configurados como secundários para o domínio bar.com. Idéias de como configurar isso de uma maneira mais confiável? Se o registro de cola no arquivo de zona bar.com foi removido e vários registros NS foram configurados em cada subdomínio (e configurados como escravos em servidores de nomes secundários), isso ajudaria a resolver os domínios, mas não ajudaria em fornecer uma alternativa servidor 'update', caso um subdomínio precise ser atualizado. Se ns1 estava inativo neste exemplo, como permitiria que os clientes nsupdate atualizassem sua zona e a replicassem para os outros servidores de nomes, bem como quando o ns1 voltasse a ser on-line? Isso é possível com o Bind?
Talvez isso ajude - o BIND pode usar o MySQL como backend (você possivelmente precisará recompilá-lo com a opção certa ativada), e o MySQL possui a edição Cluster (gratuita também) que é um pouco multi-master. Talvez ele possa ser combinado para atender às suas necessidades ... e também há o PowerDNS, que também pode usar o SQL como back-end.
O BIND9 (novamente - com correções apropriadas) é capaz de usar o banco de dados LDAP como backend. O Fedora e o RHEL 6.4+ contêm o BIND com suporte LDAP, se você quiser tentar.
A operação de vários mestres com back-end de LDAP é possível, cada servidor mestre de DNS conta o próprio número de série e se anuncia como mestre (no nome mestre de SOA), de modo que as atualizações dos clientes são distribuídas para todos os servidores. A replicação de dados é tratada no nível do LDAP nesse caso.
O DNS multi-mestre descrito é usado no projeto FreeIPA. O FreeIPA pode definir o ambiente LDAP replicado para você. (O DNS integrado / replicado / multi-master vem com o FreeIPA como bônus, o foco principal do FreeIPA é o Gerenciamento de Identidade).
Homepage do FreeIPA: link
O próprio backend do LDAP pode ser encontrado no link Patch com "interface" para BIND9 pode ser encontrado em: link
Não há mecanismo no protocolo DNS (e muito menos no BIND) para permitir que as atualizações dinâmicas recebidas em diferentes "mestres" sejam mescladas e replicadas para vários escravos (e o principal "mestre" quando surgir).
Você precisa continuar com o modelo "um mestre, secundário múltiplo" suportado com atualizações dinâmicas e IXFR ou usar alguma forma de mecanismo fora de banda para atualizar todos os seus servidores.