A engenharia deve ter sua própria zona DNS, delegado ou subdomínio?

15

Temos o domínio primário de nossa organização (com o AD) example.com. No passado, os administradores anteriores criaram várias outras zonas - como dmn.com, lab.example.com, dmn-geo.com, etc. - além de subdomínios e representantes, todos para diferentes grupos de engenharia. Nosso DNS agora está um pouco bagunçado. E, claro, isso causa problemas quando alguém em uma estação de trabalho no example.com precisa se conectar a um sistema em qualquer uma dessas outras zonas / subdomínios, ou vice-versa (parcialmente porque a transferência de zona e a delegação não estão configuradas corretamente para a maioria deles) .

Nosso DNS de produção é integrado ao Active Directory, mas os sistemas de engenharia devem ser isolados do AD.

Estamos discutindo maneiras de reorganizar o DNS e consolidar todas essas entradas diferentes. Eu vejo três caminhos diferentes que podemos tomar:

  • Crie uma nova zona, por exemplo, 'dmn.eng'. Isso pode ser gerenciado pela TI, usando nossos servidores DNS ou engenharia usando seus servidores de nomes.
  • Crie um novo delegado eng.example.com, consolide o DNS de engenharia nesse subdomínio e permita que os engenheiros gerenciem o servidor de nomes para o delegado.
  • Crie um novo subdomínio eng.example.com sem delegação e gerencie DNS para o subdomínio.

Sou a favor de criar um subdomínio de delegado e permitir que os engenheiros tenham controle total sobre sua própria estrutura de DNS nesse subdomínio. A vantagem é que, se o DNS deles não funcionar, provavelmente não é minha culpa;). No entanto, ainda existe alguma ambiguidade sobre a responsabilidade quando algo não funciona e exigirá coordenação com a engenharia para configurar, configurar e administrar.

Se não delegarmos o subdomínio, isso significará muito mais trabalho para a TI de produção que manipula o DNS de não produção (o qual já fazíamos praticamente já). A vantagem é que temos controle total sobre todo o DNS e, quando algo não funciona, não há dúvida sobre a responsabilidade de corrigi-lo. Também podemos adicionar delegados, como geo.eng.example.com, para dar mais flexibilidade e controle à engenharia quando eles precisarem.

Estou realmente incerto sobre a necessidade ou benefícios de criar uma nova zona, dmn.eng.

Quais são as melhores práticas e recomendações do setor para situações como essa? Qual solução seria a mais simples de implementar e fornecer uma resolução de nomes perfeita entre engenharia e produção? Quais são alguns possíveis benefícios ou armadilhas para cada solução que posso estar perdendo?

Para adicionar um pouco mais de informação, somos uma empresa de manufatura bastante grande. Esses engenheiros trabalham em pesquisa e desenvolvimento, desenvolvimento e controle de qualidade. Os laboratórios freqüentemente têm suas próprias sub-redes ou redes inteiras, DHCP, etc. No que diz respeito à organização e à tecnologia, elas são meio que um mundo pequeno.

