Você provavelmente não está perseguindo o problema correto, mas não fornece contexto suficiente para realmente ajudá-lo a colocar as coisas em perspectiva.
Você pode proteger a transmissão de arquivos de zona entre diferentes hosts, de várias maneiras. Primeiro, o mestre pode restringir as consultas AXFR / IXFR para que cheguem apenas de seus escravos e os escravos podem restringir as consultas de NOTIFY (os escravos puxam os dados do mestre, portanto, é o iniciador).
Para uma autenticação mais strong, você tem o TSIG. Veja isto para Bind9: ftp://ftp.isc.org /isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch04.html#tsig
Também hoje em dia muitos consteladores de servidores de nomes são configurados a partir de uma única fonte e / ou provisionados out-of-band. Por exemplo, o conteúdo pode estar em um banco de dados, gerado em algum lugar e depois distribuído usando rsync
ou equivalente a todos os servidores de nomes. Não há mensagens DNS entre os servidores de nomes para atualizá-los uns dos outros.
De uma maneira separada, você geralmente tem um mestre "oculto": um servidor de nomes no qual todas as alterações no arquivo de zona aparecem para alimentar todos os servidores de nomes públicos. Não há MITM possível lá já que você nem sabe que existe um mestre oculto e menos ainda onde está e seu IP (exceto se você já era capaz de obter o controle de um dos servidores de nomes, caso em que este é um problema completamente diferente ).
E como eu disse em outro comentário, agora você tem o DNSSEC. Se a sua zona estiver configurada corretamente com o DNSSEC, mesmo que alguém consiga alterar seu conteúdo no servidor de nomes ou em trânsito, qualquer servidor de nomes recursivo de validação detectará a alteração, pois a nova resposta não será assinada ou assinada incorretamente. / p>