207.1 Domain Name Server

Conceitos sobre DNS

O DNS (Domain Name System, ou sistema de nomes de domínios) é responsável pela tradução de Nome para IP e IP para nome. Criado e mantido pela ISC (Internet System Consortium), mesmo grupo que mantém o DHCP e NTP.

Nos anos de 1970, a ARPAnet era uma rede pequena e a administração de nomes (hostnames) para IP, era feita através de um arquivo chamado hosts. O arquivo era mantido pela SRIs - NIC (Stanford Research Institute - Network Information Center), as atualizações eram enviadas periodicamente a ARPAnet via FTP e gravadas no arquivo arquivo hosts, isso era feito uma ou duas vezes por semana manualmente.

O Domain Name System é basicamente um banco de dados de informações distribuído que armazena dados sobre Hosts e Domínios que serão consultados pela Internet.

The Domain Namespace

O Namespace (como é chamado alternativamente) identifica a estrutura dos domínios que se combinam para formar um nome de domínio completo, ou seja, é uma estrutura que tem partes combinadas para formar o nome de domínio completo.

Sua estrutura é parecida com uma árvore invertida, com o nó raiz no topo (onde temos os Root Servers) representado por um. (ponto). Cada nó da árvore possui um rótulo que o identifica, a imagem abaixo representa essa estrutura mencionada.

Tomemos como exemplo o nome de domínio sub.secondary.com, o .com é o domínio de nível superior (TLD), secondary identifica o nome de domínio secundário (geralmente um site hospedado por uma organização e/ou empresa) e sub identifica um subdomínio.

Toda essa estrutura de domínio DNS é chamada de namespace. O nome atribuído a um domínio ou computador está relacionado à sua posição no namespace.

Abaixo vou deixar uma imagem do site dispersednet mostrando o estrutura da árvore de DNS e nomeando cada conjunto dela:

dns-namespace

Domain Namespace Zones

As zonas do Domain Namespace são divisões administrativas dentro da estrutura hierárquica do DNS. O Domain Namespace representa toda a árvore de nomes do DNS, iniciando na raiz (.) e se ramificando em níveis como TLDs, domínios e subdomínios. Para facilitar o gerenciamento dessa estrutura, ela é dividida em zonas.

Cada zona é responsável por uma parte específica do namespace e é administrada por servidores de nomes autoritativos. A zona mais importante é a zona raiz (.), que fica no topo da hierarquia. Ela é responsável por apontar para os servidores dos domínios de topo (TLDs), como .com, .org e .br.

Essa zona raiz é gerenciada pelos Root Servers, que são 13 servidores nomeados (de A até M). Apesar de existirem apenas 13 identificadores, esses servidores são distribuídos globalmente em centenas de instâncias físicas, utilizando anycast para garantir alta disponibilidade e baixa latência.

A tabela abaixo foi retirada do site da iana.org:

Hostname	IP Addresses	Operator
a.root-servers.net	198.41.0.4, 2001:503:ba3e::2:30	Verisign, Inc.
b.root-servers.net	199.9.14.201, 2001:500:200::b	University of Southern California, Information Sciences Institute
c.root-servers.net	192.33.4.12, 2001:500:2::c	Cogent Communications
d.root-servers.net	199.7.91.13, 2001:500:2d::d	University of Maryland
e.root-servers.net	192.203.230.10, 2001:500:a8::e	NASA (Ames Research Center)
f.root-servers.net	192.5.5.241, 2001:500:2f::f	Internet Systems Consortium, Inc.
g.root-servers.net	192.112.36.4, 2001:500:12::d0d	US Department of Defense (NIC)
h.root-servers.net	198.97.190.53, 2001:500:1::53	US Army (Research Lab)
i.root-servers.net	192.36.148.17, 2001:7fe::53	Netnod
j.root-servers.net	192.58.128.30, 2001:503:c27::2:30	Verisign, Inc.
k.root-servers.net	193.0.14.129, 2001:7fd::1	RIPE NCC
l.root-servers.net	199.7.83.42, 2001:500:9f::42	ICANN
m.root-servers.net	202.12.27.33, 2001:dc3::35	WIDE Project

Name Servers (NS)

Um Name Server é um serviço responsável por responder consultas DNS, informando dados como o endereço IP associado a um nome de domínio. Esses servidores podem executar diferentes funções dentro da infraestrutura DNS, dependendo de como são configurados.

Tipo	Descrição
Primary (Master)	Servidor autoritativo principal de uma zona. Mantém os dados originais e permite alterações diretas.
Secondary (Slave)	Servidor autoritativo secundário. Obtém os dados do Primary por meio de transferência de zona (AXFR/IXFR).
Caching (Recursive Resolver)	Realiza consultas em outros servidores DNS e armazena as respostas em cache por um período (TTL). Não possui autoridade sobre zonas.
Forwarder	Encaminha consultas DNS para outro servidor (geralmente um resolver recursivo), em vez de resolvê-las diretamente.