Queremos manter algum nível de isolamento de rede para laboratórios de engenharia e redes, a fim de proteger nosso ambiente de produção (referência uma pergunta anterior sobre os engenheiros que adicionaram servidores DHCP de engenharia como servidores DHCP AD com autoridade - isso não deve acontecer. No entanto, um usuário em uma estação de trabalho em um laboratório precisará acessar um recurso em nossa rede de produção, ou um usuário em uma estação de trabalho em nossa rede de produção precisará se conectar a um sistema de laboratório, e isso acontece com frequência suficiente para justificar uma classificação -do DNS unificado.

Os representantes já existentes têm servidores DNS gerenciados por engenharia, mas não há comunicação entre os engenheiros nos diferentes laboratórios em que esses servidores estão configurados; portanto, o problema mais comum é a falha na resolução de nomes entre subdomínios. Como os engenheiros possuem esses servidores delegados, não posso corrigir as entradas do NS para que eles falem entre si - daí a vantagem do DNS não delegado de propriedade exclusiva da TI. Mas gerenciar o DNS para engenharia de produção e engenharia é uma dor de cabeça, especialmente porque a engenharia pode fazer alterações no DNS diariamente. Mas, como a BigHomie mencionou em sua resposta, isso provavelmente significa que a engenharia terá que contratar (ou designar) um administrador de DNS real; e essa pessoa e eu teremos que nos tornar razoavelmente bem familiarizados.

Eu não necessariamente gosto da idéia de criar uma nova zona com um nome de domínio ou sufixo arbitrário, mas nós já temos 5 outras zonas com nomes arbitrários, então consolidar em uma única é ainda uma melhoria. Eu sei que existem outras empresas que têm zonas de nível superior separadas para diferentes grupos em sua organização, por isso estou curioso sobre quando isso é apropriado e quais são as vantagens / desvantagens dessa abordagem.

FYI, eu só estive nessa empresa por alguns meses e o administrador AD / DNS anterior deixou a empresa, então não tenho nada para referenciar por que existe alguma estrutura DNS existente.

    
por Thomas 02.04.2014 / 18:24

2 respostas

14

No mundo de hoje, não recomendo a criação de novas zonas com domínios arbitrários de nível superior , pois eles podem se tornar "DNS oficial" a qualquer momento.

Pessoalmente, eu preferiria o cenário de delegação de subdomínio, já que parece adequado ao que você tenta fazer. (Consolide, mas dê controle à engenharia)

Talvez você até encontre um front-end da Web para o MS DNS, onde a engenharia pode adicionar / remover registros, de modo que o próprio servidor ainda seja de propriedade da TI de produção e a única coisa "eles" são as entradas DNS. / p>     

por 02.04.2014 / 18:32
14

Em primeiro lugar, certifique-se de que você possui o domain.tld que você planeja usar (mit.edu). Mesmo que isso nunca se conecte à internet, esse não é o ponto.

Existem enormes benefícios em ter uma hierarquia de DNS que pelo menos algo corresponda à organização. Eu só vi isso feito quando há alguém / pessoas para gerenciar esse departamento em termos de suporte de TI. Isto é no que diz respeito a ter zonas separadas para efeitos de AD. Endereços da Web e etc são um tópico separado e isso não se aplica a isso. Eu não tenho ou conheço regras rígidas e rápidas para a hierarquia DNS, acredito que as necessidades da sua organização irão ditar isso. Algumas zonas podem requerer um subdomínio (eng.mit.edu) e outras não (hr.mit.edu, por exemplo). É claro que deve haver apenas um domínio de nível superior um para consistência.

Dito isto, o que determina se um departamento precisa ou não de um subdomínio? Se isso é para estações de trabalho, eles têm seu próprio suporte de TI ou pessoas capazes de gerenciar tal sistema? Se não, não há realmente nenhum ponto em usar uma zona dns para especificar que uma máquina está em um determinado departamento, existem vários outros métodos que farão o trabalho muito bem. Estas são apenas perguntas que você só precisa fazer a si mesmo.

Eu reavaliaria cada zona e determinava

  1. Se ainda for relevante. Existem servidores ou estações de trabalho apontando para alguma coisa nessa zona?

  2. Quem administrará a nova zona. Escusado será dizer que a zona terá que ser migrada para a sua nova hierarquia, mas você apenas implementa uma informação de endereço de encaminhamento / servidor de nomes para a zona, ou irá gerir ativamente a zona?

Quais sistemas estão 'isolados' do AD? Será que isso não requer autenticação e / ou gerenciamento de rede? Qual é a razão para separá-los da perspectiva do DNS? Para confirmar suas suspeitas, é tudo uma questão de facilidade de gerenciamento. Se a engenharia necessitar de muita administração de dns, eles devem obter um administrador de DNS.

Para adicionar informações com base na sua atualização, eu pessoalmente também daria a elas seu próprio subdomínio, eng.spacelysprockets.com e sub-rede. Deve ser protegido por firewall do resto da rede com o tráfego apropriado permitido. Se eles quiserem sair e criar eng.eng.local ou eng.bikes você não pode pará-los, nem deve ser forçado a apoiar isso *.

Se eles jogarem bem, use a subzona e decida que eles querem dividir lab.eng.spacelysprockets.com e uma parte da sub-rede, que está neles. Provavelmente deveria ser uma cortesia profissional para que você saiba para que você possa segmentar esse tráfego também, mas nem todos pensam assim.

Um nome de domínio real para a sua infraestrutura seriamente uma vantagem no gerenciamento, você deve considerar isso.

* Se você e quiserem você é duas coisas diferentes, mas eu discordo.

    
por 02.04.2014 / 18:49