DNS público em PCs associados a domínios

Question

Eu tenho um domínio do AD de dois controladores e todos os PCs que fazem parte do domínio têm seus endereços como servidores DNS primários e secundários.

Gostaria de saber se devo configurar um DNS público terciário. O raciocínio é que muitos PCs estão localizados em redes remotas menores e atingem ambos os controladores de domínio por meio de um túnel VPN central. Se o túnel VPN falhar, ambos DCs não estarão disponíveis e os PCs remotos não conseguirão resolver nenhum endereço, impedindo-os de navegar na Internet / verificar email / etc.

Adicionar um DC em cada rede está fora de questão (eles são de 5/10 PCs), e o mesmo pode ser dito sobre a criação de um túnel VPN direto da rede remota para o site DC secundário (devido à capacidade de hardware) .

Um servidor DNS público terciário impediria isso, mas eu me pergunto se isso pode causar problemas (por exemplo: se for, por algum motivo, selecionado como o DNS preferido, o PC será "desconectado" do domínio).

Então: não há problema em usar um DNS público terciário em um PC associado a um domínio ou ele causará problemas? Alguma coisa para estar ciente?

    

Answer 1

Para a funcionalidade adequada do domínio Os computadores Windows precisam ser capazes de realizar pesquisas na zona DNS usada para o AD.

Se os clientes forem apontados para um servidor que não forneça respostas corretas para essa zona do AD, provavelmente esses sistemas falharão em algum momento.

É importante entender que, se um cliente fez uma pesquisa de DNS para um registro como _gc._tcp.yourdomain.example.org ou algum outro registro somente interno contra esse terceiro servidor externo, esse servidor responderá com um erro não encontrado. Seu cliente não tentará novamente essa consulta nos seus controladores de domínio. Uma resposta não encontrada é perfeitamente válida.

Se você quiser um pouco mais de redundância para o DNS em seus sites externos, eu verificaria qualquer dispositivo que esteja executando essa VPN ou o dispositivo que atua como o roteador / firewall. Veja se um desses dispositivos pode atuar como um servidor DNS de armazenamento em cache. Possivelmente você pode obtê-lo para encaminhar as solicitações de DNS interno para os DCs e solicitações não internas para o mundo. Ou, talvez, execute um servidor DNS na nuvem em algum lugar que encaminhe todas as solicitações internas para seus DCs e use qualquer método de recursão para outras solicitações.

    

Answer 2

O que eu faço em nossa rede (muitos pequenos escritórios, todos conectados em uma formação de estrelas aos nossos CDs centrais) é ter um par de pequenos servidores Raspberry Pi baratos em cada escritório. Eu uso dois para resiliência. Estes secundários nosso domínio DNS do AD dos servidores DNS / AD primários, mas também sabem como alcançar o resto do DNS do mundo sem passar pelos DCs.

Se uma VPN de escritório cair, os servidores Pi continuarão a servir DNS, e somente nossos sistemas internos na VPN ficarão temporariamente inacessíveis. Todo o resto continua sem ser afetado.

    

Answer 3

Um DNS em cache usando DCs como fonte primária e DNS público como secundário pode não ser suficiente, pois ainda usaria o DNS público para todas as recursões, respondendo com NXDOMAIN para endereços internos não armazenados em cache quando não há conexão entre Os sites. É por isso que a solução da @ roaima, seja Raspberry Pi, qualquer estação de trabalho convertida em um servidor BIND ou um servidor DNS integrado em seu roteador VPN, seria ideal: eu recomendaria a transferência de zonas completas para todos os sites. Para esse servidor, um DNS público pode ser um encaminhador para o restante, mas eu nunca o enviaria diretamente para os clientes.

Há mais do que apenas o DNS local como um resolvedor para o domínio do AD.

• Se sua VPN de site para site precisa funcionar nas duas direções, uma divisão pode atrasar temporariamente as atualizações de DNS dinâmicas. O DHCP local é capaz de armazenar em cache aqueles ou como isso é organizado, porque o computador cliente não registra automaticamente seu nome DNS quando a divisão termina.

• O perfil correto do Firewall do Windows (domínio / privado / público) é baseado na capacidade de autenticação com o controlador de domínio. Se um cliente for iniciado durante uma divisão, ele poderá ter um perfil incorreto até a próxima reconexão ou reinicialização, o que pode ser pior do que o problema NXDOMAIN .

• Se o site remoto tiver uma conectividade bastante ilimitada para o site principal, o tunelamento dividido em geral poderá tornar sua rede vulnerável, a menos que o roteador VPN também seja um firewall / UTM avançado. Ter o roteador escolhido sabiamente pode tornar a configuração do DNS mais fácil, pois é mais provável que esse tipo de solução tenha um servidor DNS totalmente funcional integrado. Além disso, as configurações são mais fáceis de implantar nos sites em comparação a uma configuração criada do zero.