DNS Resolver

O DNS Resolver é um componente responsável por realizar consultas DNS para resolver nomes de domínio em endereços IP. Ele pode existir em dois contextos:

No cliente (stub resolver)
É uma biblioteca ou serviço do sistema operacional que recebe a solicitação de aplicações (como navegadores) e encaminha a consulta para um servidor DNS.
No servidor (resolver recursivo)
É o serviço que realiza a resolução completa, consultando outros servidores DNS (Root, TLD e autoritativos) até obter a resposta final.

Normalmente, o resolver mantém um cache das consultas realizadas, respeitando o tempo definido pelo TTL (Time To Live), reduzindo a necessidade de novas consultas.

Tomando um navegador Web como exemplo, a resolução para acesso a um "website" tem as seguintes etapas, assumindo que não temos em nenhum momento o endereço em cache.

consulta_dns.drawio

Vou explicar cada um dos passos acima:

1° Passo
O computador ao precisar acessar um site primeiro verifica se ele conhece o endereço do site localmente, seja via Cache ou no arquivo /etc/hosts.
2° Passo
Sabendo que não conhece, ele pergunta para o DNS recursivo configurado no computador.

3° e 4° Passo

Nesse exemplo, o servidor DNS recursivo também não possui a resposta em cache. Dessa forma, ele inicia o processo de resolução consultando diretamente um dos Root Servers.

; <<>> DiG 9.16.1-Ubuntu <<>> +trace www.google.com.br
;; global options: +cmd
.           5550    IN  NS  m.root-servers.net.
.           5550    IN  NS  l.root-servers.net.
.           5550    IN  NS  k.root-servers.net.
.           5550    IN  NS  j.root-servers.net.
.           5550    IN  NS  i.root-servers.net.
.           5550    IN  NS  h.root-servers.net.
.           5550    IN  NS  g.root-servers.net.
.           5550    IN  NS  f.root-servers.net.
.           5550    IN  NS  e.root-servers.net.
.           5550    IN  NS  d.root-servers.net.
.           5550    IN  NS  c.root-servers.net.
.           5550    IN  NS  b.root-servers.net.
.           5550    IN  NS  a.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

O Root Server não conhece o endereço completo (www.google.com.br), mas analisa o nome e responde informando quais são os servidores responsáveis pelo domínio de topo .br. Podemos ver essa consulta abaixo:

br.         172800  IN  NS  a.dns.br.
br.         172800  IN  NS  b.dns.br.
br.         172800  IN  NS  c.dns.br.
br.         172800  IN  NS  d.dns.br.
br.         172800  IN  NS  e.dns.br.
br.         172800  IN  NS  f.dns.br.
br.         86400   IN  DS  2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4
br.         86400   IN  RRSIG   DS 8 1 86400 20221211170000 20221128160000 18733 . EyzBc7dxVdgBi7SO30Fauf/buOPTxSzlFZMLH57IS/uioW9j/6dY8/+s u9DrO4v+zECdZ5dzXAhTVVKHsGIMN5agzAUHeOmxA1OGuafuhAxFgDMA cyThBB9xmD4YdT2r6lUxtbh2vFIqHk/rPzxOH9wAc8qy354ZYRwxdpue aJni+VQQHzED8YLdRhpi5J231hgM9CMTlTCITKgDclJqjeRzIGxhZme9 YV5qaPFiirba1JuCL2LcijzIi1kEsh9d8oIi1q1P1D9iwXlw55wrOY4s 1SRwRTTTzPxk1u5D2/0LIliFOqDZI4cqKCRJKbdThFriE2yqYxCMv5KR D1R/tQ==
;; Received 745 bytes from 192.5.5.241#53(f.root-servers.net) in 4 ms

5° e 6° Passo
Sabendo que temos que consultar os DNS do .br, o servidor recursivo consulta os servidores autoritativos do domínio .br perguntando quem é a zona google.com.br. Nesse ponto, se esses servidores DNS fossem os autoritativos, já poderíamos perguntar quem é o host www dentro da zona google.com.br, mas como vamos ver abaixo os servidores nos respondem dizendo que os servidores autoritativos por essa são outros servidores:
```
google.com.br.      3600    IN  NS  ns4.google.com.
google.com.br.      3600    IN  NS  ns1.google.com.
google.com.br.      3600    IN  NS  ns2.google.com.
google.com.br.      3600    IN  NS  ns3.google.com.
```
7° e 8° Passo
Agora o servidor recursivo consulta um dos servidores autoritativos de google.com.br e perguntamos a ele o endereço do host www ao qual pertence a zona dele, naturalmente, como ele conhece, ele nos informa o endereço como podemos ver abaixo:
```
www.google.com.br.  300 IN  A   142.250.218.163
;; Received 62 bytes from 216.239.36.10#53(ns3.google.com) in 124 ms
```
9° Passo
Com isso o servidor recursivo nos retorna o endereço do destino e o guarda em cache para consultas futuras (mas uma hora esse cache vai expirar).
10° Passo
Com o endereço em "mãos" o navegador pode acessar o site.

