Outubro 2007

Muitos administradores de “primeira viagem” já passaram por problemas no que se refere à resolução de nomes em redes com domínios internos e externos iguais. Dentre algumas saídas, podemos citar a arquitetura “Split DNS”. Esta solução é muito útil nos quesitos segurança, organização e boa prática. Podemos inclusive utilizar um servidor DNS de baixo custo, opensource etc.

Vamos iniciar com um exemplo, no caso um domínio interno chamado “empresa.com”. Como clientes da rede interna, acessaremos os servidores desta rede utilizando o nome completamente qualificado, ou FQDN (Full Qualified Domain Name). Estes nomes serão resolvidos utilizando os servidores DNS que contêm os registros para a zona em questão. Para simplificar, o próprio Domain Controller de empresa.com fará este trabalho para os clientes da rede interna.

Agora, vamos supor que estes servidores da rede interna serão acessados também por clientes externos, resolvendo os nomes utilizando o mesmo servidor DNS interno. Com isso, nossa arquitetura possuirá apenas um servidor DNS, ou “single DNS”.

Teríamos então os seguintes registros, como exemplo:

www              A      200.0.0.1
ftp                 A      200.0.0.1
mail              A      200.0.0.2
emp-web-01   A      10.0.0.2
emp-exc-01   A      10.0.0.4
emp-ftp-02     A      10.0.0.5

Quando um host externo deseja acessar algum recurso, como exemplo www.empresa.com, o servidor DNS resolverá o nome solicitado para o IP 200.0.0.1 e o cliente acessará o serviço web em questão, localizado na rede interna. No caso, é a máquina de nome “emp-web-01” ou “emp-web-01.empresa.com.”

O mesmo procedimento vale para os hosts internos acessando estes recursos, mas há casos em que a comunicação será finalizada, resultando em falha.

Como funciona o processo?

O cliente solicita a resolução de algum nome. O servidor DNS responde com o IP público do serviço solicitado e o cliente utiliza este endereço para acessar o recurso. Quando a requisição chega ao ISA Server/Roteador, verifica-se que o IP em questão é de “sua propriedade”, gerando loopback para o cliente, que envia então a requisição para a interface externa do ISA Server/Roteador. Este por sua vez, encaminha a requisição para o servidor, que responderá ao solicitante (ISA Server ou um roteador, chegando finalmente ao cliente).

No caso do ISA Server, a falha ocorre basicamente com clientes Secure NAT pois este não espera uma resposta direta do servidor, e sim do próprio ISA Server.

Para clientes de firewall do ISA Server ou proxy, este problema não ocorre, bem como para clientes de roteadores “de mesa” (D-link, Linksys, Netgear etc.).

Solução Proposta

Existem algumas maneiras de se resolver este problema, mas a adoção da arquitetura “Split DNS” é a mais “bonita”. Se resume à utilização de outro servidor DNS, que atenderá às resoluções externas e também fará a “separação” de alguns registros da MESMA zona. Pode parecer estranho, mas teremos dois registros SOA (Start of Authority) para o mesmo domínio (um registro SOA em cada servidor DNS). Sim, pois um pertence ao Domain Controller do Active Directory e o outro ao Name Server(NS) que será registrado nos órgãos competentes na internet como sendo o Servidor de Nomes para empresa.com. Como não há replicações entre estes servidores, não há problema algum.

Lembre que não é possível criar a mesma zona no MESMO servidor DNS! Nem pense nisso!

Voltando aos registros da zona DNS, teremos os seguintes dados para o servidor que responderá à rede externa:

www                  A         200.0.0.1
ftp                     A         200.0.0.1
mail                   A         200.0.0.2
empresa.com.    MX 10  mail.empresa.com.

E para a rede interna:

www          CNAME   emp-web-01.empresa.com.
ftp             CNAME   emp-ftp-02.empresa.com.
mail          CNAME   emp-exc-01.empresa.com.
emp-web-01   A        10.0.0.2
emp-exc-01   A        10.0.0.4
emp-ftp-02     A        10.0.0.5

Assim, os clientes externos resolverão os registros de empresa.com utilizando o servidor designado para tal, validando todo o processo.

Os clientes internos acessarão os mesmos recursos, porém suas consultas serão resolvidas pelo DNS interno, no caso, nosso DC de empresa.com.

A figura abaixo demonstra a solução (resumida):

Dicas:  

- Para melhorar ainda mais o processo, podemos incluir o domínio interno na configuração de proxy do ISA Server informando que servidores pertencentes à este domínio serão acessados diretamente. É uma boa prática.

Procure pela LDT – Local Domain Table e adicione *.empresa.com.

- Além disso, podemos colocar o servidor DNS e os demais Web Servers em uma DMZ (...)

- Veja também o artigo sobre otimização de tráfego DNS utilizando o ISA Server.

Um abraço e até a próxima!