Um fato interessante que percebo em várias implantações do Active Directory, realizadas algumas vezes por “especialistas” é o uso do nome da organização seguido do sufixo “.local”, “.interno”, “.lan” ou “.intra”, sem falar em outras variações possíveis para o FQDN (Fully Qualified Domain Name) do Active Directory.
O mais comum é o “.local”, a origem dessa prática provavelmente vem do Windows 2008 Small Business Server, que por padrão criava o nome do domínio como “.local”. Logo muitos acreditam que esta é a melhor prática, só que o modelo do Small Business Server (que concentra Windows Server, Exchange, SQL Server em um mesmo servidor), foi projetado para ser implantado em pequenas empresas em que a pessoa que está implantando não tem o conhecimento técnico necessário para realizar uma implantação complexa com vários servidores.
Alguns profissionais, justificam que como “.local” não um TLD (Top Level Domain) válido, isso torna a implementação segura contra ataques externos, o que de fato não procede. Primeiramente você não deve expor seu Active Directory para a Internet, usualmente o seu servidor deve estar em um segmento de rede protegido por Firewall. Outro motivo é que se o servidor estiver exposto, tanto faz se ele está com um TLD válido ou não, para o atacante isso não fará muita diferença.
Outras justificativas, incluem o gerenciamento complexo do DNS, portanto seria mais fácil usar o “.local”. Em partes esta justificativa procede, porém volto a dizer você não deve utilizar os mesmos servidores DNS externos para resolução de nomes internos, até mesmo pelo fato de concepção, o ideal é que o servidor de DNS interno esteja no segmento de rede interno e o servidor de DNS externo esteja em uma DMZ ou algo do tipo, expor o DNS interno publicamente é um risco elevado. Se a organização usa BIND (por exemplo, DNS no Linux) é possível configurar duas zonas com o mesmo nome e com respostas diferentes (conforme a origem da requisição). Mas o ideal no Active Directory é que o DNS seja provido pelos próprios controladores de domínio, afinal o Active Directory é fortemente baseado no DNS.
Vamos voltar um pouco no tempo, no início dos anos 2000, quando o Active Directory surgiu pela primeira vez com o Windows Server 2000, naquela época a Microsoft disponibilizou um guia de melhores práticas para desenho do Active Directory (Best Practices Active Directory Design for Managing Windows Networks), sei que são recomendações de 15 anos atrás, mas continuam válidas. A recomendação é que o domínio do Active Directory (vou me referir simplesmente AD) seja definido com o mesmo nome do seu domínio registrado no “registro.br” ou qualquer outra entidade de registro que garanta a unicidade do nome. Logo se trabalho na organização Exemplo LTDA e o domínio de Internet é exemplo.com.br logo devo usar o mesmo no AD, outra alternativa é utilizar um subdomínio, como ad.exemplo.com.br.
Mas enfim, quais os problemas se eu quiser continuar utilizando “.local” ou outras variações? Bem você poderá ter problemas caso sua organização venha a se fundir com outra, ser adquirida ou comprar outra organização que por azar pode possuir o mesmo domínio no AD com a terminação “.local”. Sei que essa possibilidade é remota, então vou lhe fornecer mais um motivo: Existe uma orientação do CA/Browser Fórum que não recomenda a emissão de certificados emitidos por uma autoridade certificadora para domínios não válidos (https://cabforum.org/wp-content/uploads/Guidance-Deprecated-Internal-Names.pdf).
Ok, sei que os defensores da prática podem alegar que ainda será possível gerar certificados auto-assinados no AD e distribuí-los para as máquinas, mas penso que o melhor caminho é seguir as práticas recomendadas.
Outra questão que merece atenção, vejo que estas implementações “.local” (e suas variações) o nome NetBios por muitas vezes é denominado AD ou SERVER, ou seja quando o usuário vai efetuar logon, teremos algo semelhante a: ADfulano.siclano. Voltando a nossa organização Exemplo LTDA, seria mais elegante utilizar o nome “EXEMPLO” e termos algo como: EXEMPLOfulano.siclano.
Deve-se considerar que você pode ter problemas utilizando FQDN’s personalizados, se você algum dia precisar implantar DNSSEC, poderá ter problemas, sem contar que os equipamentos da Apple utilizam o serviço Bonjour de descoberta e configuração automática de dispositivos que por sua vez usa o sufixo ”. local” nativamente, talvez isso possa gerar problemas, caso o diretor (ou outro colaborador) da organização prefira trabalhar utilizando um dispositivo da Apple na sua rede.
Se você gostou do artigo, talvez você goste também de conversar e ser atendido por nossos especialistas em serviços de infraestrutura de servidores Windows e Linux, virtualizado, local ou em nuvem. Ligue 0800 494 9001 ou acesse https://info.infomach.com.br/contato_especialista