Delegação de subdomínios

Um dos principais objetivos do Sistema de Nomes de Domínio (DNS) é permitir a descentralização da administração dos domínios. Para isso, existe o mecanismo de delegação. A delegação permite que a responsabilidade sobre uma parte do domínio seja transferida para outra entidade, que passa a administrar essa nova zona de forma independente.

Um domínio pode conter diversos subdomínios, e nem todos precisam estar sob a mesma administração. Isso significa que um domínio pode ser dividido em várias zonas, cada uma com seus próprios servidores autoritativos.

Tomando como exemplo os domínios do Governo Brasileiro, o domínio gov.br possui o subdomínio sp.gov.br. Esse subdomínio, por sua vez, pode ser dividido em outros subdomínios, como: prefeitura.sp.gov.br, saopaulo.sp.gov.br, educacao.sp.gov.br entre outros. Cada um desses pode ser administrado por entidades diferentes, caso haja delegação.

Para delegar a autoridade de um subdomínio, basta configurar registros NS na zona pai apontando para os servidores responsáveis pela nova zona. Supondo que somos responsáveis pela zona sp.gov.br e queremos delegar o subdomínio vagas.sp.gov.br, podemos fazer:

# Delegando autoridade sobre o subdomínio 'vagas.sp.gov.br':
vagas.sp.gov.br IN  NS ns1.vagas.sp.gov.br
ns1.vagas.sp.gov.br IN  A 172.16.1.8

Como o servidor ns1.vagas.sp.gov.br está dentro do próprio subdomínio delegado (vagas.sp.gov.br), é necessário informar o endereço IP dele na zona pai. Caso contrário, não seria possível resolver o nome desse servidor para iniciar a consulta, criando uma dependência circular. Esse registro é chamado de glue record.

Com isso, qualquer consulta para vagas.sp.gov.br será direcionada para o servidor ns1.vagas.sp.gov.br, que passa a ser responsável por responder pelas informações dessa nova zona.

Domínios de nível superior - Top Level Domain

Os domínios de nível superior (Top Level Domains - TLDs) são os domínios mais altos na hierarquia do DNS, localizados logo abaixo da raiz (.). Os TLDs são utilizados para organizar o domain namespace do DNS e podem ser classificados em diferentes categorias.

TLD	Descrição
com	Organizações comerciais, como Hewlett-Packard (hp.com), Sun Microsystems (sun.com) e IBM (ibm.com).
edu	Organizações educacionais, como a U.C. Berkeley (berkeley.edu) e Purdue University (purdue.edu).
gov	Organizações governamentais, como a NASA (nasa.gov) e a National Science Fundation (nsf.gov).
mil	Organizações militares, como o Exército dos EUA (army.mil) e a Marinha (navy.mil).
net	Anteriormente organizações que fornecem infraestrutura de rede, como a NSFNET (nsf.net) e UUNET (uu.net). Desde 1996, no entanto, a rede está aberta a qualquer organização.
org	Organizações anteriormente não comerciais, como a Electronic Frontier Foundation (eff.org). Como a .net as restrições para à .org foram removidas em 1996.
int	Organizações internacionais, como a NATO (nato.int).

Outro domínio de nível superior, chamado arpa, foi originalmente utilizado durante a transição da ARPAnet das tabelas de hosts para o DNS. Na época, os hosts eram organizados sob o domínio arpa, facilitando sua localização. Com a evolução do DNS, esses hosts foram migrados para domínios organizacionais, e o arpa passou a ter um papel técnico dentro da infraestrutura do DNS.

Hoje, ele é utilizado para funções específicas, como a resolução reversa de endereços IP, por meio de domínios como in-addr.arpa (IPv4) e ip6.arpa (IPv6).

Com o tempo, foram criados os domínios de nível superior de código de país, conhecidos como ccTLD (country-code Top Level Domains), como: br (Brasil), us (Estados Unidos), jp (Japão) dentre outros. Com isso, os domínios de nível superior (TLD) deixaram de ser vistos como um único grupo homogêneo e passaram a ser classificados em diferentes categorias.

Nesse contexto, os domínios tradicionais como .com, .org e .net passaram a ser conhecidos como gTLD (generic Top Level Domains), enquanto os domínios associados a países, como .br, .us e .jp, passaram a ser classificados como ccTLD. O termo "genérico" é utilizado para diferenciar os gTLD dos domínios de nível superior de código de país, conhecidos como ccTLD (country-code top-level domains), que são associados a países ou territórios específicos.

Essa distinção existe porque todos esses domínios ocupam a mesma posição na hierarquia do DNS, logo abaixo da raiz (.). Trata-se apenas de uma classificação que permite diferenciar domínios de uso geral, como .com, .org e .net, daqueles vinculados a países, como .br, .uk e .jp.

