Servidor de DNS BIND Ubuntu server

evertonnr
(usa Debian)

Enviado em 05/12/2025 - 08:27h

Olá pessoal, tudo certo?
Estou com algumas dúvidas e gostaria de saber se alguém pode me ajudar.
Estou criando um servidor de DNS Bind em uma máquina com S.O ubuntu server. Aqui na empresa onde trabalho temos várias redes LANs então o DNS precisaria funcionar para todas.
Eu criei uma boa parte, acredito estar próximo da finalização, porém como estou fazendo com o intuíto de ns1 ser o master e o ns2 ser o Slave, encontrei algumas dificuldades. A primeira é que quando o servidor Master transfere a zona
para o Slave, ou ele transfere somente a zona externa e a interna acaba não funcionando no Slave, ou ele transfere somente a zona interna e a Externa acaba não funcionando no Slave.
Por exemplo no named.conf.options quando eu deixo a rede pertencente as minhas máquinas dentro da ACL "internos" ele transfere a zona pro slave mas somente como internos, e se eu tiro dessa ACL e deixo sem colocar em nenhuma outra, ele transfere somente como externo.
Alguém consegue me dizer se eu consigo fazer o slave funcionar exatamente igual ao Master? respondendo tanto interno quanto externo? ou não tem como mesmo? o Slave só vai responder internamente ou externamente ?

danniel-lara
(usa Fedora)

Enviado em 05/12/2025 - 13:25h

é totalmente possível ter um servidor BIND Slave respondendo exatamente igual ao Master, tanto para a zona interna quanto para a externa, desde que você entenda um ponto importante:

O que provavelmente está acontecendo no seu ambiente

Você está usando views no BIND (view "internos" e view "externos").

E aqui está o ponto crítico:

Se o Master usa views, o Slave também deve usar views — com a MESMA estrutura.

O BIND nunca mistura zonas entre views diferentes.
Isso significa:

O Master tem zona interna dentro da view interna

O Slave só vai transferir essa zona para a view equivalente

Se o Slave não tiver a mesma view, ou não estiver autorizado na ACL daquela view → ele recebe só uma das zonas (a que ele “pertence” à ACL).

Por que isso acontece?

O BIND entende “view” como DNS completamente separados, cada view é um servidor DNS independente mas dentro do mesmo processo.

Então:

A view interna tem sua própria zona: zone "empresa.local" { ... }

A view externa tem outra zona: zone "empresa.local" { ... }

Mesmo nome, mas mundos diferentes.

E a transferência da zona depende da ACL e da view.

Resposta direta à sua dúvida
Sim, o Slave pode e deve responder igual ao Master, tanto interno quanto externo.

Mas não existe Slave “global”.
Ele precisa ser Slave por view.

Ou seja:

Você precisa declarar, no Slave:

view "internos" {

    match-clients { internos; };

    recursion yes;



    zone "empresa.local" {

        type slave;

        masters { IP_DO_MASTER; };

        file "db.empresa.local.interna";

    };

};



view "externos" {

    match-clients { any; };

    recursion no;



    zone "empresa.local" {

        type slave;

        masters { IP_DO_MASTER; };

        file "db.empresa.local.externa";

    };

};

 

E no Master as views devem estar configuradas exatamente iguais:

view "internos" {

    match-clients { internos; };

    recursion yes;



    zone "empresa.local" {

        type master;

        file "/etc/bind/db.interna.empresa.local";

        allow-transfer { IP_DO_SLAVE; };

    };

};



view "externos" {

    match-clients { any; };

    recursion no;



    zone "empresa.local" {

        type master;

        file "/etc/bind/db.externa.empresa.local";

        allow-transfer { IP_DO_SLAVE; };

    };

};

 

Erro comum (e provavelmente o seu erro)

Você colocou o Slave na ACL somente da view “internos”, então:

Ele só recebe zona da view interna → responde interno apenas.

Quando tira da ACL:

