Estou familiarizado com a dependência do Active Directory no DNS e as práticas recomendadas em relação ao DNS na nomenclatura do Active Directory (por exemplo, use um subdomínio do domínio corporativo dedicado ao AD). Eu tenho apenas uma pergunta bastante conceitual sobre isso, no entanto:
Quão necessário é que um registro DNS (em qualquer lugar realmente) seja apontado para o controlador de domínio? Por exemplo, digamos que minha rede seja proprietária
example.come eu esteja pensando em alocarad.example.compara o domínio. Como o controlador de domínio é o servidor DNS autoritativo da rede, se você chamá-load.example.com, mesmo sem adicionar um registro DNS CNAME para ele, todas as solicitações no domínioad.example.comserão atendidas corretamente pelo controlador de domínio - e isso realmente não importa se as solicitações externas não forem. Estou esquecendo de algo? Que diferença faz a adição de um registro DNS, já que o DC não deve ser acessível de fora, de qualquer maneira? Você pode fugir sem fazê-lo (funcionalmente)? Esta resposta parece sugerir isso , mas o OP também diz que usa registros DNS públicos.Eu sei que todos criticam isso, mas a maior parte da minha experiência com domínios AD tem visto organizações usarem seu domínio DNS raiz como o nome de domínio AD (por exemplo, apenas
example.com). Supondo que eu também quisesse seguir esse caminho (e não serei dissuadido de fazê-lo), quais são os passos a seguir/coisas a considerar ao fazer isso? Eu continuo ouvindo sobre "conflitos", mas não está claro em que sentido esses conflitos existem. Seriam apenas as solicitações para o siteexample.comque irão para o próprio controlador de domínio, que precisa redirecionar as solicitações com base na porta? Qual é a maneira "adequada" de lidar com esses conflitos quando você reutiliza o domínio raiz para o AD?
Para sua primeira pergunta, não tenho certeza do que você está querendo chegar. Você está dizendo que não acha necessário ter um registro DNS público para seu domínio? Você está certo, você não, tecnicamente . O problema é que seu namespace de domínio deve ser exclusivo em todo o mundo e, se estiver subordinado a um namespace que você já possui, pode ter certeza de que é exclusivo. Torna a vida muito mais fácil se você tiver um namespace público quando se trata de integração posterior
Esse conselho remonta aos dias do Windows 2000 e ainda é relevante.
Para sua segunda pergunta, se você possui um namespace, não coloque seu domínio do AD na raiz desse namespace. Sempre, sempre, sempre, crie um namespace subordinado para seu domínio.
Você não quer controladores de domínio expostos à Internet. Você sempre precisará de algum tipo de "shim" de DNS para separar seus controladores de domínio de seu DNS voltado para o público e, nesse caso, você pode simplesmente hospedar seu namespace raiz lá.
Ter um namespace separado significa que você não terá a dor e a agonia de manter um DNS de cérebro dividido em ordem. Esse link da Dell fornece um resumo muito bom do tipo de problemas que você pode encontrar.
Sim, existem soluções como Infoblox "DNS Views" (até a Microsoft oferece algo assim agora), mas também requer cuidados e alimentação. Você precisa de pessoas qualificadas para configurá-lo e mantê-lo adequadamente. Caso contrário, de acordo com o artigo da Dell, pode ser ( sempre é IME) incrivelmente doloroso se você tiver dois sistemas diferentes "autoritários" para o mesmo namespace sem esses extras.
Se você tiver seus serviços da Web em seu namespace raiz e talvez outras coisas, como outros namespaces para e-mail em massa (para facilitar o SPF) ou sistemas não Windows ou praticamente qualquer serviço de terceiros com o qual você queira compartilhar seu namespace, é muito melhor manter seu domínio separado. Se você quiser fazer essas coisas (dica, se for uma empresa ou organização pública de qualquer descrição, você fará ) .
É um pouquinho de segurança via obscuridade. Não muito, com certeza, mas um pouco.
Do ponto de vista do gerenciamento do sistema, suas delegações e resolvedores de DNS são muito mais fáceis. Você tem seu namespace raiz e esse servidor DNS delega o namespace de domínio subordinado aos DCs, que têm autoridade para ele. Qualquer cliente de domínio pode fazer bons registros DNS seguros, o DNS raiz permanece autoritário para o namespace raiz. A zona DNS do AD pode ser definida com segurança para eliminar registros obsoletos, pois os clientes Windows modernos não têm problema em registrar novamente conforme necessário. Claro que você ainda pode criar entradas estáticas para seus servidores.
Para resolução de nomes, os DCs têm seus resolvedores configurados para apontar para o DNS upstream e, para resolução de nomes de zona externa e raiz, é bom e limpo para clientes de domínio e não domínio. Obviamente, você só permitiria que seus clientes internos sem domínio consultassem o namespace de domínio interno, não clientes externos.
Na verdade, eu recomendaria ter um namespace subordinado separado também para hosts internos não Windows - que podem ser hospedados no DNS upstream ou delegados nos DCs do Windows ou até mesmo em um host DNS completamente separado. Ou, se você só tem um bom Linux moderno para se preocupar, junte-o ao domínio AD, pronto.
Por fim, tenho gerenciado domínios AD desde 2000 (e domínios NT antes disso) e, literalmente, o problema número um que encontrei com o design de domínio é se ele foi feito em um DNS de cérebro dividido no namespace raiz. O temido domínio "single label" está muito abaixo da classificação dos problemas de domínio, porque é bastante raro. Muito mais raro do que esse problema de namespace do AD raiz.
Estou apoiando um ambiente como esse agora. O domínio tem dezenas de milhares de contas e existe desde 2002. Temos centenas de serviços web, serviços em nuvem (provedor de nuvem múltipla), integrações de SAAS e PAAS de terceiros, telefonia, domínios externos com namespaces separados, Windows e não Windows sistemas sem domínio no ambiente -- todos interagindo com esse namespace raiz e/ou o AD interno. A pobre autoridade de design de DNS e eu literalmente passamos horas todo mês puxando nossos cabelos por uma razão ou outra. Há muito manuseio manual para contornar os problemas que ele causa.
Mais uma opção é registrar um namespace completamente separado com o único propósito de hospedar seu domínio, enquanto todas as coisas públicas permanecem no namespace primário. Por exemplo, entidades que registram um enterprise.com/.org para seu namespace público e enterprise.net.cc ou algo assim para seu domínio do Windows. Isso está perfeitamente bem, mas você tem uma sobrecarga de gerenciamento adicional de registrar registros MXes e TXT e criar UPNs personalizados (talvez) para que seu namespace separado se integre a coisas como seus endereços de e-mail públicos/serviços de nuvem. Exequível, mas um pouco mais de despesa e trabalho para não muito benefício. E você precisa garantir que o shadow IT não se infiltre usando o namespace "errado" e, de repente, ele também tenha que ser acessível publicamente.
TL; DR - a razão pela qual não há bons conselhos sobre uma maneira "adequada" de fazer isso é que literalmente não há uma maneira adequada e gerenciável de fazê-lo. Não há benefício em ter seu AD no namespace raiz; há muitas desvantagens se estiver lá.
A menos que você esteja em um ambiente minúsculo e realmente não se importe com o seu AD. Nesse caso, sugiro que você não se preocupe com o AD e simplesmente vá direto para as identidades baseadas em nuvem do Azure AD .
O uso de um subdomínio como raiz de floresta pode ser feito quando houver outros servidores DNS com autoridade para a raiz do domínio que você possui e também para gerenciar sobrecarga. Em um ambiente heterogêneo ( Com Linux, Solaris, outros servidores Windows usando um serviço DNS como QIP (por exemplo), que você não deseja usar para o Active Directory, pois deseja DNS integrado ao AD, o que não é obrigatório, mas recomendado ) onde você está criando um design de AD de campo verde, você designou um domínio especificamente para seus DCs e os clientes e usuários que o DC gerenciaria. , serviços do Azure AD.No ADDNS, você cria um stub para o DNS do domínio raiz para seus clientes e servidores integrados do AD.
Conflito: Acho que é mais uma sobrecarga do que um conflito. Mantemos seus registros de DNS externos no DNS público e internos em seu DNS/ADDNS privado. Em seguida, usamos um endereço de encaminhamento de DNS no ADDNS/DNS privado. Especialmente quando você usa muitos sites e aplicativos hospedados/na nuvem.