DNS público em PCs ingressados ​​no domínio

Para uma funcionalidade de domínio adequada, os computadores Windows precisam ser capazes de realizar pesquisas na zona DNS que está sendo usada para o AD.

Se os clientes forem apontados para um servidor que não fornece respostas corretas para essa zona do AD, esses sistemas provavelmente serão interrompidos em algum momento.

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

Se você quiser um pouco mais de redundância para DNS em seus sites externos, eu examinaria qualquer dispositivo que esteja executando essa VPN ou o dispositivo que atua como roteador/firewall. Veja se um desses dispositivos pode atuar como um servidor DNS de cache. Possivelmente você pode fazer com que ele encaminhe as solicitações internas de DNS 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.

O que eu faço em nossa rede (muitos escritórios minúsculos, todos ligados em formação de estrela aos nossos DCs centrais) é ter um par de pequenos servidores Raspberry Pi baratos em cada escritório. Eu uso dois para resiliência. Estes são secundários ao nosso domínio AD DNS 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 atendendo ao DNS e apenas nossos sistemas internos na VPN ficarão temporariamente inacessíveis. Todo o resto continua inalterado.

Um DNS de 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 toda a recursão, respondendo com NXDOMAINendereços internos não armazenados em cache quando não houver conexão entre os sites. É por isso que a solução da @roaima, seja Raspberry Pi, qualquer estação de trabalho convertida em servidor BIND ou servidor DNS embutido em seu roteador VPN, seria ideal: eu recomendaria ter zonas completas transferidas para todos os sites. Para este servidor, um DNS público pode ser um encaminhador para o resto, 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 site a site tiver que funcionar em ambas as direções, uma divisão pode interromper temporariamente as atualizações dinâmicas de DNS. O DHCP local é capaz de armazená-los em cache ou como isso é organizado, porque o computador cliente não registra novamente 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 pode ter um perfil errado até a próxima reconexão ou reinicialização, o que pode ser pior do que o NXDOMAINproblema.

• Se o site remoto tiver conectividade bastante ilimitada com o site principal, o túnel dividido em geral pode tornar sua rede vulnerável, a menos que seu roteador VPN também seja um firewall / UTM avançado. Ter o roteador escolhido com sabedoria pode realmente facilitar a configuração do seu DNS, pois esse tipo de solução é mais provável que 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 com uma configuração criada do zero.