Vale mencionar que a administração desses domínios é descentralizada. Cada ccTLD é operado por uma organização responsável, geralmente designada para gerenciar aquele domínio por meio da delegação de autoridade, cuidando da sua operação e manutenção.

Pesquisa recursiva e iterativa

Durante o processo de resolução de nomes no DNS, podem ocorrer dois tipos de consulta: recursiva e iterativa. Na consulta recursiva, o cliente solicita ao servidor DNS que resolva completamente um nome de domínio. Isso significa que o servidor consultado se responsabiliza por obter a resposta final, consultando outros servidores DNS quando necessário, até chegar a um servidor autoritativo. Ao final do processo, ele retorna ao cliente a resposta definitiva, como o endereço IP solicitado.

Já na consulta iterativa, o servidor DNS não realiza a resolução completa. Em vez disso, ele retorna a melhor resposta que possui naquele momento, sem consultar outros servidores em nome do cliente. Isso significa que o servidor consultado verifica seus dados locais, incluindo seu cache. Caso não possua a resposta final, ele retorna uma referência para outros servidores DNS que estão mais próximos da resposta, como os servidores responsáveis por um domínio de nível superior ou por uma zona específica.

O termo pesquisa Iterativa pode ser usado também como Resolução Iterativa ou até mesmo Consulta Iterativa.

Com essas informações, cabe ao cliente ou ao resolver que iniciou a consulta continuar o processo, entrando em contato com os próximos servidores até obter a resposta final. A consulta iterativa ocorre, quando um servidor DNS não está configurado para realizar resolução recursiva ou quando esse comportamento é explicitamente solicitado.

FQDN

O FQDN (Fully Qualified Domain Name, ou em português, Nome de Domínio Completamente Qualificado), também chamado de nome de domínio absoluto, é um nome de domínio que especifica sua localização exata na árvore hierárquica do Domain Name System (DNS). Ele representa o nome completo de um host, incluindo todos os níveis da hierarquia, até a raiz (.). Por esse motivo, um FQDN é único e não ambíguo, podendo ser interpretado de apenas uma maneira dentro do DNS.

Considere o seguinte exemplo:

Nome do computador: foo
Nome do domínio: bar.com

O FQDN correspondente será: foo.bar.com..

Observe o ponto final (.), que representa a raiz do DNS. Embora geralmente seja omitido no dia a dia, ele faz parte do nome completo. Outros exemplos de FQDN:

espec.ppgia.pucpr.br.
www.uol.com.br.
www.mit.edu.
edas.info.

PDQN

Um PQDN (Partially Qualified Domain Name) é um nome de domínio que não especifica completamente sua posição na hierarquia do DNS, ou seja, não inclui todos os níveis até a raiz (.). Por esse motivo, ele é considerado um nome relativo, podendo depender do contexto para ser interpretado corretamente.

Esses nomes também podem ser chamados de relative domain names ou simplesmente hostnames, sendo frequentemente utilizados para se referir a máquinas dentro de um domínio local. Por exemplo, considere o nome: foo.

Esse nome, isoladamente, não é um FQDN. Ele pode ser interpretado como:

foo.bar.com.
foo.local.
foo.interno.empresa.

Dessa forma, um PQDN só pode ser resolvido corretamente quando o sistema possui contexto suficiente para completar ele até um FQDN.

Tipo de Registros DNS

A maioria das entradas presentes nos arquivos de zona do DNS é chamada de registros de recursos (Resource Records - RR). Esses registros são responsáveis por armazenar informações essenciais sobre um domínio ou nome de host, como endereços IP, servidores DNS e serviços disponíveis. Cada registro possui um tipo específico, que define qual informação está sendo representada e como ela deve ser interpretada pelo servidor DNS.

Os registros DNS são armazenados em arquivos de texto, conhecidos como arquivos de zona, mantidos em servidores DNS autoritativos. Esses arquivos seguem uma sintaxe própria, composta por diretivas e instruções que são interpretadas pelo servidor DNS para responder às consultas realizadas pelos clientes.

A tabela a seguir apresenta os principais tipos de registros DNS:

Registro	Descroção
SOA	Start of Authority. Define o início da autoridade da zona e contém informações administrativas, como servidor primário, e-mail do responsável e parâmetros de controle da zona.
NS	Name Server. Indica quais servidores DNS são autoritativos para a zona.
A	Associa um nome de domínio a um endereço IPv4.
AAAA	Associa um nome de domínio a um endereço IPv6.
MX	Mail Exchange. Define os servidores responsáveis pelo recebimento de e-mails do domínio.
CNAME	Canonical Name. Cria um alias para um nome do domínio que já existe.
PTR	Pointer Record. Utilizado em resolução reversa, associando um endereço IP a um nome de domínio.
TXT	Permite armazenar informações textuais. É amplamente utilizado para configurações como SPF, DKIM e verificações de domínio.
SRV	Service Record. Especifica a localização de serviços no domínio, incluindo hostname, porta e protocolo.