Ele cai na view externa → recebe só zona externa.

# Como resolver (resumo)

Configure duas views no Slave, iguais ao Master.

Declare a mesma zona em ambas as views (interna e externa).

No Master, permitir transferência ao Slave em ambas as views.

ACLs precisam permitir que o Slave seja visto como cliente das duas views (normalmente com match-clients baseado em IP).

Dica importante

O Slave não faz distinção de “ser interno e externo”.
Quem define isso é o cliente originador, que cai em uma view ou outra dependendo do match-clients.

evertonnr
(usa Debian)

Enviado em 08/12/2025 - 08:44h

Certo. Entendo a situação. Porém acredito não ter cometido esse erro.
Segue as configurações do meu servidor MASTER:

named.conf.local:

view "internal" {
match-clients {clientes-internos; };
recursion yes;
allow-recursion {clientes-internos; };

zone "quepele.com.br" {
type master;
also-notify {IP DO SLAVE; };
allow-transfer {IP DO SLAVE; };
file "/etc/bind/master/quepele.com.br.interno.zone";
};

zone "IP-REVERSO.in-addr.arpa" {
type master;
also-notify {IP DO SLAVE; };
allow-transfer {IP DO SLAVE; };
file "/etc/bind/master/dns.reverso";
};
};

view "external" {
match-clients {any; };
recursion no;

zone "." {
type hint;
file "/usr/share/dns/root.hints";
};

zone "quepele.com.br"{
type master;
also-notify {IP DO SLAVE; };
allow-transfer {IP DO SLAVE; };
file "/etc/bind/master/quepele.com.br.externo.zone";
};

};

named.conf.options:

acl "clientes-internos"{
127.0.0.1;
192.168.4..;
192.168.2..;
192.168.1..;
};

options {
directory "/var/cache/bind";

listen-on port 53 {127.0.0.1; IP DO MASTER; IP EXTERNO DO MASTER; };
allow-query {any; };
recursion no;

forwarders {
8.8.8.8;
8.8.4.4;
};
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

//forwarders {
// 0.0.0.0;
// };

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;

listen-on-v6 { any; };
};



; quepele.com.br.interno.zone


$TTL 3600


; Zona
@ IN SOA ns1.quepele.com.br. admin.quepele.com.br. (
2025120601 ; serial
1D ; refresh
3H ; retry
4W ; expire
1D ) ; minimum TTL

; Servidores DNS

@ IN NS ns1.quepele.com.br.
@ IN NS ns2.quepele.com.br.

teste IN A IP INTERNO DE UMA APLICAÇÃO DE TESTE
ns1 IN A IP DO MASTER
ns2 IN A IP DO SLAVE

evertonnr
(usa Debian)

Enviado em 08/12/2025 - 08:45h

; quepele.com.br.externo.zone


$TTL 3600


; Zona
@ IN SOA ns1.quepele.com.br. admin.quepele.com.br. (
2025120601 ; serial
1D ; refresh
3H ; retry
4W ; expire
1D ) ; minimum TTL

; Servidores DNS

@ IN NS ns1.quepele.com.br.
@ IN NS ns2.quepele.com.br.

teste IN A IP EXTERNO DE UMA APLICAÇÃO DE TESTE
ns1 IN A IP EXTERNO DO MASTER
ns2 IN A IP EXTERNO DO SLAVE

evertonnr
(usa Debian)

Enviado em 08/12/2025 - 08:52h

Vale ressaltar que as configurações do slave estão quase iguais, o que muda de fato são no named.conf.local que referencia o master com o seu respectivo ip.
Quando está dessa maneira que mandei aqui na nossa conversa, ele até transfere as duas zonas, pelo menos aparenta transferir. Porém quando eu executo um rndc dumpdb -zone e tiro a minha rede interna da ACL que pertence ao meu Master e Slave. A zona externa é transferida corretamente. Porém a zona interna vem com os Ips externos também.