Resolver problemas de DNS num domínio do Active Directory que termina em .com em vez de .local

Question

Acabei de começar a trabalhar para um cliente que tinha uma empresa de TI anterior para configurar seu domínio. Eles têm cerca de 30 computadores em seu domínio e estão executando o Server 2008 com o Microsoft Exchange 2007.

O cara de TI anterior nomeou seu domínio com um .com em vez de um local, apesar do fato de NÃO possuírem o endereço real .com. Para fins de argumentação, chamaremos o domínio deles: contoso.com. Todas as redes eu trabalho no final em .local.

Isso causa problemas porque todos os computadores em um domínio são tecnicamente subdomínios. Portanto, se o domínio for contoso.local e o nome do computador for computer1, o FQDN do computador local será computer1.contoso.local. Quando você tenta acessar um compartilhamento de rede no computador2 ou faz ping no computador2, ele procura o FQDN no DNS para resolver o endereço IP. Porque eles estão usando contoso.com, ele tenta pesquisar computer2.contoso.com. Desde que o computador tenha se registrado no DNS e exista, ele será encontrado.

Quando faço ping em algo que faz o sitentexist.contoso.com, em vez de falhar no ping, literalmente começo a obter respostas de ping de um endereço IP público. As únicas configurações de DNS em todos os computadores na rede apontam para nossos controladores de domínio. Os dois controladores de domínio apontam apenas para si próprios. Há um fowarder no servidor DNS no controlador de domínio primário para os servidores DNS do ISP, além dos dois servidores, como backups. Se eu não tivesse nenhum encaminhamento, nada na rede seria capaz de resolver os endereços IP da Internet.

No entanto, programas como o Outlook 2007, que automaticamente tentam e configuram com base em subdomínios de adivinhação, estão em um rude despertar. Quando não existe um endereço no servidor DNS local para, digamos, mail.contoso.com, ele encaminha os servidores DNS de nosso provedor que informam um endereço IP público (não pertencente ao meu cliente). Isso está causando muitas dores de cabeça e aborrecimentos, além do fato de que o Outlook 2007 não irá autoconfigurar.

Eu me resignei ao fato de que mudar de .com para .local seria muito trabalho, especialmente porque o Exchange está envolvido. Então, minha pergunta é, como faço para desativar o DNS de encaminhar solicitações terminando em contoso.com? Isso seria uma solução rápida.

Além disso, eu estaria aberto a qualquer sugestão sobre a mudança de .com para .local se não envolver o risco do domínio atual e a recriação de tudo.

(Em resposta a Joseph Kern ...)

Expliquei a situação para o cliente. Este é um dos maiores problemas com os quais estamos lidando. É por isso que o último cara foi demitido. Ao contrário dos outros problemas, não tenho ideia de por onde começar com este.

Obrigado!

    

Answer 1

Você não deveria estar usando .local também ... .local deveria ser usado com o DNS multicast, que é um padrão real da Internet. Você deve usar um nome de domínio válido que você tenha o direito de usar ou um dos TLDs reservados do RFC 2606.

As correções para este problema são registrar o nome que está em uso ou migrar um novo domínio com um nome válido.

As "correções rápidas" das quais você está falando são hacks que provavelmente causarão problemas. Seu cliente pode não estar disposto a pagar por uma solução real, mas eles precisam ser educados sobre eles e entender as escolhas que estão fazendo.

    

Answer 2

Parece que você precisa renomear um domínio, mas, infelizmente, a renomeação de domínio não é "suportada" em um Exchange Ambiente de 2007 . É bastante irritante, na verdade.

Na superfície, parece que você está falando sobre o antigo problema "nomeamos nosso domínio do Active Directory como nosso nome de domínio da Internet", exceto que o nome escolhido era de outra pessoa Nome de domínio da Internet.

O que eu não sigo, no entanto, é a sua declaração "Quando não existe um endereço no servidor DNS local para, digamos, mail.contoso.com, ele encaminha os servidores DNS de nosso provedor que informam um IP público endereço (não pertencente ao meu cliente) ". O servidor DNS da Microsoft não encaminhará solicitações de nomes em um domínio autoritativo. Sua declaração me deixa perplexa. Se os seus servidores DNS internos forem autoritativos para "contoso.com", eles nunca encaminharão solicitações para a Internet ".contoso.com". Período.

Parece-me que você pode ter servidores DNS públicos especificados nas propriedades de NIC cliente ou servidor ou opções DHCP e esses servidores DNS públicos estão resolvendo a versão da Internet de "contoso.com" para seus clientes. Você nunca deve especificar servidores DNS não controladores de domínio nas propriedades da NIC de qualquer computador associado a um domínio do AD (a menos que você realmente saiba por que está fazendo isso).

Então, você tem servidores DNS públicos especificados nas propriedades da NIC ou opções de DHCP para computadores cliente e / ou servidor?

    

Answer 3

Embora não seja a melhor situação, certamente não é o fim do mundo. No final do dia, a única coisa afetada deve ser o acesso ao domínio "real" contoso.com.

Pelo que você disse, parece haver algo errado com o DNS interno. Como Evan apontou, seus servidores DNS internos são autoritários para o domínio contoso.com e nunca devem encaminhar solicitações para esse domínio a nenhum outro servidor de nomes. Além disso, o fato de você não conseguir resolver registros DNS externos sem o uso de encaminhadores informa que seus servidores DNS não estão configurados para usar os servidores de dica de raiz. Isso vai funcionar, mas IMHO não é a melhor configuração para acompanhar. Você está completamente dependente da operação segura, estável e confiável desses forwarders. Se eles estão quebrados, você está quebrado (para registros de DNS externos).

Minha sugestão como primeiro passo seria executar um sniffer de pacotes em uma de suas máquinas clientes, filtrar DNS e tentar resolver registros DNS inexistentes no domínio contoso.com. Observe a captura e veja exatamente onde as consultas ao DNS estão indo e quais respostas estão sendo retornadas e de onde. Em seguida, faça a mesma coisa no próximo "link da cadeia", significando que, se as consultas forem enviadas e respondidas pelos servidores DNS internos, execute a mesma captura nos servidores DNS internos e veja o que é exibido.

    

Answer 4

So my question is, how do I disable DNS from fowarding requests ending in contoso.com? This would be a quick fix.

Isso me faz querer chorar. Eu entendo suas restrições de tempo, mas ...

Isso não está corrigindo o problema, se você tentar passar por cima, você estará causando o mesmo dano que o "admin" anterior.

Você já resolveu isso com seu cliente?

    

Answer 5

Embora existam maneiras de fazer isso funcionar com um DNS dividido, sua melhor opção para consertar esse longo prazo é fazer uma migração para uma nova floresta. Confira o guia de migração do ADMT 3.0 para detalhes. Isso permitirá que você não precise descartar todo o seu ambiente

    

Answer 6

Este é o Exchange 2007? Defina o AutoDiscoverInternalServiceUri no (s) servidor (es) CAS para o URL interno correto. O Outlook vai olhar para o SCP isso publica primeiro.