O que é o SPF?

O SPF (Sender Policy Framework) é um mecanismo de autenticação de e-mail que permite ao domínio declarar quais servidores estão autorizados a enviar mensagens em seu nome. Seu principal objetivo é reduzir práticas como spoofing, onde terceiros tentam se passar por um domínio legítimo durante o envio de e-mails.

A política SPF é publicada no DNS por meio de um registro TXT. Nesse registro, o administrador define uma lista de servidores autorizados, além do comportamento esperado caso um servidor não autorizado tente enviar mensagens utilizando o domínio. O processamento dessas regras segue as definições da RFC 4408.

Durante a validação, o servidor de destino consulta o registro SPF do domínio remetente e compara o endereço IP de origem da mensagem com as regras definidas. O resultado dessa verificação determina como a mensagem será tratada.

Qualificadores SPF

Os qualificadores indicam o resultado da validação e orientam a ação a ser tomada pelo servidor receptor:

+ (Pass)
Indica que o endereço IP está autorizado a enviar mensagens em nome do domínio. A mensagem deve ser considerada legítima sob a política SPF.
- (Fail)
Indica explicitamente que o endereço IP não está autorizado. A recomendação é que a mensagem seja rejeitada.
~ (SoftFail)
Indica que o IP provavelmente não está autorizado, mas sem garantia absoluta. A mensagem não deve ser rejeitada automaticamente, sendo recomendado aplicar verificações adicionais, como análise de spam.
? (Neutral)
Indica ausência de política definida para o IP avaliado. O resultado deve ser tratado como neutro, equivalente à inexistência de um registro SPF aplicável.

Exemplo de registro SPF

v=spf1 ip4:192.0.2.10 include:_spf.exemplo.com -all

Neste exemplo:

Apenas o IP 192.0.2.10 e os servidores definidos em _spf.exemplo.com estão autorizados
O modificador -all indica que qualquer outro servidor deve ser rejeitado

Protocolo AXFR

O AXFR (Asynchronous Full Zone Transfer) é um mecanismo utilizado para realizar a transferência completa de uma zona DNS entre servidores. Esse processo é essencial para manter a consistência dos dados entre o servidor primário (master) e os servidores secundários (slaves).

Durante uma transferência AXFR, todo o conteúdo do arquivo de zona é replicado do servidor autoritativo principal para outro servidor autorizado.

Embora seja um mecanismo legítimo de replicação, o AXFR pode representar um risco de segurança quando exposto indevidamente. Isso ocorre porque uma transferência de zona bem-sucedida permite obter todas as entradas DNS de um domínio, incluindo subdomínios, servidores e outras informações sensíveis.

Diferente de consultas DNS comuns, que retornam apenas registros específicos, o AXFR retorna a zona completa, desde que o servidor permita esse tipo de operação. A transferência de zona pode ser testada utilizando ferramentas como o dig:

# Exemplo de consulta AXFR:
$ dig @SERVIDOR AXFR DOMINIO

Se o servidor estiver configurado de forma inadequada, esse comando retornará todos os registros da zona.

BIND - Berkeley Internet Name Domain

O BIND (Berkeley Internet Name Domain) é uma das implementações mais tradicionais e amplamente utilizadas do Sistema de Nomes de Domínio (DNS). Ele fornece suporte completo para atuação como servidor autoritativo, resolvedor recursivo ou ambos. Na LPIC-2, o foco está na versão BIND 9.x, que é a linha atualmente mantida e utilizada em ambientes de produção.

Apesar de sua ampla adoção, existem outras implementações de servidores DNS que podem ser utilizadas conforme o cenário e os requisitos do ambiente:

DJBDNS
Desenvolvido por Daniel J. Bernstein, é conhecido por sua abordagem focada em segurança e simplicidade. Possui uma arquitetura diferente do BIND e separa funcionalidades em componentes distintos.
DnsMasq
Solução leve que combina cache DNS e servidor DHCP. É amplamente utilizado em redes locais, roteadores e ambientes pequenos devido à sua facilidade de configuração.
Power DNS
Implementação robusta e escalável, bastante utilizada em ambientes de grande porte. Possui suporte a diferentes backends (como bancos de dados) e é uma alternativa moderna ao BIND.
NSD
Servidor DNS autoritativo de código aberto, desenvolvido pelo NLnet Labs em cooperação com o RIPE NCC. Foi projetado para ser simples, eficiente e altamente confiável. Por design, o NSD não implementa resolução recursiva nem cache. Ele é utilizado exclusivamente como servidor autoritativo.
Para cenários que exigem resolução recursiva com cache e validação DNSSEC, o NLnet Labs também desenvolve o Unbound, que pode ser utilizado em conjunto com o NSD.

