Considerações de implementação / design para o DNS corporativo?

Question

Trabalho em uma grande organização (milhares de servidores, centenas de locais físicos, meia dúzia de datacenters consolidando-se um pouco em um futuro próximo) e estou revisitando muitos aspectos da infraestrutura de rede e do ambiente de hospedagem do servidor.

Uma das áreas em que me pediram para fornecer informações é a implementação do DNS. O maior problema que tenho é que não suportamos DNS split-horizon ou split-view. Os dispositivos voltados para a Internet são denominados host.example.com e os dispositivos da intranet e as interfaces administrativas são rotulados como host.example.customtld. Isso causa muita tristeza para as pessoas que implementam serviços voltados para a Internet e intranets.

Existe alguma coisa que a comunidade SF possa oferecer como sugestão para obter mais do DNS? Alguma história de horror para evitar? Idéias inovadoras que salvaram muito trabalho?

    

Answer 1

Você já considerou o DNS anycast? Esta questão , entre outras, fornece um pouco mais de informação sobre isto. Anycast permite que você anuncie o mesmo prefixo IP de vários locais em sua rede, com os sistemas clientes sendo roteados para a instância (logicamente) mais próxima de um serviço.

Alguns benefícios:

• Todos os clientes podem usar o mesmo endereço IP do resolvedor, independentemente de sua localização física. Isso simplifica muito o gerenciamento de configurações.
• Failover / resiliência pode ser fornecido automaticamente; se você tornar seus anúncios de roteamento condicionais ao servidor DNS que esteja funcionando e aceitando consultas, sempre que um servidor falhar, suas rotas serão retiradas automaticamente. Os clientes serão encaminhados para a próxima instância 'mais próxima' do serviço, sem a necessidade de qualquer reconfiguração.
• O Anycast também permite dimensionar horizontalmente com muita facilidade; como todos os clientes podem segmentar o mesmo endereço IP, independentemente da localização, trazer um novo servidor on-line se torna trivial.

Answer 2

Implementar o DNS de visão dividida economizará muito sofrimento (para pessoas que implementam serviços que enfrentam a Internet e intranets) e, portanto, trabalham (para você). Com o BIND, é fácil configurar.

Claro, se você não estiver executando o BIND, talvez seja mais trabalhoso.

E se os poderes que dizem "não usarás visão dividida", então você está ferrado.

    

Answer 3

Você provavelmente está ciente de que é uma boa prática (e às vezes necessária) ter pelo menos dois servidores DNS para cada domínio (ou LAN, ou unidade organizacional, ou qualquer outro). Há um equívoco comum de que um desses dois servidores deve ser o "mestre" e os outros devem ser "escravos". Se você tiver várias LANs (ou subdomínios) e cada uma tiver seu próprio par de servidores DNS, você terá um pesadelo tentando gerenciar todos os servidores principais espalhados pela sua organização.

Então aqui vai a dica: não é verdade que um dos dois servidores DNS tem que ser um mestre. O requisito real é que ambos sejam autoritativos . Isso é diferente.

Não há nada de errado em ambos os servidores com autoridade serem escravos. Na verdade, faço isso com bastante frequência, mesmo para pequenos domínios. Ter servidores escravos autoritários libera-me para fazer algumas coisas interessantes.

Digamos que eu tenha dois servidores DNS (A e B) e queira migrar os dados de A para um novo servidor, C, e se livrar de A. Aqui estão os passos:

1. Configure o C como escravo de A. Ele copia todos os arquivos de zona. (Ou você pode copiá-los manualmente se quiser preservar sua boa formatação.)
2. Atualize o DHCP para que os clientes consultem B e C. Agora você tem dois servidores escravos (B e C) que estão sendo autoritativos para o seu domínio.
3. Reconfigure C como o mestre.
4. Reconfigure B para escravo de C.
5. Deixe as coisas se acalmarem por um dia ou mais.
6. Desativar DNS em A.

Outro truque é usar apenas seus escravos como servidores autoritativos. O servidor mestre não é usado por clientes e existe apenas para manter os arquivos da zona mestre. Os escravos obtêm seus arquivos de zona do mestre, que podem estar escondidos atrás de um firewall para ajudar a evitar adulterações. Você poderia ter um único mestre do qual todos os escravos (através de toda a sua organização), eliminando a sobrecarga administrativa de gerenciar múltiplos mestres.