Como fazer com que o DNS do Windows Server use o arquivo hosts para resolver nomes de host específicos

[NOTA: A solução desta pergunta é perfeita, afastando-se algo do que o título indica.]

Estou enfrentando um pequeno problema com Windows Server 2003 DNS service. Na minha empresa, estou executando o servidor DNS da Microsoft ( 172.16.0.12) para fazer a resolução de nomes na intranet da empresa (o nome de domínio termina em dev.nls. Resolvendo para IP 172.16 .. ) E também é configurado como um encaminhador de DNS para encaminhar outros nomes de domínio ( por exemplo, * .google.com, * .sf.net) para Internet real DNS servers. Esse servidor DNS interno nunca tende a atender usuários de outros países.

E estamos executando um servidor de correio (servindo correio de entrada para um domínio real da Internet @nlscan.com) dentro do firewall da empresa, que pode ser acessado de qualquer maneira:

1. conectando a 172.16.0.10partir da intranet.
2. conectando-se à mail.nlscan.com(resolvido 202.101.116.9) da Internet.

Observe que 172.16.0.10e 202.101.116.9não é a mesma máquina física. Essa 202é uma máquina de firewall que faz o encaminhamento de porta 25e o 110endereço da intranet 172.16.0.10.

Agora, minha pergunta: se os usuários dentro da LAN corporativa quiserem resolver mail.nlscan.com, ele resolve 202.101.116.9. Isso é correto e viável, MAS NÃO É BOM, porque o tráfego de e-mail vai para a máquina do firewall e então volta 172.16.0.10. Espero que internal DNS serverpossamos interceptar o nome mail.nlscan.come resolvê-lo para 172.16.0.10. Então, espero poder escrever uma entrada no arquivo "hosts" 172.16.0.12para fazer isso. Mas, como Microsoft DNS serverreconhecer esse arquivo "hosts"?

Talvez você sugira, por que não usar o usuário da intranet 172.16.0.10para acessar meu servidor de correio? Devo dizer que é inconveniente, suponha que um usuário (funcionário) trabalhe em seu laptop, durante o dia no escritório e durante a noite em casa. Quando ele está em casa, ele não pode usar 172.16.0.10.

Criar uma zona para o nlscan.comnosso interno DNS servernão é viável, porque o servidor de nomes para o nlscan.comdomínio está no nosso ISP e é responsável por resolver outros nomes de host e subdomínios no site nlscan.com.

[EDITAR]

Conforme WesleyDavidsugerido, sigo a solução de simplesmente criar uma zona denominada mailserver.nlscan.come colocar um registro A sem nome nessa zona . O tempo prova que isso funciona bem.

A última parte deste post está errada. Fiquei impressionado, com base em algumas coisas que li na Web (se estiver na Web, deve ser verdade!) Que parte das tarefas do Windows DNS Server Service para criar seu cache era também carregar o arquivo host no cache junto com seus dados da zona local. Eu procurei e não consegui encontrar evidências concretas disso. Testei a teoria em minha própria máquina Server 2008 R2 e descobri que o arquivo hosts não era usado para criar o cache do servidor DNS.

No entanto, acredito que tenho uma solução um pouco mais elegante que a Massimo. Em vez de criar uma zona autorizada para toda a zona nlscan.com, basta criar uma zona denominada mailserver.nlscan.com e colocar um registro A sem nome nessa zona. O registro A sem nome terá o mesmo nome que a própria zona e você poderá atribuir o endereço IP desejado. Todos os outros domínios abaixo do nlscan.com e do próprio nlscan.com serão resolvidos pelo DNS público.

Acabei de testar isso no meu próprio servidor DNS do Server 2008 R2 e consegui resolver o site do meu amigo (nessus.nl) por meio de servidores DNS públicos, mas o subdomínio específico (blog.nessus.nl) resolve para um endereço IP da Apple.com . Experimente e veja se funciona para você.

Postagem mais antiga e incorreta começa:

Se meu entendimento estiver correto (EDIT: e não está), quando o cache DNS é construído na máquina Server 2003, ele extrai entradas do arquivo hosts e dos dados da zona. A colocação 172.16.0.10 mailserver.nlscan.comno arquivo de hosts da máquina Server 2003 deve resolver o problema. Reinicie seus serviços DNS depois de alterar o arquivo hosts.

Use ipconfig / displaydns em qualquer máquina Windows (especificamente, na máquina DNS do Server 2003) para ver as entradas do arquivo host. Lembre-se também de que as respostas negativas são armazenadas em cache em seus clientes; portanto, sempre execute ipconfig / flushdns nos clientes com os quais você está experimentando. Caso contrário, você acabará abusando de vários objetos rígidos enquanto se pergunta por que seus clientes não conseguem resolver um nome digitado em um arquivo de zona / host. =)

Você já tentou isso e falhou?

O desejo de que usuários internos obtenham IPs internos para recursos, enquanto usuários externos obtêm IPs externos para esses mesmos recursos é comum. É referido como DNS de cérebro dividido. Você tem um servidor DNS voltado para a Internet e outro servidor DNS interno para usuários locais. Os usuários internos usam DHCP na sua rede e, no servidor DHCP, você anuncia o servidor DNS interno. Quando seus usuários estiverem fora do escritório, o servidor DHCP deles os atribuirá a um servidor DNS que apenas conhecerá a zona externa.

