Situação:
- Temos um site de DR que precisa ser testado
Há uma mistura de hosts Linux e Windows no site de DR. Em caso de desastre, se o SERVER no site de produção não estiver disponível, o SERVER_DR no DR será ativado e associado ao mesmo domínio do Windows. não está disponível e não queremos excluir o registro original do formulário SERVER AD.
O problema que estou tentando resolver é uma resolução de nomes no site de DR. Processos e scripts estão usando o nome DNS SERVER, portanto, nas solicitações do site de DR para SERVER, devem ser traduzidas para SERVER_DR. Não temos acesso para fazer nada no DNS do Windows.
Minha ideia é usar o BIND para resolver esse problema. Os hosts no DR devem ser capazes de se autenticar com o AD. O fato de que eles não precisam acessar mais nada fora do site do DR no domínio do Windows deve simplificar o problema.
Os serviços que precisam ser acessados por hosts DR são principalmente compartilhamento de arquivos e servidores SQL. Acredito que os servidores SQL talvez sejam um problema aqui, já que eles usam SPN
Isso traz uma ideia de usar o BIND para a zona our.domain.com mantida pelo BIND no site DR, no entanto, posso ver um possível problema quando os hosts do Windows DR precisam se autenticar no AD, pois precisam usar registros não registrados, se bem me lembro. delegar zonas do AD devido aos motivos que mencionei anteriormente.
Vale a pena resolver esse problema? Um de meus colegas sugeriu usar o arquivo hosts para cada host do Windows DR. No entanto, parece muito feio, não há muitos deles e meu tempo configurando o BIND pode ser desperdiçado.
Responder1
Os arquivos HOSTS não farão com que a autenticação do AD funcione corretamente. A autenticação AD precisa dos RR SRV que somente um servidor DNS pode fornecer (já que um arquivo HOSTS é apenas A RR).
Dê uma olhada aqui: uma resposta anterior que dei sobre o uso do BIND para oferecer suporte ao AD:Usando BIND9 e DHCPD para oferecer suporte a um domínio Windows
Você terá problemas com alguns softwares funcionando corretamente se os nomes dos computadores do servidor Windows forem diferentes. Apenas tentar "alias" o nome não-DR para um servidor Windows com um conjunto de nomes de computador diferente funcionará para alguns protocolos, mas outros cairão de cara no chão (SPNs no AD, por exemplo, estão "ligados" ao computador nomes).
Não está claro para mim por que você não pode usar o DNS do Windows no site de DR. Eu acho que você poderia ativar um servidor DNS do Windows e, se o pior acontecer, delegar a zona _msdcs.domain.com ao servidor DNS do Windows na infraestrutura BIND existente.
Acho que precisaria entender um pouco mais sobre o que você está tentando realizar e por que tem as restrições que tem, mas, em geral, eu estaria trabalhando para tornar o ambiente de DR o mais próximo possível do ambiente de produção, para que que você tenha uma quantidade mínima de trabalho a fazer ao mover operações para o ambiente de DR.
Responder2
Não há uma maneira fácil de fazer com que os hosts no site de DR resolvam "SERVER" para o endereço IP de SERVER_DR e, ao mesmo tempo, mantenha todo o material AD DNS funcionando. O que você precisa fazer é usar um alias para todas as referências do servidor.
Minha abordagem usual é criar um novo domínio (por exemplo, meudomínio.site) que não seja inteiro do AD. Isso permite que você use arquivos de zona separados e diferentes para diferentes servidores DNS. Em seguida, altere todas as referências aos seus servidores para server.mydomain.site. Isso permite que seus usuários usem um único nome de servidor que resolva o que for apropriado para o site.
Observação: para que o compartilhamento de arquivos do Windows funcione com um alias CNAME, você precisa adicionar uma entrada de registro para o serviço LanManServer. Verhttp://support.microsoft.com/kb/281308para detalhes. Isso funciona em W2k8, bem como em 2k e 2k3.
Eu recomendo fortemente que você use o DNS do Windows para hospedar o domínio .site. Se você realmente não consegue persuadir seus administradores de sistema a ajudar, você pode usar o BIND e configurar os servidores DNS do Windows como encaminhadores. Então o BIND resolveria o domínio .site enquanto o Windows seria usado para todos os outros domínios, incluindo o domínio AD. No entanto, isso torna as coisas mais complexas de manter, então eu evitaria isso se puder.
Jr.
PS re "NB para compartilhamento de arquivos do Windows para funcionar com um alias CNAME"
O objetivo de usar o alias é que você pode navegar em compartilhamentos ou mapear unidades de rede usando nomes UNC como \myserver.mydomain.site\share, onde o nome "myserver.mydomain.site" resolve o endereço IP do seu servidor de destino e pode resolver para diferentes endereços IP em diferentes sites. Por padrão, o serviço LanManServer não permitirá a navegação, a menos que o nome do servidor corresponda ao nome real do servidor, e você receberá uma mensagem de erro como "Existe um nome duplicado na rede". Isso é feito para aumentar a segurança. O artigo da base de conhecimento que mencionei descreve como desativar a verificação de nomes para que nomes UNC como os acima funcionem.
Na verdade, eu uso esse truque rotineiramente porque facilita a movimentação de compartilhamentos de arquivos para servidores diferentes. Não substitui o DFS, mas pode ser um truque útil.