As práticas recomendadas para o design do domínio do AD (Active Directory) aconselham o uso de um nome de domínio registrado como o nome de um domínio do AD. As alternativas viáveis incluem o uso de um sufixo de DNS não público (. local ou . LAN, por exemplo) no nome de domínio do AD, ou tornando o domínio do AD um subdomínio do domínio registrado (Corp.domain.com, por exemplo).
No entanto, você não terá sempre uma opção nisso. Você pode se familiarizar com o domínio do AD que tem o mesmo nome que o domínio registrado da empresa e o gerenciamento pode não querer alterar nenhum dos nomes. Isso é conhecido como um cenário de DNS dividido (ou DNS de divisões), no qual há dois namespaces distintos de DNS – o namespace interno usado pelo AD e o namespace externo usado pelo registrador de domínio público-com o mesmo nome. Esse cenário pode apresentar alguns desafios exclusivos. Este artigo discute alguns problemas comuns que resultam em um ambiente de DNS dividido e o que pode ser feito para reduzi-los.
Em todos os exemplos a seguir, o domínio do AD e o domínio registrado são nomeados como Domain.come há um site da empresa chamado www.domain.com.
Problema 1: Site da empresa hospedado externamente inacessível de dentro do escritório
Esse é o problema mais comum em um ambiente de DNS dividido: o site da empresa, ou outro proprietário da empresa, o recurso de conexão à Internet, não pode ser acessado a partir do escritório por máquinas associadas ao domínio do AD, mas as máquinas fora do escritório não têm problemas para acessar o site. O motivo pelo qual isso acontece pode ser mostrado ao analisar o que acontece quando um usuário interno tenta navegar no site da empresa:
O problema surge porque um servidor de DNS que tem uma zona de pesquisa específica em seu banco de dados — a zona Domain.com neste exemplo-não envia consultas para registros da zona em qualquer outro lugar; Ele simplesmente devolve uma resposta "Not Found" se não houver nenhum registro correspondente a uma consulta específica. Neste exemplo, há outro servidor de DNS com o registro correto: o DNS servidor que hospeda a zona pública Domain.com que pertence ao registro de domínio, visto que o está evidente pelo fato de que as máquinas fora do escritório podem acessar o site. Consultas dos computadores internos nunca chegam a esse servidor.
A solução para esse problema é simples: Crie um registro de host chamado www na zona Domain.com no DC e conceda o registro ao endereço IP do site. Máquinas que consultam esse DNS servidor, em seguida, recebem a resposta correta e poderão navegar no site.
Problema 2: Site público hospedado internamente inacessível de dentro do escritório
Isso pode ser considerado uma variação do problema 1 acima. A diferença, nesse caso, é que o site é hospedado internamente, seja por trás de um firewall na rede interna da empresa ou em uma DMZ. Ele deve estar acessível para usuários internos e externos, mas usuários internos não conseguem contatá-lo, enquanto os usuários externos não relatam problemas.
O motivo para o problema é semelhante ao do problema 1, mas os usuários internos neste caso são capazes de resolver corretamente o nome do site para o endereço IP público. No entanto, eles ainda não conseguem acessar o site devido à maneira como o firewall está configurado. Ele espera que os usuários da rede interna acessem o site usando seu endereço privado em vez de seu endereço público.
Mais uma vez, há uma correção simples: Crie um registro de host chamado www na zona Domain.com no DC, mas desta vez dê ao registro o endereço IP privado do site. As máquinas internas resolvem o nome do site para esse endereço privado, enquanto as máquinas externas continuam a resolver o nome para o endereço público do site.
Problema 3: O site é carregado incompletomente ou ainda não carrega depois que as alterações acima são feitas
Isso pode ocorrer se o código do site redireciona os navegadores de www.domain.com para Domain.com ou se links internos referem-se ao site como Domain.com em vez de www.domain.com. Os mesmos sintomas são vistos em máquinas internas, se o local for hospedado interna ou externamente:
O problema neste caso é um pouco mais complexo. Para que as máquinas resolvam Domain.com para um endereço IP, deve haver um registro de host em branco na zona Domain.com em DNS. O nome desse registro aparece como (igual à pasta pai) no console de DNS Windows. No entanto, há um problema neste caso: O AD usa registros de host em branco na zona Domain.com para representar os DCS para o domínio Domain.com . Os membros do domínio usam esses registros ao localizar um DC para autenticação, e se houver registros de host em branco extras na zona do Domain.com , podem ocorrer atrasos ou problemas de autenticação.
Para o motivo acima, esse problema não pode ser resolvido somente no DNS. A criação de um registro de host em branco com o endereço IP do site resolve exclusivamente o problema de acesso ao site para usuários internos, porque já existem outros registros de host em branco com os endereços IP dos DCs no domínio e isso causa problemas de autenticação de domínio.
A maneira mais simples de resolver esse problema é modificar o código do site para remover o redirecionamento ou corrigir os links internos para que tudo se refere ao site como www.domain.com em vez de Domain.com. Se modificar o código não for possível, a única opção para resolver o problema é renomear o domínio do AD. Pode ser uma tarefa complexa, dependendo do tamanho e da complexidade do ambiente.