DNS com o BIND Parte 1: Fundamentos e Instalação do Servidor DNS com BIND

Posted Feb 5, 2026

By Gean Martins

17 min read

Introdução

Bem-vindo à primeira parte de nossa série completa sobre a configuração de um servidor DNS robusto com BIND (Berkeley Internet Name Domain). O DNS é um dos pilares fundamentais da internet, atuando como um “tradutor” que converte nomes de domínio legíveis por humanos (como www.google.com) em endereços IP numéricos que as máquinas usam para se conectar umas às outras. Sem o DNS, a navegação na web como a conhecemos seria impossível.

Nesta série, vamos explorar em detalhes como instalar, configurar e gerenciar o BIND 9, a implementação de servidor DNS mais utilizada no mundo. Começaremos com os conceitos básicos e a instalação, progredindo gradualmente para configurações avançadas, seguras e eficientes, adequadas tanto para ambientes corporativos quanto para provedores de serviço.

O que será visto nesta primeira parte

Neste primeiro módulo, nosso foco será estabelecer uma base sólida. Abordaremos os seguintes tópicos:

Topologia da Infraestrutura: Desenharemos o ambiente de rede que servirá de base para toda a série.
Lógica de Consultas: Entenderemos como o BIND processará consultas de diferentes origens usando o conceito de views.
Tipos de Servidores DNS: Explicaremos as diferenças entre servidores autoritativos, recursivos e híbridos.
Introdução ao BIND: Conheceremos a história e os componentes do BIND.
Instalação do BIND: Instalaremos os pacotes necessários em um servidor Oracle Linux 9.
Configuração de Cache: Faremos a configuração inicial do BIND para operar como um servidor de cache DNS.

Pré-requisitos

Para acompanhar este tutorial de forma eficaz, é recomendado que você tenha:

Conhecimento Básico de Redes: Familiaridade com conceitos como endereços IP (IPv4 e IPv6), sub-redes e portas TCP/IP.
Familiaridade com Linux: Conforto com a linha de comando para criar diretórios, editar arquivos e gerenciar serviços.
Acesso a um Servidor: Uma máquina física ou virtual com Oracle Linux 9 (ou uma distribuição baseada em RHEL, como CentOS Stream ou Rocky Linux) recém-instalado.
Privilégios de Administrador: Acesso sudo para instalar pacotes e alterar configurações de sistema.

1. Topologia da Infraestrutura DNS

Diagrama da Infraestrutura

┌───────────────────────────────────────────────────────────────┐
│                    INTERNET (Rede Externa)                    │
│                                                               │
│  203.0.113.0/24 (IPv4)  |  2001:db8::/48 (IPv6)               │
└────────────────┬──────────────────────────────────────────────┘
                 │
        ┌────────┴────────┐
        │                 │
    ┌───▼─────┐       ┌───▼──────┐
    │   NS1   │       │   NS2    │
    │ Primário│       │Secundário│
    │ (Master)│       │ (Slave)  │
    └────┬────┘       └────┬─────┘
         │                 │
    203.0.113.2         203.0.113.3
    2001:db8::2         2001:db8::3
         │                 │
         └────────┬────────┘
                  │
        ┌─────────▼──────────┐
        │  Rede Interna      │
        │  10.16.32.0/20     │
        │  fd00:0:0:1::/64   │
        │                    │
        │  Clientes Internos │
        │  (10.0.0.0/8)      │
        └────────────────────┘

Tabela de Endereços

Servidor	Função	IPv4 Interno	IPv6 Interno	IPv4 Externo	IPv6 Externo
NS1	Primário	10.16.32.2	fd00:0:0:1::2	203.0.113.2	2001:db8::2
NS2	Secundário	10.16.32.3	fd00:0:0:1::3	203.0.113.3	2001:db8::3
Domínio Principal	lab4it.com.br	10.16.32.24	fd00:0:0:1::24	203.0.113.24	2001:db8::24

Nota: Os endereços IPv4 externos (203.0.113.0/24) e IPv6 (2001:db8::/48) são blocos de exemplo documentados em RFC 5737 e RFC 3849, respectivamente. Em um ambiente de produção, você usaria endereços reais alocados pela sua organização ou registrador de domínios.

2. Lógica das Consultas DNS

O BIND será configurado para usar views (visualizações), um recurso que permite servir diferentes respostas DNS dependendo da origem da consulta. Isso é uma prática comum em ambientes corporativos.

Fluxo de Consultas

