Configuração de DNS Master / Slave vs. servidores DNS rsync'ed

Question

Atualmente, temos servidores DNS primários e secundários em nossa rede corporativa. Eles são configurados em uma configuração do tipo mestre / escravo, onde o escravo obtém suas informações de DNS do mestre.

Estou tentando descobrir qual é a vantagem real para a configuração mestre / escravo, em vez de apenas configurar um rsync automático entre os dois para manter as configurações de DNS correspondidas.

Alguém pode lançar alguma luz sobre isso? Ou é apenas uma coisa preferencial? Se for esse o caso, parece que a configuração do rsync seria muito mais fácil de configurar, manter e entender.

    

Answer 1

A configuração mestre / escravo (também conhecida como "transferências de zona", AXFR ou IXFR ) é a configuração padrão usada pela maioria dos servidores DNS. Só por isso, é o que eu recomendo, mesmo que seja complicado.

Embora eu recomende isso para interoperabilidade, e porque é fácil para outros administradores entenderem, isso não significa que é tecnicamente a melhor maneira de fazer isso.

Daniel Bernstein (de djbdns / tinydns ) prefere strongmente rsync e tem esta tabela comparando rsync vs. transferências de zona . rsync funciona muito bem com tinydns , mas eu nunca tentei com bind .

Se você tentar, lembre-se de que provavelmente estará escrevendo um script executado por cron . Outro administrador que analisa sua configuração de DNS não saberá necessariamente isso ou saberá onde encontrar o script de sincronização. Por outro lado, a configuração da transferência de zona regular está bem ali nos seus arquivos de zona, tornando-a explícita. Se isso é importante depende da quantidade de outros administradores com os quais você lida e do quanto você espera que eles estejam informados sobre sua configuração de DNS.

    

Answer 2

Na verdade, há muita coisa acontecendo aqui, mas muito disso pode ser irrelevante para sua situação.

Primeiro, usar as relações mestre / escravo do DNS permite uma replicação fácil entre os tipos de servidores heterogêneos. Eu sei que eu sincronizei um servidor principal do OS X Server (BIND?) Com o DNS do Windows.

Isso também permite que você especifique que um sistema DNS secundário pode recuperar de servidores primários diferentes para zonas diferentes (e vice-versa). Um exemplo prático: usamos nosso próprio sistema DNS e terceirizamos DNS secundário adicional para confiabilidade.

Expandir servidores DNS também é fácil dessa maneira. Você simplesmente adiciona o novo escravo à lista, em vez de adicionar o servidor de nomes adicional, configurar replicação adicional, etc. Isso mantém o processo relativamente autocontido.

    

Answer 3

Existem alguns motivos para usar AXFR / IXFR em vez de rsync:

1. É padrão e funciona em todas as implementações em conformidade. Isso permite que você misture servidores - talvez se você quiser resiliência em caso de um problema de segurança com um de seus fornecedores

2. É rápido - as alterações no mestre podem ser replicadas para os secundários em segundos, se você usar o mecanismo NOTIFY . (o mestre diz aos secundários que a zona mudou e, em seguida, os secundários podem pegar as alterações com IXFR ).

3. É confiável - não há chance de o seu servidor de alguma forma obter um arquivo parcialmente copiado e pensar que é todo o arquivo.

FWIW, usamos IXFR aqui em uma grande zona muito . "Apenas funciona".

    

Answer 4

Assumindo o BIND aqui.

• Se você atualizar seus registros de zona, em um recarregamento, o mestre normalmente notificará o (s) escravo (s) de uma alteração. O escravo buscará as atualizações.
• Usando o rsync, as atualizações só serão propagadas quando o rsync for executado. Mais o então precisa dizer ao escravo para recarregar as mudanças.

Parece-me que usar o rsync não é apenas mais um problema, apenas cria mais coisas para dar errado, possivelmente deixando o mestre e o escravo fora de sintonia.

    

Answer 5

Parece que um rsync e um IXFR acabariam fazendo praticamente a mesma coisa. Você estaria bem rsyncing de bind9- > bind9 por exemplo, mas se você precisava ir de bind8- > bind9 ou bind-> Microsoft, uma transferência de zona ainda deve funcionar, apesar das diferenças no back-end. O sinal de mais para rsync-only como eu vejo é que você pode desativar totalmente as transferências de zona, o que é bom do ponto de vista de segurança.

    

Answer 6

Nós rodamos bind com o rsync desde 1995 - Funciona bem - Há muitas razões para usar tinydns e / ou transferências de zona hoje, mas a lógica na época, e por que continuamos com isso hoje, é se um servidor tem hackeado de alguma forma não há verdadeira "primária" para depois replicar o problema para os outros.

Dito isso, ter o primário interno da sua LAN e os escravos acessíveis na Internet também resolve o problema.

Nós enviamos o rsync e recarregamos por meio de scripts, junto com algumas verificações de integridade - Se você seguir esse caminho, considere adicionar todas essas peças caso algo dê errado - Você REALMENTE não quer seus servidores DNS desativados ou até mesmo zonas ausentes. / p>     

Answer 7

Eu normalmente faço o que é natural para a situação dada.

Ao usar o bind, dependendo da situação, normalmente executarei dois mestres e vários escravos.

Mudanças são feitas um mestre; essas mudanças são validadas e depois rsynced para outro mestre. Esse mestre usa transferências de zoen para enviar as zonas para os clientes de servidores DNS. Os outros dois não são anunciados. (o primeiro mestre não é estritamente necessário, mas é bom ter um macaco zero ) Eu também gosto de ter 2 cópias das configurações do servidor e 2 cópias dos arquivos de zona em um formato adequado (em vez da cópia que você obtém em um servidor escravo). Deve-se tomar cuidado para garantir que o servidor recarregue as zonas apenas após o rsync ser concluído.

Quando você usa o AD para DNS, não precisa se preocupar com a troca de zonas entre servidores - os protocolos do AD magicamente cuidam da sincronização de tudo.

O PowerDNS espera que você use as transferências de zona ou use algum mecanismo de replicação de banco de dados para manter as coisas em sincronia.

O TinyDNS pode usar transferências de zona, mas se você estiver transferindo arquivos dentro da mesma organização, faz sentido usar algo como o rsync, porque o servidor tinydns torna as zonas de recarga seguras e fáceis.

Por fim, e mais importante: use as transferências de zona, se estiver trocando zonas DNS com organizações fora de seu controle direto. Por exemplo, é comum que seu provedor de serviços de Internet hospede um servidor autoritativo para os clientes. Esse servidor será um servidor escravo e obterá as zonas por meio de transferências de zona, independentemente do tipo de servidor DNS que o cliente esteja executando. Da mesma forma, se eu terceirizar meu DNS para um provedor como o UltraDNS, insistirei em fazer transferências de zona de minhas zonas de seus servidores, para que eu possa deixá-las a qualquer momento atualizando os registradores para usar meus servidores em vez deles como os servidores oficiais dos meus domínios.