Instalação e configuração do Bind em modo Recursivo

Vamos instalar o BIND e fazer a configuração básica para atuar como servidor DNS recursivo (com cache). A instalação do BIND varia de acordo com a distribuição utilizada:

## CentOS / RHEL:
$ sudo yum install bind bind-utils

# Habilite o serviço no Boot e inicie ele:
$ sudo systemctl enable named
$ sudo systemctl start named

## Debian / Ubuntu:
$ sudo apt install bind9 bind9-utils -y

O pacote bind-utils (ou bind9-utils) inclui ferramentas essenciais para diagnóstico e testes, como dig, host e nslookup.

A organização dos arquivos de configuração do BIND varia entre distribuições. No CentOS/RHEL, a maior parte da configuração está centralizada em um único arquivo. Já no Debian/Ubuntu, a configuração é modular, dividida em múltiplos arquivos. A tabela abaixo resume os principais arquivos e suas localizações:

Descrição	CentOS	Debian
Arquivo principal (lembrando que no Debian é dividido entre vários arquivos)	`/etc/named.conf`	`/etc/bind/named.conf`
Diretório de zonas DNS	`/var/named/`	`/etc/bind/`
Arquivo de Root Servers (root hints)	`/var/named/named.ca`	`/etc/bind/db.root` ou `/usr/share/dns/root.hints`
Definição de zonas (direta, reversa, secundária)	`/etc/named.conf`	`/etc/bind/named.conf.default-zones`
Opções globais (DNSSEC, forwarders, segurança)	`/etc/named.conf`	`/etc/bind/named.conf.options`
Configuração de zonas locais (RFC1918), veja aqui.	`/etc/named.conf`	`/etc/bind/named.conf.local`

Como mencionado anteriormente, o BIND já vem, por padrão, configurado para atuar como um servidor DNS recursivo (cache-only). Isso pode ser observado no arquivo principal de configuração, onde não existe definição de zonas autoritativas, mas sim a presença de uma zona especial do tipo hint, responsável por iniciar o processo de resolução recursiva.

Abaixo está um exemplo da configuração padrão no CentOS:

### Centos ###
## Arquivo: /etc/named.conf

options {

            # Define em quais endereços e portas o servidor DNS irá escutar:
        listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        
        # Diretório base utilizado pelo BIND:
        directory       "/var/named";

        # Arquivos de estatísticas e dump de cache:
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        
        # Define quais clientes podem realizar consultas:
        allow-query     { localhost; };

            # Ativa resolução recursiva:
        recursion yes;
        
        # Suporte a DNSSEC:
        dnssec-enable yes;
        dnssec-validation yes;

        # Arquivo de chaves para validação DNSSEC:
        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.root.key";

        managed-keys-directory "/var/named/dynamic";

        # Arquivos de controle do processo do BIND:
        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";
};

# Zona raiz utilizada como ponto inicial da resolução recursiva:
zone "." IN {
        type hint;
        file "named.ca";
};

Por padrão, consultas DNS realizadas por clientes utilizam a porta 53 via UDP, pois esse protocolo é mais leve e eficiente para requisições simples. O uso de TCP na porta 53 também é suportado, porém ocorre em situações específicas, como quando a resposta excede o tamanho permitido no UDP (truncation), quando o cliente solicita explicitamente o uso de TCP ou durante transferências de zona (AXFR/IXFR).

Em condições normais, o tráfego DNS utiliza UDP. O uso de TCP é reservado para cenários específicos, sendo obrigatório em transferências de zona.

Para facilitar o entendimento, algumas diretivas foram comentadas no exemplo anterior, destacando apenas os parâmetros mais relevantes. Observe que, na configuração padrão, o servidor está restrito a responder apenas localmente:

listen-on e listen-on-v6 definidos como { 127.0.0.1; } e { ::1; }
allow-query limitado a localhost

Isso significa que, por padrão, o servidor DNS atende apenas requisições originadas da própria máquina. Tanto nas diretivas listen-on / listen-on-v6 quanto em allow-query, é possível definir endereços IP específicos ou utilizar a palavra-chave any, permitindo acesso de qualquer origem.

A opção recursion define o comportamento do servidor quando ele não possui a resposta em cache. A opção recursion yes permite que o servidor consulte outros servidores DNS em nome do cliente. Já a opção recursion no limita o servidor a responder apenas com dados locais ou autoritativos. Esse comportamento é fundamental para servidores do tipo resolver recursivo, conforme apresentado na seção de DNS Resolver.

Para operação em modo Recursivo, um ponto essencial é a definição da zona do tipo hint:

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

Essa configuração indica ao BIND onde encontrar os servidores raiz (root servers), permitindo iniciar o processo de resolução recursiva. Nas versões mais novas do BIND (principalmente 9.11+ e mais ainda nas atuais tipo 9.18/9.20), esse bloco não é mais obrigatório e muitas vezes nem aparece mais na configuração padrão já que o BIND já tem isso embutido no código fonte.