┌──────────────────────────────────────────────────────────────┐
│                    Consulta DNS Recebida                     │
└────────────────────────┬─────────────────────────────────────┘
                         │
                    ┌────▼─────┐
                    │ Verificar│
                    │ Origem   │
                    └────┬─────┘
                         │
         ┌───────────────┼─────────────────┐
         │               │                 │
    ┌────▼────┐     ┌────▼────┐       ┌────▼────┐
    │Interna? │     │Loopback?│       │ Outra?  │
    │10.0.0/8 │     │127.0.0.1│       │         │
    │fd00::/48│     │::1      │       │         │
    └────┬────┘     └────┬────┘       └────┬────┘
         │               │                 │
    ┌────▼───────────────▼───┐    ┌────────▼─────────┐
    │ View "internals"       │    │ View "externals" │
    │ - Zonas internas       │    │ - Zonas públicas | 
    │ - Recursão habilitada  │    │ - Sem recursão   │
    │ - Acesso total         │    └──────────────────┘
    └────────────────────────┘    

Tabela de Views

View	Clientes	Origem	Recursão	Zonas	Propósito
internals	Rede interna	10.0.0.0/8, fd00::/48, localhost	Sim	Internas + Externas	Resolução completa para usuários internos
externals	Internet	Qualquer outra origem	Não	Apenas públicas	Respostas autoritativas para domínios públicos

Nota: Esta é uma implementação possível. Alguns administradores preferem separar DNS recursivos e autoritativos em servidores distintos por questões de segurança e performance. A abordagem com views oferece flexibilidade, mas requer configuração cuidadosa para evitar vulnerabilidades de amplificação de DNS.

Para aprofundar seus conhecimentos sobre DNS e resolução de nomes na Internet, consulte: Servidor de Nomes - DNS: Resolução de Nomes na Internet

3. Introdução aos Tipos de Funcionamento de um DNS

Servidor Autoritativo (Authoritative)

Um servidor DNS autoritativo é aquele que detém os registros oficiais e definitivos para um determinado domínio. Pense nele como a fonte da verdade. Quando alguém pergunta o endereço IP de www.lab4it.com.br, o servidor autoritativo para o domínio lab4it.com.br é o único que pode dar a resposta final e “oficial”.

Responsabilidade: Armazena os arquivos de zona (com os registros A, AAAA, MX, CNAME, etc.) de um ou mais domínios.
Comportamento: Responde apenas a consultas sobre os domínios para os quais tem autoridade. Ele não tenta resolver nomes de outros domínios para seus clientes.

Servidor Recursivo (Recursive / Caching)

Um servidor DNS recursivo, também conhecido como resolver ou servidor de cache, é o intermediário que faz o trabalho pesado para os clientes (como seu computador ou smartphone). Quando um cliente precisa resolver um nome, ele envia a consulta a um servidor recursivo.

Responsabilidade: Encontrar a resposta para a consulta de um cliente, mesmo que não a saiba.
Comportamento: Se não tiver a resposta em seu cache, ele executa um processo de consulta iterativa: pergunta aos servidores raiz da internet, depois aos servidores do TLD (.br, .com), e assim por diante, até encontrar o servidor autoritativo que tem a resposta. Após obtê-la, ele a entrega ao cliente e a armazena em cache por um tempo para acelerar futuras solicitações para o mesmo nome.

Servidor Híbrido (Split-View DNS)

Um servidor híbrido combina as funções de autoritativo e recursivo em uma única instância do BIND, mas de forma inteligente e segregada. Utilizando um recurso chamado views (visualizações), o servidor pode fornecer respostas diferentes para a mesma pergunta, dependendo de quem está perguntando (por exemplo, um cliente da rede interna ou um usuário da internet).

Responsabilidade: Servir como autoritativo para domínios públicos e internos, ao mesmo tempo que atua como um servidor recursivo para os clientes da rede local.
Comportamento: É exatamente o modelo que implementaremos nesta série. Para consultas da rede interna, ele permitirá recursão e mostrará registros internos. Para consultas da internet, ele desativará a recursão e mostrará apenas os registros públicos, protegendo a infraestrutura interna.

4. Introdução ao BIND

O que é BIND?

BIND (Berkeley Internet Name Domain) é o software de servidor DNS mais antigo e amplamente utilizado na internet. Criado no início dos anos 1980 na Universidade da Califórnia, Berkeley, com financiamento da DARPA, o BIND tornou-se a implementação de referência para o protocolo DNS.

