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 para o meu grupo, enquanto o restante é alocado para nossa equipe de TI interna.
Não queremos poder gerenciar o DNS para sua fatia do bolo, mas precisamos ser capazes de gerenciá-lo para nossa fatia.
O problema é que por razões políticas / históricas, que precederam o meu mandato, montamos um servidor DNS baseado em Linux e mantivemos nossos próprios registros e apontamos todos os nossos servidores e equipamentos neste servidor. Enquanto isso, usuários e desenvolvedores de toda a organização são apontados para o servidor DNS das equipes de TI.
Para garantir que tudo funcione em todas as situações, precisamos inserir registros DNS em nosso servidor e, em seguida, colocar ingressos com nossa equipe de TI para que os registros sejam criados no ambiente do Active Directory. Isso veio da paridade e é um pesadelo de gerenciamento.
Além disso, temos centenas de servidores e aplicativos que usam o domain.com compartilhado e precisam criar um subdomain.domain.com e atualizar centenas de servidores e aplicativos não é o preferido.
Como tal, existe uma forma de conceder confiança e permissão para atualizar registros em domain.com para apenas um punhado de / 24s dentro de um / 16? Soluções de terceiros que são lançadas no Active Directory são aceitáveis.
Eu posso estar lendo mal isso, mas parece que uma tarefa agendada para executar uma ou duas vezes por dia funcionaria.
Um exemplo de como acessar a zona e realizar atualizações está aqui:
Esse código é para corrigir registros DNS dinâmicos órfãos, mas deve apontar você na direção correta.
Você certamente já percebeu que o DNS não se importa com as sub-redes quando se trata de gerenciamento. A unidade de gerenciamento típica em uma infraestrutura de DNS é uma "zona" que corresponderia a pelo menos um domínio. Então, se você quisesse delegar tarefas de gerenciamento, você delegaria a administração sobre uma zona completa, pelo menos o domínio completo.
Os servidores DNS do Windows AD oferecem algumas capacidades adicionais de controle de acesso e delegação para entradas de registro único - ou seja, você pode configurar direitos de "modificação" para um determinado usuário ou grupo para cada registro em uma zona sem delegar todo o gerenciamento de zona. Mas nenhum dos recursos de delegação e ACL inclui algo como uma "sub-rede" como uma unidade de gerenciamento; se você precisar refletir isso em ACEs, precisará corrigi-los externamente.
Dito isto, provavelmente não é tão ruim quanto parece, pois as ACLs de 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 para permissões para alterar outros dados específicos da zona ou outros registros. O "criador" se torna o dono do registro e implicitamente obtém o direito de alterar suas permissões, assim indiretamente ganha "controle total". Além disso, a ACE para "CREATOR-OWNER" 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:
Eu não posso falar sobre como o Active Directory seria configurado para permitir que você gerencie e automatize remotamente o domínio usando nsupdate .
O que eu posso dizer é que você pode reduzir um pouco a dor de cabeça usando NS delegações entre si para os registros individuais e nunca definindo% estático A ou CNAME registros para 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 , ns1 e dc1 são registros definidos estaticamente. www e ftp foram delegados a ns1.example.com. , o que, digamos, é um servidor DNS Linux autoritativo. www e ftp acionam a recursão e fazem com que ns1.example.com seja consultado para a resposta. Isso será bem-sucedido, desde que haja um firewall que permita que o tráfego dos DCs atinja ns1 . Isso ainda é uma dor: você não está escapando da necessidade de definir registros no servidor remoto. O que você está realizando é 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 nos dois lados da cerca. Isso funcionará, pelo menos até alguém desejar definir sub.ftp.example.com no DC. Como ftp foi delegado, sub.ftp também foi delegado e não há como gerenciá-lo localmente.