Você parece querer dividir o DNS do cérebro sem hospedar a zona internamente. Você sugere que hospedar a zona internamente é problemático porque você não deseja que os usuários obtenham o IP interno quando estão trabalhando em casa, mas isso não faz sentido porque, quando estão em casa, estão obtendo o IP de um servidor DHCP diferente que não anunciará seu servidor DNS interno. Ele anunciará o servidor DNS do seu ISP, que saberá apenas sobre sua zona externa e, portanto, fornecerá apenas endereços IP externos.

Por fim, acho que você não terá êxito em solicitar a um servidor DNS que sirva registros do arquivo de hosts no servidor DNS. Um servidor DNS serve registros de seus arquivos de zona. O arquivo de hosts locais nesse servidor DNS propaga entradas para o cache de resolução do cliente local, aplicável apenas às pesquisas nessa máquina. Essas entradas não são atendidas pelo servidor DNS, que é um mecanismo diferente.

Leia o DNS do cérebro dividido - é a maneira normal de lidar com essa situação.

Wes: Não tenho certeza de quem enganou você, mas gostaria de esclarecer o uso do arquivo hosts: O arquivo hosts é usado pelo componente resolvedor de cliente DNS, não pelo componente servidor DNS. Uma entrada no arquivo hosts em um servidor DNS será usada pelo servidor DNS quando estiver atuando como um cliente DNS. Por exemplo, uma entrada nos arquivos hosts do meu servidor DNS W2K8, como esta:

1.1.1.1 test.test.com

é carregado no cache do cliente DNS do servidor DNS (não é o cache do servidor). Se eu executar ping test.test.com no meu servidor DNS, ele retornará a 1.1.1.1 conforme o esperado. Se eu executar o nslookup no servidor DNS e solicitar test.test.com, ele retornará o endereço IP público correto registrado para test.test.com, pois o componente do cliente DNS no servidor DNS agora está pedindo a resolução do componente do servidor DNS (exatamente como qualquer outro cliente DNS faria). É uma idéia confusa, mas o servidor DNS também é um cliente DNS e, quando o componente do cliente DNS é acionado, ele age como qualquer outro cliente DNS, observando seu próprio cache do cliente DNS, incluindo entradas pré-DNS. carregado do arquivo hosts. Somente quando o componente do cliente DNS usar o componente do servidor DNS (consultando os servidores DNS configurados nele ''

Qualquer cliente DNS que consulte o servidor DNS sempre obterá a resposta "real" e não a entrada hosts, porque o cache do cliente DNS do servidor DNS é usado pelo próprio servidor (como cliente DNS) e não pelo componente do servidor DNS.

Até onde eu sei, não há como fazer com que o DNS do Windows use o hostsarquivo para lidar com a resolução de nomes; mas isso não é necessário.

Você pode criar com segurança uma zona no servidor DNS interno com o mesmo nome de uma zona pública da Internet; o que acontecerá é que seu servidor manipulará solicitações de nomes nessa zona usando seus próprios dados, em vez de encaminhar essas solicitações para os servidores de nomes autorizados dessa zona; isso às vezes é chamado de "sombreamento", porque torna a zona pública "real" indisponível para o cliente interno, respondendo com dados "falsos".

Você deve tomar cuidado com o fato de preencher essa zona interna com todos os nomes de que precisará, mesmo usando endereços IP públicos quando necessário; caso contrário, os clientes internos não poderão resolver esses nomes.

Digamos que sua zona pública fique assim:

www.nlscan.com    202.101.116.8
mail.nlscan.com   202.101.116.9

Você deseja que os clientes internos resolvam mail.nlscan.com como 172.16.0.10; tudo bem, então você cria uma zona "nlscan.com" no servidor DNS interno e coloca "mail.nlscan.com -> 172.16.0.10" nela.
Mas agora seus clientes internos não podem resolver "www.nlscan.com", porque o servidor acha que é autoritário para essa zona e, portanto, não responde à consulta (porque não conhece esse host), mas também não o encaminhará a ninguém.
Para resolver isso, você precisa colocar "www.nlscan.com" também dentro da sua zona interna; ele pode apontar para o endereço IP público real, se você quiser que seus clientes acessem dessa maneira, ou você pode usar o mesmo redirecionamento usado para "mail.nlscan.com", se "www" também está sendo encaminhado pelo firewall para algum servidor interno.
O mesmo princípio se aplica a qualquer nome na zona.

Essa configuração não terá impacto em clientes externos ou em nenhum de seus usuários que esteja temporariamente fora da sua rede, porque essa zona de "sombra" interna nunca será visível na Internet.

Não importa o arquivo do host, basta adicionar uma nova zona no DNS mail.domain.com e adicionar um host na zona. deixe o nome em branco (ele usará automaticamente o nome da zona) e insira o endereço IP do servidor de correio local ;-)