Sua longevidade e adoção massiva se devem à sua robustez, flexibilidade e conformidade com os padrões da internet (RFCs). Hoje, ele é mantido pelo Internet Systems Consortium (ISC) e continua a evoluir, incorporando novas funcionalidades e aprimoramentos de segurança.

Componentes Principais do BIND

O BIND é, na verdade, um conjunto de ferramentas. Os componentes que mais utilizaremos são:

named: O daemon (serviço) do servidor de nomes propriamente dito. É o processo que roda em segundo plano, escutando por consultas DNS na porta 53 e respondendo a elas com base em sua configuração.
rndc (Remote Name Daemon Control): A ferramenta de controle do named. Ela permite que administradores gerenciem o serviço DNS sem precisar reiniciá-lo, executando ações como recarregar zonas, limpar o cache ou verificar o status.
Ferramentas de Diagnóstico: Utilitários como dig (Domain Information Groper) e nslookup, que são instalados com o pacote bind-utils. Eles são essenciais para testar e solucionar problemas de DNS.

5. Outros Servidores DNS

Embora o BIND seja o padrão de fato, é importante saber que existem outras implementações de servidores DNS populares, cada uma com suas próprias filosofias e pontos fortes. Algumas alternativas notáveis incluem:

Servidor	Desenvolvedor	Foco Principal
PowerDNS	PowerDNS.COM	Foco em performance e backends de banco de dados. Oferece um servidor autoritativo e um recursor separados.
Knot DNS	CZ.NIC	Um servidor autoritativo de alta performance, projetado para ser rápido e moderno.
Unbound	NLnet Labs	Um servidor DNS exclusivamente recursivo, com forte foco em segurança, validação e performance.
dnsmasq	Simon Kelley	Um servidor DNS leve, ideal para redes pequenas e dispositivos embarcados, que geralmente combina DNS com serviços DHCP.

Nesta série, focaremos no BIND por ser a solução mais tradicional, flexível e rica em funcionalidades, tornando-o uma base de conhecimento indispensável para qualquer administrador de sistemas.

6. Instalação do Pacote BIND

6.1 Preparação do Sistema

Nota: Para esta implementação usaremos a distribuiçao Oracle Linux versão 9.

Antes de instalar o BIND, configure o servidor para usar um nameserver externo confiável:

  
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf 

Nota: Este comando configura temporariamente o Google DNS (8.8.8.8) como servidor de nomes, permitindo que o sistema resolva nomes durante a instalação do BIND e assumindo que a VM ainda não possua um servidor de DNS definido.

6.2 Instalação dos Pacotes

Instale o BIND e suas ferramentas de utilidade:

sudo dnf install bind bind-utils

Pacotes instalados:

bind - O servidor DNS BIND propriamente dito
bind-utils - Ferramentas de utilidade para consultas e diagnóstico

6.3 Verificação da Instalação

Verifique que os pacotes foram instalados corretamente:

  
[gean@ns1 ~]$ rpm -qil bind
Name        : bind
Epoch       : 32
Version     : 9.16.23
Release     : 34.0.1.el9_7.1
Architecture: x86_64
Install Date: Fri 06 Feb 2026 11:02:03 AM -03
Group       : Unspecified
Size        : 1506464
License     : MPLv2.0
Signature   : RSA/SHA256, Mon 17 Nov 2025 10:24:42 PM -03, Key ID bc4d06a08d8b756f
Source RPM  : bind-9.16.23-34.0.1.el9_7.1.src.rpm
Build Date  : Mon 17 Nov 2025 10:19:02 PM -03
Build Host  : build-ol9-x86_64.oracle.com
Vendor      : Oracle America
URL         : https://www.isc.org/downloads/bind/
Summary     : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server
Description :
BIND (Berkeley Internet Name Domain) is an implementation of the DNS
(Domain Name System) protocols. BIND includes a DNS server (named),
which resolves host names to IP addresses; a resolver library
(routines for applications to use when interfacing with DNS); and
tools for verifying that the DNS server is operating properly.
[...]

  
[gean@ns1 ~]$ rpm -qil bind-utils
Name        : bind-utils
Epoch       : 32
Version     : 9.16.23
Release     : 34.0.1.el9_7.1
Architecture: x86_64
Install Date: Fri 06 Feb 2026 11:01:59 AM -03
Group       : Unspecified
Size        : 657438
License     : MPLv2.0
Signature   : RSA/SHA256, Mon 17 Nov 2025 10:24:44 PM -03, Key ID bc4d06a08d8b756f
Source RPM  : bind-9.16.23-34.0.1.el9_7.1.src.rpm
Build Date  : Mon 17 Nov 2025 10:19:02 PM -03
Build Host  : build-ol9-x86_64.oracle.com
Vendor      : Oracle America
URL         : https://www.isc.org/downloads/bind/
Summary     : Utilities for querying DNS name servers
Description :
Bind-utils contains a collection of utilities for querying DNS (Domain
Name System) name servers to find out information about Internet
hosts. These tools will provide you with the IP addresses for given
host names, as well as other information about registered domains and
network addresses.

