Nomeando uma nova floresta do Active Directory - por que o DNS de split-horizon não é recomendado?

Question

Espero que , todos sabem quais são as recomendações para nomear uma floresta do Active Directory , e eles são bem simples. Ou seja, pode ser resumido em uma única frase.

Use um subdomínio de um nome de domínio registrado existente e escolha um que seja não será usado externamente. Por exemplo, se eu fosse incorporar e registrar o domínio hopelessn00b.com , minha floresta interna do AD deveria ser denominada internal.hopelessn00b.com ou ad.hopelessn00b.com ou corp.hopelessn00b.com .

Existem razões esmagadoras para evitar o uso de "fake" tlds ou nomes de domínio de rótulo único , mas estou tendo dificuldade em encontrar de maneira semelhante Razões convincentes para evitar o uso do domínio raiz ( hopelessn00b.com ) como meu nome de domínio e usar um subdomínio como corp.hopelessn00b.com . Realmente, a única justificativa que consigo encontrar é que acessar o site externo de dentro requer um registro de A name DNS e digitar www. na frente do nome do site em um navegador, o que é muito "meh" quanto a problemas vai.

Então, o que estou perdendo? Por que é muito melhor usar ad.hopelessn00b.com como meu nome de floresta do Active Directory em relação a hopelessn00b.com ?

Apenas para registro, é realmente meu empregador que precisa ser convencido - o chefe está revidando, e depois de me dar o aval para criar uma nova floresta do AD chamada corp.hopelessn00b'semployer.com para a nossa rede interna, ele está querendo ficar com uma floresta do AD denominada hopelessn00b'semployer.com (igual ao nosso domínio registrado externamente). Espero conseguir alguma razão ou razão que a melhor prática seja a melhor opção, para que eu possa convencê-lo disso ... porque parece mais fácil do que desistir da raiva e / ou encontrar um novo emprego, pelo menos para o momento. No momento, as "práticas recomendadas da Microsoft" e o acesso interno ao site público da nossa empresa parecem não estar sendo cortados, e eu sou muito , muito , realmente esperando que alguém aqui tenha algo mais convincente.

    

Answer 1

Tanta repetição a ser obtida. Venha a mim precioso.

Ok, então é muito bem documentado pela Microsoft que você não deve usar o split-horizon, ou um TLD inventado como você já ligou muitas vezes (grite para o meu blog!). Existem algumas razões para isso.

1. O problema www que você apontou acima. Irritante, mas não é um disjuntor de negócio.

2. Obriga você a manter registros duplicados para todos servidores voltados ao público que também podem ser acessados internamente, não apenas www . mail.hopelessnoob.com é um exemplo comum. Em um cenário ideal, você teria uma rede de perímetro separada para itens como mail.hopelessnoob.com ou publicwebservice.hopelessnoob.com . Com algumas configurações, como um ASA com interfaces internas e externas , você precisa de NAT dentro de dentro ou DNS de divisão de horizonte mesmo assim , mas para organizações maiores com uma rede de perímetro legítima onde seus recursos voltados para a Web não são t atrás de um limite NAT de grampo de cabelo - isso causa um trabalho desnecessário.

3. Imagine este cenário: você é hopelessnoob.com interna e externamente. Você tem uma corporação com a qual você está se associando chamado example.com e eles fazem a mesma coisa - dividir o horizonte internamente com seu AD e com seu namespace DNS publicamente acessível. Agora, você configura uma VPN site a site e deseja autenticação interna para que a confiança percorra o túnel enquanto tem acesso a seus recursos públicos externos para passar pela Internet. É quase impossível sem roteamento de política incrivelmente complicado ou manter sua própria cópia de sua zona de DNS interna - agora você acabou de criar um conjunto adicional de registros DNS para manter. Então você tem que lidar com hairpinning ao seu lado seu fim, política de roteamento / NAT, e todos os tipos de outros truques. (Eu estava nessa situação com um AD que herdei).

4. Se você já implantou o DirectAccess , ele simplifica drasticamente suas políticas de resolução de nomes - isso provavelmente também é verdade para outras tecnologias VPN de túnel dividido também.

Alguns destes são casos de borda, alguns não são, mas são todos facilmente evitados. Se você tem a capacidade de fazer isso desde o início, também pode fazê-lo da maneira correta para que você não encontre um desses em uma década.

    

Answer 2

Esta declaração: "Realmente, a única justificativa que consigo encontrar é que acessar o site externo interno requer um registro DNS SRV e digitar www. na frente do nome do site em um navegador" não é verdade.

Isso significa que você precisa manter uma cópia de todos os seus registros públicos em seus servidores DNS do AD, o que pode causar problemas, especialmente se você não fizer isso corretamente - perder alguns, etc. Se alguém quiser chegar ao ftp.company.com, mas se esquecer de criar o alias no DNS interno (ou não o tiver feito corretamente), os funcionários internos não conseguirão acessar o site FTP público.

Isso é muito bem detalhado na pergunta à qual você se vinculou: Práticas recomendadas para nomeação do Windows Active Directory

Se a manutenção de várias cópias de suas zonas DNS for um problema fácil para você resolver corretamente, para sempre, suponho que você possa fazer o que quiser. Até que a MS mude algo que a quebre. Você poderia apenas seguir as recomendações deles.

    

Answer 3

Eu não me importo o suficiente com o representante para criar uma resposta longa hoje ... então vou resumir isso.

Eu costumava ficar bem com o split-dns e o implementava várias vezes até que Evan e Mark me convenceram do contrário. Honestamente, NÃO é que não possa ser feito ... pode, e alguns podem estar bem com isso (apesar da sobrecarga e do trabalho feito para isso).

2 coisas específicas surgiram anos atrás para mim que solidificaram NÃO usando:

1. Como você apontou em sua pergunta, você simplesmente não pode permitir que usuários internos acessem seu website externo apenas pelo nome de domínio. Não pergunte por que isso era tão importante, mas tínhamos usuários internos que ficavam nervosos quando digitávamos apenas o nome do domínio em um navegador sem que www não trouxesse o site real, já que o registro de domínio corresponde ao nome do domínio. Domínio do AD e não é um resumo de como chegar a www e NÃO PODE SER internamente.
2. Problemas do Exchange - O AutoDiscover do Exchange pode falhar ao obter os certificados e solicitará um erro. Isso pode acontecer internamente e externamente. Isso ficou ainda mais aparente quando começamos a ter "Caixas de Correio de Floresta Externa" em nossa organização do Exchange e eles não viram o mesmo DNS interno que nós.

Espero que ajude.