A lista oficial de servidores root servers pode ser consultada no site da iana.org.

Tipos de zonas

Serve para informarmos o Bind como ele deve trabalhar com uma determinada zona.

Zonas	Descrição
Master	Zona de autoridade sobre o domínio. Os dados da zona serão criados, publicados e administrados a partir deste ponto.
Slave	Basicamente é uma cópia da zona original, nenhuma criação ou alteração respectiva a essa zona será feita diretamente neste DNS.
Stub	Tipo de zona similar a Slave, não é previsto em nenhuma RFC, foi implementado apenas no BIND.
Hint	Específica para o BIND onde ele deve começar uma busca recursiva, quando estiver operando como cache.
Forward	Serve para orientar o "BIND", e encaminhar a consulta sobre uma determinada zona para outro servidor em especial.

Já no Debian nós temos:

### Debian ###
## Arquivo: /etc/bind/named.conf.default-zones

# Configuração que torna o servidor de cache:
// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/usr/share/dns/root.hints";
};

Já as outras configurações ficam implicitas e se você quiser mudar algo, tem que adicionar elas.

Logging

Por padrão os logs do named são enviados para o /var/log/syslog pelo Syslog no Debian ou para /var/log/messages também pelo serviço do Syslog no CentOS.

O CentOS possui uma declaração de log que grava os logs de Debug em /etc/named/data/named.run.

Severidade

Os logs possuem tipos de severidade, que ditam qual o nível de verbosidade vamos armazenar em Log, apesar de já deixar um esquema de log pronto, veja abaixo as severidades disponíveis para que você consiga configurar de acordo com sua necessidade:

Severidade	Descrição
critical	Somente erros criticos.
error	Erros (não criticos) e também inclui erros criticos.
warning	Aqui temos Warning e as duas opções acima.
notice	Noticia e as três opções acima.
info	Informação e as quatro opções acima.
debug	Debig e as cinco opções acima. Podemos escolher vários níveis de Debug, informando `debug 0` significa sem debug.
dynamic	Depurar e as seis opções acima. Significa assumir o nível de depuração global definido pelo parâmetro de linha de comando `-d` ou executando `rndc trace`.

Além das severidades vamos trabalhar com canais, um canal é apenas um nome para facilitar a identificação da chave onde vamos configurar um arquivo para guardar os logs, por exemplo:

    channel abobrinha {
        file "/var/log/bind/transfers" versions 3 size 10M;
        print-time yes;
        severity info;
    };

Essa chave declara um canal chamado abobrinha, dentro desse canal, vamos dizer qual o arquivo onde será armazenado o log, isso é fornecido pela opção file. A opção print-time yes; é usada para guardar o Log com hora e data.

Além desse print ainda temos outros:

Opção	Descrição
print-severity	Controla se o nível de severidade vai ser escrito no log ou não. Padrão é não.
print-category	Controla se a categoria vai ser escrito no log ou não. Padrão é não.

Versions

Em versions devemos dizer quantas versões vamos querer ter para esse arquivo. Os arquivos de versão são criados pelo BIND anexando .0, .1 e etc ao nome do arquivo. Podemos usar a palavra versions unlimited para não criar versões de arquivos, mas tome cuidado, caso seja definido tamanho para os arquivos de log serão sim criados várias versões para o mesmo arquivo.

Novas versões de log serão criadas apenas quando o BIND for reiniciado.

Os arquivos são renomeados ou sobrescritos de modo que .0 sempre conterá as últimas informações de log antes de iniciar o novo log, .1 será o segundo e assim por diante. Se nenhuma instrução de versão for definida, um único arquivo de log de tamanho ilimitado será usado e, na reinicialização, novos dados serão anexados ao arquivo definido. Isso pode chegar a ser um arquivo muito grande.

Size

Em size devemos dizer o tamanho que cada arquivo de log deve ter. Para a dimensão podemos usar as letras (pode ser maiúsculas ou minúsculas): k , m, g.

Agora se atente ao seguinte:

Se você especificar um valor para size e não especificar o parâmetro versions, quando o limite de tamanho for atingido, o BIND interromperá o registro até que o tamanho do arquivo seja reduzido abaixo do limite definido, ou seja, excluindo ou truncando o arquivo.
Se você especificar o parâmetro size (com valor) e o parâmetro versions (com valor), os arquivos de log serão rotacionados quando o limite de tamanho for atingido.
Se você não especificar o parâmetro size e versions, os arquivos de log serão rotacionados somente quando o BIND for reiniciado.