6.4 Ativação do Serviço

Ative o serviço BIND para iniciar automaticamente no boot:

  
sudo systemctl enable --now named

Verifique o status:

  
[gean@ns1 ~]$ sudo systemctl status named
● named.service - Berkeley Internet Name Domain (DNS)
     Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; preset: disabled)
     Active: active (running) since Fri 2026-02-06 11:12:37 -03; 11min ago
    Process: 1493 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is>
    Process: 1495 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 1496 (named)
      Tasks: 10 (limit: 9010)
     Memory: 23.9M (peak: 26.2M)
        CPU: 147ms
     CGroup: /system.slice/named.service
             └─1496 /usr/sbin/named -u named -c /etc/named.conf

Feb 06 11:12:37 ns1 named[1496]: zone localhost.localdomain/IN: loaded serial 0
Feb 06 11:12:37 ns1 named[1496]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Feb 06 11:12:37 ns1 named[1496]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Feb 06 11:12:37 ns1 named[1496]: zone localhost/IN: loaded serial 0
Feb 06 11:12:37 ns1 named[1496]: all zones loaded
Feb 06 11:12:37 ns1 named[1496]: running
Feb 06 11:12:37 ns1 systemd[1]: Started Berkeley Internet Name Domain (DNS).
Feb 06 11:12:37 ns1 named[1496]: managed-keys-zone: Initializing automatic trust anchor management for zone "."; DNSKEY ID 20326 is now trusted, waiving the normal 30-day w>
Feb 06 11:12:37 ns1 named[1496]: managed-keys-zone: Initializing automatic trust anchor management for zone "."; DNSKEY ID 38696 is now trusted, waiving the normal 30-day w>
Feb 06 11:12:38 ns1 named[1496]: resolver priming query complete

6.5 Verificação de Portas

Confirme que o BIND está escutando na porta 53:

  
[gean@ns1 ~]$ ss -nltpu | grep 53 
udp   UNCONN 0      0          127.0.0.1:53        0.0.0.0:*          
udp   UNCONN 0      0          127.0.0.1:53        0.0.0.0:*          
udp   UNCONN 0      0              [::1]:53           [::]:*          
udp   UNCONN 0      0              [::1]:53           [::]:*          
tcp   LISTEN 0      4096       127.0.0.1:953       0.0.0.0:*          
tcp   LISTEN 0      10         127.0.0.1:53        0.0.0.0:*          
tcp   LISTEN 0      10         127.0.0.1:53        0.0.0.0:*          
tcp   LISTEN 0      10             [::1]:53           [::]:*          
tcp   LISTEN 0      10             [::1]:53           [::]:*          
tcp   LISTEN 0      4096           [::1]:953          [::]:*     

7. BIND como Servidor Cache

Agora que o BIND está instalado, configure-o para funcionar como servidor cache. Primeiro, configure o /etc/resolv.conf para usar o próprio servidor:

  
[gean@ns1 ~]$ echo -e "nameserver 127.0.0.1\nnameserver ::1" | sudo tee /etc/resolv.conf 
nameserver 127.0.0.1
nameserver ::1

sudo chattr +i /etc/resolv.conf

Nosso servidor recém-instalado já está operando como servidor cache. Para demonstrar o efeito do cache, faça uma consulta DNS e observe o Query time. Em seguida, repita a mesma consulta e note a diferença:

Nota: O servidor de cache nesse momento já está funcionando, apenas para o próprio servidor, respondendo na loopback

Primeira Consulta (sem cache):

  
[gean@ns1 ~]$ dig @localhost -t soa kernel.org | tail -n6

;; Query time: 2217 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Feb 06 11:26:35 -03 2026
;; MSG SIZE  rcvd: 126

