DNS do Windows: existe uma maneira de particionar um domínio com base em sub-redes

Question

Em nossa organização, temos dois grupos separados que compartilham espaço de endereço de rede e um domínio. Algumas fatias de /24 são alocadas ao meu grupo, enquanto o restante é alocado à nossa equipe interna de TI.

Não queremos ser capazes de gerenciar o DNS para a sua fatia do bolo, mas precisamos ser capazes de gerenciá-lo para a nossa fatia.

O problema é que por razões políticas/históricas, que precederam a minha gestão, configuramos um servidor DNS baseado em Linux e mantivemos nossos próprios registros e apontamos todos os nossos servidores e equipamentos para este servidor. Enquanto isso, usuários e desenvolvedores de toda a organização são direcionados ao servidor DNS das equipes de TI.

Para garantir que tudo funcione em todas as situações, temos que inserir os registros DNS em nosso servidor e depois colocar tickets com nossa equipe de TI para que os registros sejam criados no ambiente Active Directory. Isto saiu da paridade e é um pesadelo de gestão.

Além disso, temos centenas de servidores e aplicativos que usam o compartilhamento domain.come não é preferível criar subdomain.domain.come atualizar centenas de servidores e aplicativos.

Dessa forma, existe uma maneira de conceder confiança e permissão para atualizar registros em domain.comapenas alguns /24s dentro de um /16? Soluções de terceiros integradas ao Active Directory são aceitáveis.

Answer 1

Posso estar interpretando mal isso, mas parece que uma tarefa agendada para ser executada uma ou duas vezes por dia funcionaria.

• Leia nos registros DNS
• Se o endereço IP do registro corresponder aos critérios
• examine a ACL de segurança para a ACE de um grupo de segurança que gerencia o endereço
• Adicione a ACE se ela não existir.

Um exemplo de código de como acessar a zona e realizar atualizações está aqui:

http://www.adamtheautomator.com/fix-dynamic-dns-record-permissions-automagically/

Esse código serve para corrigir registros DNS dinâmicos órfãos, mas deve apontar a direção certa.

Answer 2

Você certamente já percebeu que o DNS não se preocupa com as sub-redes quando se trata de gerenciamento. A unidade de gestão típica numa infra-estrutura DNS é uma “zona” que corresponderia a pelo menos um domínio. Portanto, se você quisesse delegar tarefas de gerenciamento, delegaria a administração em uma zona completa, ou seja, pelo menos no domínio completo.

Os servidores DNS do Windows AD oferecem alguns recursos adicionais de controle de acesso e delegação para entradas de registro único - ou seja, você seria capaz de configurar direitos de "modificação" para um determinado usuário ou grupo para cada registro dentro de uma zona sem delegar todo o gerenciamento da zona. Mas nenhum dos recursos de delegação e ACL inclui algo como uma "sub-rede" como unidade de gerenciamento; se você precisar refletir isso nas ACEs, precisará corrigi-las externamente.

Dito isto, provavelmente não é tão ruim quanto parece, já que as ACLs DNS do Windows também têm o conceito de "criador" de um registro, juntamente com a capacidade de delegar apenas a criação de novos registros em uma zona, sem a necessidade de permissões para alterar outros dados específicos da zona ou outros registros. O "criador" torna-se o proprietário do registro e obtém implicitamente o direito de alterar suas permissões, ganhando assim indiretamente "controle total". Além disso, a ACE para "CREATOR-OWNER" a ser herdada na criação de um novo registro pode ser definida explicitamente no contêiner, se desejado (mas o direito implícito de alterar permissões não pode ser revogado). Portanto, o esboço básico do projeto pode ser assim:

• peça à equipe AD DNS direitos de criação para novos registros na zona do seu grupo
• peça à equipe do AD DNS para delegar os direitos de modificação dos registros de recursos pertencentes ao seu grupo
• comece a criar e modificar registros de recursos para seu grupo no AD DNS por conta própria
• propor a criação de um script de gerenciamento executado com frequência que verifique se os registros criados pelo seu grupo estão em conformidade com a política de delegação (ou seja, apontam para hosts em seus domínios)
• reconfigure seu servidor DNS Linux para simplesmente encaminhar consultas aos servidores AD DNS ou para atuar como secundário, extraindo os dados da zona de um dos AD DNS primários (se a zona DNS for integrada ao AD, todos os servidores AD DNS irão atuar como primários)

Answer 3

Não posso falar sobre como o Active Directory seria configurado para permitir que você gerencie e automatize remotamente o domínio usando o nsupdate.

O que eupodeO que lhe digo é que você pode reduzir um pouco a dor de cabeça usando NSdelegações entre si para os registros individuais e nunca definindo registros estáticos Aou CNAMEpara dados que sua equipe não gerencia.

Imagine que você tenha o seguinte no Active Directory:

example.com. SOA dc1.example.com. hostmaster.example.com. 2015022400 28800 7200 604800 300
     IN NS dc1.example.com.
     IN NS dc2.example.com.
     IN MX 10 mail.example.com.
www  IN NS ns1
ftp  IN NS ns1
mail IN  A 198.18.0.10

dc1  IN  A 198.18.0.150
ns1  IN  A 198.18.0.250

• mail, ns1e dc1são registros definidos estaticamente.
• wwwe ftpforam delegados a ns1.example.com., que diremos ser um servidor DNS Linux autoritativo.
• Como o controlador de domínio normalmente atua em uma função de servidor DNS mista (recursiva e autoritativa), as solicitações wwwe ftpacionarão a recursão e farão com que ns1.example.comseja consultado para obter a resposta. Isso será bem-sucedido, desde que haja um firewall que permita que o tráfego dos DCs atinja ns1.

Isso ainda é um problema: você não está escapando da necessidade de definir registros no servidor remoto. O que vocêsãorealizar é a propriedade de registros individuais. Se o endereço IP de um desses registros precisar ser alterado, essa alteração não precisará ser feita em ambos os lados da cerca. Isso funcionará, pelo menos até que alguém queira definir sub.ftp.example.como DC. Desde que ftpfoi delegado, sub.ftptambém foi delegado e não há como gerenciá-lo localmente.