Categoria	Descrição
client	Processamento de solicitações de clientes.
config	Análise e processamento do arquivo de configuração.
database	Mensagens relacionadas aos bancos de dados usados internamente pelo servidor de nomes para armazenar dados de zona e cache.
default	Registra todos os valores que não são explicitamente definidos em declarações de categoria, ou seja, se esta for a única categoria definida, ele registrará todas as categorias listadas nesta tabela, com exceção das consultas que não são ativadas por padrão.
delegation-only	Registra as consultas que retornaram NXDOMAIN como resultado de uma zona somente de delegação ou uma instrução somente de delegação em uma dica ou declaração de zona de stub.
dispatch	Envio de pacotes recebidos para os módulos do servidor onde serão processados.
dnssec	Processamento do protocolo DNSSEC e TSIG.
general	Qualquer coisa que não seja classificada como qualquer outro item nesta lista é padronizada para esta categoria.
lame-servers	Servidores chatos. Configuração incorreta na delegação de domínios descoberta pelo BIND 9 ao tentar respostas autoritativas. Se o volume dessas mensagens for alto, muitos usuários optam por enviá-las para o canal nulo, por exemplo: `categoria lame-servers { null; };`.
network	Registra todas as operações de rede.
notify	Registra todas as operações NOTIFY.
queries	Registra todas as transações de consulta. A instrução querylog pode ser usada para substituir esta instrução de categoria. Esta entrada pode gerar um volume substancial de dados muito rapidamente. Esta categoria não está ativada por padrão e, portanto, o tipo padrão acima não registrará essas informações.
resolver	Resolução de nomes, incluindo pesquisas recursivas realizadas em nome de clientes por um servidor de nomes de cache.
rpz	Todas as operações relacionadas ao processamento da Zona de Política de Resposta (RPZ). Mesmo quando as zonas RPZ estão desativadas (usando o parâmetro policy disabled na declaração de política de resposta) o a operação é concluída, registrada e descartada (a resposta real é retornada ao usuário).
rate-limit	Todas as operações relacionadas a uma ou mais declarações rate-limit nas options ou view cláusulas.
security	Aprovação e negação de pedidos.
unmatched	Nenhuma cláusula de exibição correspondente ou valor de classe não reconhecido. Um resumo de uma linha também é registrado na categoria do cliente. Por padrão, esta categoria é enviada para o canal nulo.
update	Registro de todas as transações de atualização dinâmica (DDNS).
update-security	Aprovação e negação de solicitações de atualização usadas com DDNS.
xfer-in	Detalhes das transferências de zona que o servidor está recebendo.
xfer-out	Detalhes das transferências de zona que o servidor está enviando.

AppArmor

Sistemas que rodam o AppArmor como o Ubuntu, é necessário fazer uma atualização nas regras dele para permitir escrita nos arquivos em /var/log/bind/, caso contrário não será possível.

# Edite o arquivo abaixo:
$ sudo vim /etc/apparmor.d/usr.sbin.named

Dentro do arquivo você vai procurar a sessão abaixo:

  # /etc/bind should be read-only for bind
  # /var/lib/bind is for dynamically updated zone (and journal) files.
  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
  # See /usr/share/doc/bind9/README.Debian.gz
  /etc/bind/** r,
  /var/lib/bind/** rw,
  /var/lib/bind/ rw,
  /var/cache/bind/** lrw,
  /var/cache/bind/ rw,

Após a linha /var/cache/bind/ rw vamos adicionar as duas linhas abaixo para permitir a escrita:

  /var/log/bind/** rw,
  /var/log/bind/ rw,

Agora reinicie o serviço do AppArmor:

$ sudo systemctl restart apparmor

Agora reinicie o servidor do Bind, serve em ambos os sistemas (Debian e CentOS):

$ sudo systemctl restart named

Em versões mais recentes do DNS BIND, o log não está sendo iniciado automaticamente após a inclusão da configuração sem reiniciar o serviço.
Para que o log passe a ser registrado, com o serviço rodando, é preciso utilizar o seguinte comando:
# rndc querylog
Ou reiniciando totalmente o serviço:
# rndc stop

# rndc start

RNDC Options

Vamos ver algumas opções importante para o comando rndc:

Opção	Descrição
reload	Recarrega os arquivos de configuração e arquivos de zonas.
flush	Limpa todo o cache que foi armazenado no servidor.
reconfig	Recarrega os arquivos de configuração e arquivos de zonas que são novas (ainda não incluídas anteriormente) .

Fontes importantes

https://dnsviz.net

https://www.zytrax.com/books/dns/ch4/#caching

https://www.zytrax.com/books/dns/ch7/logging.html

Conceitos sobre DNS​

The Domain Namespace​

Domain Namespace Zones​

Name Servers (NS)​

DNS Resolver​

Delegação de subdomínios​

Domínios de nível superior - Top Level Domain​

Pesquisa recursiva e iterativa​

FQDN​

PDQN​

Tipo de Registros DNS​

Protocolo AXFR​

BIND - Berkeley Internet Name Domain​

Instalação e configuração do Bind em modo Recursivo​

Tipos de zonas​

Logging​

Severidade​

Versions​

Size​

Category​

AppArmor​

RNDC Options​

Fontes importantes​