Adicionando entradas DNS estáticas em uma configuração dinâmica do BIND

Question

Eu tenho uma configuração de DNS (BIND9) e DHCP (ISC-DHCP-SERVER) na qual o servidor DHCP atualiza dinamicamente o DNS quando os hosts pegam um endereço IP. No momento, estou fazendo o reenvio de uma parte da minha rede que não está sendo tratada atualmente pelo DHCP e é essencial que os clientes possam acessar os servidores nessa sub-rede. Para evitar a interrupção de clientes, desejo criar entradas estáticas apontando para vários servidores para que os clientes possam acessá-los por meio de seus FQDNs em vez de IPs e assim que eu mudei a sub-rede em que esses servidores estão (e os servidores começam a pegar endereços DHCP) Não é necessário modificar nada, pois os FQDNs apontarão para os novos endereços.

Como o DNS é atualizado dinamicamente para a zona, não é possível criar registros manualmente no arquivo de zona, pois eles serão sobrescritos. O que eu estou querendo saber é como poderia criar entradas estáticas (permanentes até removidas) em uma zona atualizada dinamicamente? Logo antes que a sub-rede seja alterada, essas entradas serão excluídas e, em seguida, adicionadas dinamicamente pelo DHCP com os endereços apropriados.

    

Answer 1

Para responder diretamente à sua pergunta, não há como sinalizar um registro por ser somente leitura em uma zona dinâmica. (que eu estou ciente de pelo menos)

Duas soluções alternativas:

1. Se tiver certeza absoluta de que os clientes DNS não substituirão seus registros criados manualmente, você poderá usar rndc freeze para gravar o arquivo de diário e desativar temporariamente as atualizações. Você pode modificar a zona e reativar as atualizações com rndc thaw . O problema é que você perde todas as alterações dinâmicas do DNS que são disparadas durante o congelamento. Você provavelmente já considerou essa possibilidade e já a descartou.
2. Solução alternativa feia: se você declarar zonas adicionais que são mais específicas que a zona dinâmica (isto é, "zona foo.bar.com" é mais específica que "bar.com"), cada uma terá precedência sobre as menos específicas zona. Uma dor enorme, pois sobrecarrega sua configuração, e cada um dos arquivos de zona precisaria de SOA e NS de registros, além do único registro A .