Segunda Consulta (com cache):

  
[gean@ns1 ~]$ dig @localhost -t soa kernel.org | tail -n6

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Feb 06 11:26:39 -03 2026
;; MSG SIZE  rcvd: 126

8. Conhecendo o Arquivo de Configuração Principal: `/etc/named.conf`

O arquivo /etc/named.conf é o coração da configuração do BIND. Ele define as opções globais do servidor, as zonas que ele gerencia e outras configurações importantes. Vamos analisar as principais seções deste arquivo:

  
[gean@ns1 ~]$ sudo cat /etc/named.conf 
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
	listen-on port 53 { 127.0.0.1; };
	listen-on-v6 port 53 { ::1; };
	directory 	"/var/named";
	dump-file 	"/var/named/data/cache_dump.db";
	statistics-file "/var/named/data/named_stats.txt";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	secroots-file	"/var/named/data/named.secroots";
	recursing-file	"/var/named/data/named.recursing";
	allow-query     { localhost; };

	/* 
	 - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
	 - If you are building a RECURSIVE (caching) DNS server, you need to enable 
	   recursion. 
	 - If your recursive DNS server has a public IP address, you MUST enable access 
	   control to limit queries to your legitimate users. Failing to do so will
	   cause your server to become part of large scale DNS amplification 
	   attacks. Implementing BCP38 within your network would greatly
	   reduce such attack surface 
	*/
	recursion yes;

	dnssec-validation yes;

	managed-keys-directory "/var/named/dynamic";
	geoip-directory "/usr/share/GeoIP";

	pid-file "/run/named/named.pid";
	session-keyfile "/run/named/session.key";

	/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
	include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
	type hint;
	file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

8.1 Seção `options`

Esta é a seção de configuração global. As diretivas definidas aqui se aplicam a todo o servidor, a menos que sejam sobrescritas em uma seção mais específica (como uma view ou zone).

listen-on / listen-on-v6: Especifica em quais endereços IP e portas o BIND deve escutar por consultas. No exemplo, ele está configurado para escutar apenas na interface de loopback (127.0.0.1 e ::1), o que é o padrão para um servidor de cache local.
directory: Define o diretório de trabalho do named. Todos os caminhos relativos nos arquivos de configuração serão baseados neste diretório.
allow-query: Controla quem tem permissão para fazer consultas ao servidor. localhost; permite apenas consultas originadas do próprio servidor.
recursion yes;: Habilita a funcionalidade de servidor recursivo. É essencial para um servidor de cache, mas deve ser desabilitado em um servidor puramente autoritativo exposto à internet.

8.2 Seção `logging`

Esta seção controla como o BIND registra suas atividades (logs). A configuração padrão cria um canal (channel) chamado default_debug que envia todas as mensagens de log de severidade dinâmica para o arquivo data/named.run (relativo ao diretório de trabalho).

Nas próximas partes, veremos como criar uma configuração de logging muito mais granular e útil, separando diferentes categorias de eventos (consultas, segurança, erros) em arquivos distintos.

8.3 Seção `zone`

Cada bloco zone define uma zona DNS que o servidor gerencia. A configuração padrão inclui a zona raiz (.), que é do tipo hint. Isso significa que o BIND usará o arquivo named.ca para saber quais são os servidores raiz da internet, o ponto de partida para qualquer consulta recursiva.

8.4 Seção `include`

A diretiva include permite dividir a configuração em múltiplos arquivos, o que é uma prática essencial para manter a organização. O arquivo padrão inclui /etc/named.rfc1912.zones, que contém definições de zonas para redes privadas (RFC 1912), e /etc/named.root.key, que contém as chaves de confiança para a validação DNSSEC da zona raiz.

Conclusão

Nesta primeira parte, construímos a fundação para nossa jornada com o BIND. Definimos nossa arquitetura, entendemos os diferentes papéis que um servidor DNS pode desempenhar e instalamos com sucesso o BIND 9. Além disso, o configuramos para funcionar como um servidor de cache local e verificamos sua operação.

Com essa base estabelecida, estamos prontos para avançar para a próxima fase: estruturar e organizar as configurações de forma profissional para suportar nosso ambiente de split-view.

Próximos Passos

Agora que o BIND está instalado e funcionando como um servidor de cache, o próximo passo é organizar nossa estrutura de arquivos e criar a configuração avançada que separará as consultas internas das externas.

Clique aqui para ir para DNS com o BIND Parte 2: Estrutura e Configuração do BIND

Referências

DNS, BIND

This post is licensed under CC BY 4.0 by the author.