Estrutura do DNS e Design
Neste artigo, finalizamos o estudo de DNS no Active Directory onde veremos agora sua estrutura interna.
A estrutura do DNS é algo muito importante. Quando desenhos a estrutura do servidor DNS que iremos trabalhar, é importante manter em mente certos princípios e boas práticas que afetam consideravelmente a performance de como um servidor de nomes trabalha em toda a rede. Você deve ter percebido isso no nosso artigo anterior, onde configuramos passo-a-passo um DNS server.
O que nos credencia a irmos de encontro as melhores práticas no momento de criação da estrutura, é extremamente importante para termos um ambiente eficiente e produtivo. Isso é óbvio, claro, e parece redundante, mas como eu costumo dizer ..." quem falha ao planejar, planeja em falhar...".
Um ponto chave no desenvolvimento de uma estrutura sadia de servidores DNS, envolve o uso das ADI, Active Directory Integrad zones.
Uma ADI zone é uma cópia de uma zona de pesquisa direta que onde está hospedado a um controlador de domínio. Este é um requisito importante pois os registros de DNS estão todos detidos no Active Directory, portanto, o servidor DNS precisa acessar o AD e hospeda uma cópia gravável na zona de DNS, onde os clientes (estações de trabalho, servidores e outros DCs).
Então, como é uma estrutura de DNS usando zonas integradas ao Active Directory?
ADI zones só podem ser hospedados em hosts DCs. No entanto, muitos administradores querem colocar servidores de nome de domínio em locais remotos para fornecer um melhor desempenho de resolução de nomes e para diminuir o tráfego de rede. Dessa forma, os usuários não têm que atravessar a WAN para encontrar um servidor DNS. No entanto, um administrador pode não querer colocar um DC no local. Windows Server 2000 e Windows Server 2003 permitem que os administradores coloquem uma zona secundária padrão (somente leitura) em um servidor por exemplo, e utilizar um dos servidores ADI primária como master.
Entendo melhor. A regra é que uma zona ADI primária só pode existir em um DC Host, ou seja onde você configurou e hospedou, mas os administradores podem ter um padrão secundário dessa zona em um servidor.
Assim, os clientes podem se conectar ao seu servidor DNS local se está hospedando a ADI primária ou secundária. Quando um cliente (DC, servidor membro ou estação de trabalho) tenta registrar, entretanto, só pode registrar em um servidor DNS que hospeda a zona primária ADI. Se os pontos do cliente para um servidor que hospeda um secundário, o cliente irá receber simplesmente uma referência de uma das primárias que já está registrado.
Protegendo o DNS server
Proteger seu DNS server deve ser uma grande prioridade para você como administrador de sua rede. Muitas das funções e recursos do Active Directory usam DNS para localiza controladores de domínios, sistemas, serviços,clients e outros objetos. Lembra-se quando falamos como o Active Directory trabalha com os objetos? Senão, clique nos links abaixo, para ler meu arquivos de introdução.
//www.devmedia.com.br/Introducao-ao-Active-Directory-Parte-1/21149
https://www.devmedia.com.br/organizacao-interna-no-active-directory-parte-2/21150
Bom, basicamente falando, se um DNS falha então o Active Directory também falhará, pois a configuração ou sua manutenção por parte de seus clientes, deixará muitos dos serviços, para não falar em todos, inativos para a maioria deles.
Dessa forma, imagine que se o DNS falha, uma requisição na rede pode ser nula, falha, sem efeito nenhum. Ou seja os clientes vão te ligar avisando que não conseguem acessar nada...
Primeiro e acima de tudo, estabilizar e assegurar que a mesma concepção, de execução e procedimentos de implantação para os servidores de DNS, como tenho recomendado para o seu anúncio DCs, estão sendo seguidos. Senão se recorda, lembre-se de configurá-lo de acordo com as boas práticas, ver a zona correta, agrupar clients, perfis, gerenciar quotas, etc..
Depois considere a implementação segura com testes de comunicação dos DNS, para ver se está tento um desempenho regular, monitorando todo o tráfego da rede(você pode usar diversas ferramentas para isso, como não é o foco inicial desse artigo, não vou entrar nessa questão agora), re-avaliar as portas que estão ou ficaram abertas no Firewall, verificando sua real necessidade, e se não tem nada passando despercebido. Consumos de antivírus, por exemplo que ficam tentando acessar um Host para atualiza-se, podem consumir tráfego de dados em horários que muitos usuários estão trabalhando e isso pode causar um grande desconforto. Sugiro colocar algumas rotinas de segurança ou proativas em horários que tenham menos ou nenhuma conexão.
Isso irá minimizar ou eliminar problemas aleatórios ou desconhecidos na sua rede, pois a maiorias dos processos estarão mapeados com você.
Uma das melhores maneiras de implementar a segurança e tratamento é com um framework chamado IPSec, que seta configurações de protocolos para segurança da rede ou camadas de comunicação entre pacotes.
Importante: Enquanto o IPSec funciona em todo o sistema, poderá gerar uma diminuição na performance de toda a rede, mas isso é por causa dos seu funcionamento de criptografia/descriptografia em todas as comunicações, muitos especialistas dizem que o aumento na segurança deve ser mais importante que uma ligeira queda no desempenho da rede.
Isso varia de caso para caso, ok? Você tem que analisar o seu problema, de acordo com a sua vivência na sua rede, no seu ambiente de trabalho.
Ao analisar o ambiente, você tem uma idéia do tráfego, de portas abertas no firewall, que te garantem por experiência e vivência, um estudo sobre padrões, e identificar o que é normal ou anormal na sua rede.
