DNS divide a arquitetura de domínio enquanto retém o acesso a zonas de divisão

Question

Como a maioria das organizações, mantemos vários domínios divididos por vários motivos. Devido ao que fazemos, freqüentemente usamos o mesmo nome em diferentes instâncias do domínio para apontar para diferentes versões de coisas e isso é um requisito para nós mantermos. O que surgiu mais recentemente é que isso está se tornando uma barreira para o acesso entre as divisões. No caso mais simples, queremos poder fornecer aos usuários internos acesso ao exemplo.com, que existe tanto interna como externamente.

Gostaríamos de poder acessar a versão interna como example.com e a versão externa como ext.example.com. Temos acesso para transferir a zona externa para nosso servidor BIND interno de um provedor externo.

Eu configurei uma exibição no servidor BIND sem nenhuma para correspondências de cliente, de modo que tudo o que ela faz é pré-formatar a transferência de zona para a zona. Eu tentei usar o mesmo arquivo na visão "interna" como um mestre sob o nome ext.mypna.com. Quando isso é feito, todos os registros são invalidados por bind como "dados fora da zona".

Analisando o arquivo de zona no servidor interno versus o provedor externo, descobri que a zona transferida foi marcada com "$ ORGIN external.com" e "external.com IN SOA". Revertê-los para @ permite que o BIND use o arquivo de zona novamente, mas ele só é descartado após uma atualização.

Existe uma maneira padrão de implementar esse tipo de arquitetura?

    

Answer 1

Se eu entendi corretamente, você executa servidores DNS independentes separados, e cada conjunto (eu realmente espero que você tenha mais de uma instância por sub-rede ou local de rede) de servidores contém informações não coordenadas diferentes. Isso é insustentável. Na verdade, herdei algo assim há alguns anos e foi nossa maior fonte de aborrecimentos, bugs e interrupções até termos arrancado e construído uma configuração de DNS completamente nova.

Em vez de manter vários mestres responsáveis por suas próprias zonas, crie um único mestre mantendo todas as zonas, com várias visualizações. Configure escravos em todos os lugares que eles fizerem sentido (outro no mesmo local, mais em outros locais físicos, coloque-os fisicamente e logicamente perto de onde seus usuários estão). Replicar todas as vistas para todos os escravos, ou apenas algumas visões, se você souber que alguns de seus escravos não atenderão a solicitações de certas redes. Quando isso estiver no lugar, todos os seus servidores terão exatamente os mesmos dados. Você só precisa garantir que suas visualizações estejam definidas corretamente e que todos os clientes obtenham exatamente os resultados de que precisam, independentemente do servidor usado.

Algumas dicas sobre a implementação:

1. Use $ INCLUDE em seus arquivos de zona para que os arquivos de visualização individuais tenham apenas as entradas diferentes entre diferentes exibições (por exemplo, seu ext.example.com provavelmente resolverá o mesmo IP independentemente da exibição, por isso, ele vai para o arquivo de inclusão comum, enquanto example.com será específico para cada arquivo de visualização).

2. Para replicação, você pode fornecer a cada servidor DNS vários endereços IP - um por exibição. Isso é feito, porque as visualizações usam o endereço IP do cliente para determinar o que atender - e isso também inclui solicitações XFER provenientes de escravos. Então, você tem que 1) para cada escravo, adicionar um e apenas um dos seus endereços IP em cada visão; 2) nos escravos, use diretiva transfer-source em named.conf para que os XFERs se originem no IP correto. Aqui está a mesma idéia explicada em mais detalhes: link

Além disso, veja se você pode obter ajuda de seus administradores de rede. Em algumas situações, a reconfiguração do DNS pode tornar as visões separadas desnecessárias.