DNS Server · 8 min read · Oct 02, 2025
Servidor DNS dois em um com BIND9
Este tutorial mostra como configurar o servidor DNS BIND9 para atender uma rede interna e uma rede externa ao mesmo tempo com conjuntos diferentes de informações. Para alcançar esse objetivo, um novo recurso do BIND9 chamado view é utilizado. Como um tutorial, ele o guiará por toda a configuração, mas é necessário ter conhecimento inicial de BIND e DNS, existem muitos documentos que cobrem essas informações na Internet.
Continue lendo no site original ou baixe o PDF.
Conteúdos
- 1 O problema
- 2 Configuração inicial
- 3 Internos e externos
- 4 Segurança
- 5 Arquivos de configuração - 5.1 /etc/bind/named.conf.local
- 5.2 /etc/bind/externals/db.example.com
- 5.3 /etc/bind/internals/db.example.com
- Bibliografia
1 O problema
É um problema típico em organizações que estão crescendo que elas têm que resolver dois problemas ao mesmo tempo:
- Ter um servidor DNS para a rede interna da empresa porque há muito tempo já havia computadores demais para lembrar seus IPs 1 e até mesmo computadores demais para manter um conjunto de arquivos de hosts 2.
- Ter um servidor DNS para os servidores externos, para clientes externos, etc.
resolver esses problemas se torna um problema maior quando a organização em crescimento não pode fornecer mais recursos do que um servidor DNS 3. É um problema maior porque se você apenas configurar seu servidor com todos os seus nomes, públicos e privados, você acabará poluindo a Internet com endereços privados, algo que é muito ruim, e também mostrando ao mundo parte da topologia de sua rede interna. Algo que você não quer que um possível atacante/cracker tenha.
A outra parte do problema é que para eficiência você pode querer resolver para IPs internos quando está dentro e IPs externos quando está fora. Aqui estou falando sobre computadores que têm conexões públicas e privadas.
Existem muitas soluções diferentes para esse problema e eu me lembro de ter resolvido isso até com BIND4, mas agora vou usar BIND9 para fazer uma solução que é muito limpa. Isso foi implantado em um servidor Debian GNU/Linux 3.1, mas também deve funcionar para outros sistemas operacionais que executam BIND9, apenas certifique-se de alterar seus caminhos adequadamente.
2 Configuração inicial
Vamos imaginar que a organização para a qual trabalho faz exemplos… de quê? Não sei, mas você pode encomendá-los em example.com. A Examples Corporation foi atribuída à rede 192.0.2.0/24 e internamente estamos usando 10.0.0.0/24.
Vamos começar a servir os nomes e IPs externos, editamos /etc/bind/named.conf.local 4 e adicionamos:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};e então criamos /etc/bind/db.example.com com o seguinte conteúdo:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Temos nosso servidor de e-mail em outro lugar.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Conectamos ao client1 com muita frequência.Como você pode ver, nossa configuração inicial tem um computador para atender a todos, exceto o e-mail, ele até mantém o encaminhamento de IP e um par de bancos de dados.
Agora, uma boa configuração de DNS tem pelo menos um servidor secundário e, de fato, alguns registradores (onde você registra nomes de domínio) impõem isso. Como não temos um segundo computador, vamos para o XName, abrir uma conta e registrar example.com como secundário com 192.0.2.1 como IP para transferência. Agora precisamos permitir que o IP do XName faça a transferência; somos uma pequena organização, mas como queremos ser uma startup de sucesso, tentamos fazer tudo da maneira mais inteligente possível. Então usamos a diretiva de configuração do BIND9 acl para definir um identificador que faz alias para os endereços IP do XName; no início de /etc/bind/named.conf.local adicionamos:
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};e mudamos a declaração da zona para:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { slaves; };
};Poderíamos simplesmente ter digitado os IPs onde digitamos “slaves”.
3 Internos e externos
Agora que temos uma base sólida, podemos começar a pensar em servir conteúdos diferentes para a rede interna e externa, mas primeiro, temos que definir o que é interno e o que é externo.
Em /etc/bind/named.conf.local adicionamos a seguinte definição (no topo ou abaixo da definição de slaves):
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};Se tivéssemos mais redes internas, poderíamos apenas adicioná-las lá. Não definimos externos porque tudo que não é interno é externo. Você pode, se quiser, definir conjuntos de diferentes externos se quiser servir conteúdo diferente para diferentes partes da Internet.
Usaremos um novo recurso do BIND9 chamado views. Uma view permite colocar um pedaço de configuração dentro de uma condição que pode depender de uma série de coisas, neste caso, vamos apenas depender de internals. Substituímos a declaração da zona em /etc/bind/named.conf.local por:
view "internal" {
match-clients { internals; };
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};A diretiva de configuração match clients nos permite mostrar condicionalmente essa view com base em um conjunto de IPs, “any” significa qualquer IP. IPs internos serão armazenados em cache pela view interna e o resto será descartado na view externa. O mundo exterior não pode ver a view interna, e isso inclui o XName, nosso provedor de DNS secundário, mas removemos o allow-transfer da view interna, pois não queremos que ninguém possa transferir sob quaisquer circunstâncias o conteúdo da view interna.
Também mudamos o caminho, teremos que criar o diretório /etc/bind/externals e /etc/bind/internals e mover /etc/bind/db.example.com para /etc/bind/externals/.
Em /etc/bind/internals/db.example.com colocamos um arquivo de zona semelhante ao correspondente externo, mas contendo os IPs internos:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Ótimo, agora podemos pingar o computador do nosso chefe com
ping boss.example.commas tentar acessar mail.example.com nos decepcionará, o que aconteceu? Não há referência a mail.example.com no arquivo de zona interna e, como estamos na rede interna, podemos resolver mail.example.com. Muito bem, vamos apenas copiar o conteúdo do arquivo de zona externa para o arquivo de zona interna. Isso funcionará.
Mas somos uma pequena startup inteligente, podemos fazer melhor do que copiar e colar cada modificação no arquivo de zona, além disso, isso é muito propenso a erros (você sempre se lembrará de modificar o arquivo de zona interna quando modificar o externo, ou você esquecerá e passará alguns dias depurando problemas de rede?).
O que faremos é incluir o arquivo de zona externa no arquivo interno desta forma:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103e voilà! Encontrar a diretiva $include na documentação atual foi difícil… Apenas lembre-se de mudar o serial do arquivo de zona externa sempre que você mudar o interno, mas não é um grande problema, se você esquecer, nada de ruim acontecerá, pois você não deve ter servidores de cache dentro de sua própria pequena rede.
4 Segurança
Não é recomendado usar o mesmo servidor DNS como primário para algum domínio (no nosso caso example.com) e como servidor DNS de cache, mas no nosso caso somos forçados a fazê-lo. Do mundo exterior, 192.0.2.1 é o servidor DNS primário para example.com, da nossa própria rede interna, 192.0.2.1 (ou seu endereço privado, 10.0.0.1) é nosso servidor de nomes de cache que deve ser configurado como o nameserver a ser usado em cada estação de trabalho que temos.
Um dos problemas é que alguém pode começar a usar nosso servidor de nomes de cache do exterior, há um ataque chamado cache-poisoning e muitas outras coisas desagradáveis que podem ser feitas e estão documentadas em SINS (incluindo como evitá-las).
Para melhorar nossa segurança um pouco, adicionaremos algumas diretivas ao arquivo de configuração:
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Isso impedirá que qualquer um na perigosa Internet use nosso servidor recursivamente, enquanto nós, em nossa própria rede, ainda podemos fazê-lo.
5 Arquivos de configuração
5.1 /etc/bind/named.conf.local
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};5.2 /etc/bind/externals/db.example.com
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Temos nosso servidor de e-mail em outro lugar.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Conectamos ao client1 com muita frequência.5.3 /etc/bind/internals/db.example.com
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Bibliografia
SINS
Segurança de um Servidor de Nomes da Internet
Notas de rodapé
… IPs
1
Para mim, dois computadores já qualificam como computadores demais para lembrar seus IPs.
… arquivos
2
O arquivo de hosts reside em /etc/hosts e é um mapeamento simples para o computador local de nomes para IP. Foi a primeira maneira de resolver nomes para IPs e há muito tempo um grande arquivo de hosts centralizado foi mantido, posteriormente distribuído por FTP ou similar. Cresceu rapidamente em um problema que foi resolvido pela invenção do DNS. Tente não deixar seu arquivo de hosts crescer em um problema antes de transformá-lo em DNS, aprenda com os pioneiros!
… servidor
3
Ou quando você é um perfeccionista e acredita que isso deve ser possível com apenas um servidor.
…/etc/bind/named.conf.local
4
Pode ser apenas /etc/bind/named.conf em seu sistema operacional se não for Debian.
Receba novas postagens na sua caixa de entrada
Sem spam. Cancele a assinatura a qualquer momento.