메인 콘텐츠로 이동
  • 빠르고 간편하게 주문
  • 주문 보기 및 배송 상태 추적
  • 제품 목록을 생성 및 액세스
  • 회사 관리를 사용하여 Dell EMC 사이트, 제품 및 제품 수준 연락처를 관리하십시오.

DNS considerações em um ambiente de Windows com nomes de domínio internos e externos idênticos

요약: Este artigo apresenta informações sobre os problemas que podem surgir em um ambiente no qual o domínio do Active Directory e o nome do domínio da Internet registrados são idênticos. ...

이 문서는 자동으로 번역되었을 수 있습니다. 번역 품질에 대한 의견이 있는 경우 페이지 하단의 양식을 사용해 알려 주시기 바랍니다.

문서 콘텐츠


증상

 


 

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:

  1. O computador do usuário consulta o servidor de DNS do domínio, geralmente um controlador de domínio (DC), para o endereço IP do www.domain.com.
  2. O DC hospeda uma zona de pesquisa direta chamada Domain.com, para que ele pesquise em uma zona para um registro de host chamado www.
  3. O DC localiza nenhum registro de host chamado www, e, uma vez que ele é autoritativo para a zona do Domain.com , ele não consulta nenhum outro servidor DNS.
  4. O DC responde ao computador do usuário, informando que não foi possível encontrar um endereço para www.domain.com.
  5. O navegador no computador do usuário exibe a mensagem "não é possível exibir a página".
 

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 site pode não carregar tudo, caso em que o navegador do usuário normalmente mostra Domain.com na barra de endereços, mesmo se o usuário digitar www.domain.com no navegador.
  • O site pode ser carregado incompletomente; partes do site podem não ser exibidas e/ou links no site podem não funcionar.
  • Em ambos os casos, os usuários externos podem acessar o site sem problemas.
 

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.
  

원인

Consulte a seção sintoma

해결

Consulte a seção sintoma

문서 속성


영향을 받는 제품

Servers

마지막 게시 날짜

01 11월 2023

버전

6

문서 유형

Solution