Eu tenho um servidor DHCP/DNS (ISC Bind 9.6, DHCP 3.1.1) em funcionamento rodando no Debian ao qual gostaria de adicionar a funcionalidade DynamicDNS. Tenho uma pergunta bastante simples: o DynamicDNS exige (ou recomenda) subdomínios separados? Eu vi alguns tutoriais onde os clientes que estão adquirindo seus endereços IP e outras informações de rede via DHCP estão em um subdomínio diferente dos servidores configurados estaticamente (tanto em termos de IP quanto de DNS). Por exemplo: Todos os clientes estão em ws.example.org e os servidores em example.org.
No momento, todos os nossos servidores e clientes estão no mesmo domínio (example.org), mas espalhados por diferentes arquivos de zona (porque temos várias sub-redes). Os clientes são configurados com DHCP e os servidores são configurados estaticamente. Se eu quiser configurar o DynamicDNS para os clientes, devo usar um subdomínio separado? Qual é a melhor prática aqui (e por que ou por que não seria uma má ideia fazer o contrário)?
Obrigado.
Responder1
Não, não é tecnicamente necessário ter uma zona separada para atualizações dinâmicas.
Acho que o maior fator no uso de subdomínios para DNS dinâmico tem a ver com políticas de segurança para atualização da zona. Na minha opinião, as permissões que você pode definir no bind não são muito flexíveis, embora as versões mais recentes sejam um pouco melhores. Com allow-update(Bind 8.*) as permissões são aplicadas no nível da zona e não por registro. Assim, o cliente A poderia atualizar o registro do seu servidor crítico se ele usasse um endereço IP autorizado para realizar atualizações.
Portanto, ao decidir sobre sua configuração de DNS dinâmico, você deve decidir se acha uma boa ideia permitir que suas estações de trabalho possam alterar os registros de atualização de algum serviço crítico. Ou você deseja separar os serviços críticos em uma zona sem atualizações dinâmicas e outras máquinas em zonas mais dinâmicas?
Responder2
DNS dinâmico nãoprecisarum subdomínio separado, mas essa é a maneira mais fácil (e melhor) de configurá-lo.
Se você restringir as atualizações do DynamicDNS a um subdomínio (ws.example.org) e uma sub-rede (ambas sem servidores), será bastante simples configurar as restrições para que nada de ruim possa acontecer. O pior caso de algo dar errado é uma estação de trabalho ser identificada como outra estação de trabalho.
Se você configurar atualizações do DynamicDNS no mesmo domínio principal onde os servidores residem, deverá ter cuidado ao configurar restrições para que as estações de trabalho não possam se atualizar dinamicamente para serem, digamos, www.example.org. Já faz muito tempo que não olhei para isso, mas você pode acabar precisando de uma ACL separada para cada servidor (ou outro dispositivo para o qual deseja proteger o nome). Problemas semelhantes com sub-redes.