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. A ISC desenvolve o BIND, uma das implementações mais usadas de servidor DNS.

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 de root servers, eles são operados por várias organizações e replicados em muitas instâncias anycast, ou seja, 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 é o componente usado no processo de resolução de nomes. O resolver é quem consulta o DNS para obter dados associados a um nome de domínio. Um Resolver pode existir em dois contextos:

No cliente (stub resolver)
O stub resolver é um componente simples do sistema operacional, normalmente implementado como uma biblioteca ou serviço utilizado pelas aplicações, como navegadores, clientes de e-mail e outros programas que precisam resolver nomes de domínio.
Ele não percorre sozinho a hierarquia do DNS nem consulta diretamente os servidores raiz, os servidores de TLD e os servidores autoritativos. Também não costuma processar referências DNS, isto é, respostas que indicam quais servidores devem ser consultados em seguida.
Sua função é receber a solicitação da aplicação e encaminhá-la, normalmente como uma consulta recursiva, para um resolvedor DNS recursivo configurado. Esse resolvedor pode ser fornecido pela rede local, pelo roteador, pelo provedor de Internet ou por um serviço público de DNS.
Em sistemas Unix/Linux, os endereços dos resolvedores utilizados pelo sistema podem aparecer em /etc/resolv.conf, embora esse arquivo também possa ser gerenciado automaticamente por ferramentas como NetworkManager, systemd-resolved ou pelo cliente DHCP.
No servidor (resolver recursivo)
Esse é o servidor DNS que realmente "faz o trabalho pesado". Quando ele recebe uma consulta recursiva do stub resolver, ele primeiro verifica se já possui a resposta em cache. Se possuir, responde imediatamente.
Se não possuir, ele consulta a hierarquia DNS usando consultas iterativas, começando pelos servidores raiz, então ele recebe uma indicação para os servidores do TLD (como .com ou .br), depois recebe a indicação para os servidores autoritativos do domínio, e continua até obter a resposta final ou um erro como NXDOMAIN.

No fim das contas, o resolver é um termo usado para definir o componente responsável por intermediar ou executar consultas DNS. Ele pode existir no cliente (como um stub resolver), que é implementado normalmente como uma biblioteca. Mas esse termo também pode ser usado para se referir ao servidor (como um resolver recursivo), que é responsável por realizar a resolução completa.

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? -- Essa parte não cai na LPIC-2

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 é 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 e os servidores Secundários.

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

Apesar do AXFR ter sido criado pensando em resolver o problema de replicação entre servidores DNS, ele pode representar um risco de segurança quando exposto indevidamente. Essa falha pode ocorrer 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 bind9-dnsutils/bind-utils fornece os comandos dig e nslookup, além de depender do pacote bind9-host, que é responsável pelo comando host.

Também é possível encontrar o pacote dnsutils em Debian/Ubuntu. Porém, ele funciona como um pacote de transição que instala o bind9-dnsutils.

Quando instalamos o bind9-utils, é para obter ferramentas administrativas do BIND, como named-checkconf, named-checkzone, rndc e utilitários relacionados ao DNSSEC.

A organização dos arquivos de configuração do BIND pode variar bastante conforme a forma de instalação e a distribuição utilizada. Em instalações feitas por pacotes da própria distribuição, normalmente existe um padrão já definido pelo mantenedor do sistema.

No CentOS/RHEL, a configuração tende a ficar mais centralizada, geralmente partindo do arquivo principal named.conf. Já no Debian/Ubuntu, é comum encontrar uma estrutura mais modular, com o arquivo principal incluindo outros arquivos separados para opções globais, zonas locais entre outras.

Em cenários onde o BIND é compilado manualmente a partir do código-fonte, essa organização pode mudar completamente. Nesse caso, a localização dos arquivos, a divisão entre arquivos principais e arquivos incluídos, os diretórios de zonas, logs, chaves e arquivos auxiliares passam a depender das opções usadas na compilação, dos caminhos definidos na instalação e, principalmente, da decisão do administrador.

Portanto, nesse cenário não existe uma estrutura única obrigatória, já que o administrador pode centralizar tudo em um único arquivo ou criar uma organização modular própria, desde que os caminhos estejam corretamente referenciados na configuração do BIND.

A tabela abaixo resume os principais arquivos e localizações encontrados em instalações típicas por pacotes nas distribuições mais comuns.

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, junto dessa opção, também é usado allow-recursion e allow-query-cache. 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	Esse tipo de zona é uma configuração específica do BIND. É uma forma do BIND declarar quais são os root hints usados na inicialização do servidor. No entanto, o conceito por trás disso, não é exclusivo do BIND.
Forward	Usado para encaminhar a consultas sobre uma determinada zona para outro servidor DNS.

No Debian/Ubuntu, a configuração dos root hints costuma aparecer de forma explícita no arquivo /etc/bind/named.conf.default-zones. Essa entrada informa ao named qual arquivo deve ser usado como lista inicial de servidores raiz durante a resolução recursiva:

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

# 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";
};

Essa configuração apenas fornece ao BIND uma lista inicial de servidores raiz, usada no início do serviço de DNS para localizar um servidor raiz e obter a lista atual dos servidores autoritativos da zona raiz. O próprio ARM do BIND descreve a zona type hint como o conjunto inicial de servidores raiz usado no startup do BIND, se nenhuma zona hint for configurada, o BIND usa uma lista padrão já compilada no próprio código.

Por isso, em algumas distribuições ou instalações mais recentes, essa zona pode não aparecer declarada explicitamente no named.conf, porque o BIND já possui root hints embutidos no código. Ainda assim, é válido declarar a zona raiz manualmente e apontar para um arquivo de hints, como root.hints, named.root, named.ca ou outro nome definido pelo administrador.

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	Debug 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;
    };

Esse bloco declara um channel chamado abobrinha. Nesse caso, a diretiva file indica que as mensagens associadas a esse canal serão escritas no arquivo /var/log/bind/transfers. As opções versions 3 e size 10M controlam a rotação do arquivo: quando o log atingir o tamanho definido, o BIND poderá manter até três versões anteriores do arquivo antes de sobrescrevê-las.

A opção print-time yes; faz com que cada entrada de log seja registrada com data e hora, o que facilita a análise posterior dos eventos. Já severity info; define o nível mínimo de severidade aceito por esse canal, registrando mensagens de nível info e também mensagens mais severas, como notice, warning, error e critical.

Além desse print-*, ainda temos alguns 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.

É importante observar que esse channel sozinho apenas define o destino e o formato do log. Para que ele seja usado de fato, ele precisa ser associado a uma category, por exemplo xfer-in, xfer-out, queries, security ou outra categoria de log do BIND. A category define quais tipos de mensagens serão enviados para esse canal.

Versions

Em versions, definimos quantas versões antigas do arquivo de log o BIND deve manter durante a rotação. Por exemplo, com versions 3, o BIND pode manter o arquivo atual e mais três arquivos anteriores, normalmente usando sufixos como .0, .1 e .2, dependendo do formato de sufixo usado. Quando o arquivo atinge o tamanho definido em size, ele é rotacionado: o log atual é renomeado e um novo arquivo passa a ser usado.

Se atente a opção versions unlimited, ela não significa "não criar versões", mas quer dizer que o BIND não terá um limite fixo para a quantidade de versões antigas mantidas. Por isso, deve ser usada com cuidado, principalmente quando também existe um limite de tamanho configurado com size, pois cada rotação poderá gerar novos arquivos e consumir espaço em disco continuamente.

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

Os arquivos são renomeados ou sobrescritos de forma que o sufixo .0 contenha as informações de log mais recentes antes da criação de um novo arquivo. O arquivo .1 conterá a versão anterior à .0, e assim sucessivamente. Se nenhuma diretiva versions for definida, será usado apenas um único arquivo de log, sem rotação controlada pelo BIND. Nesse caso, ao reiniciar o serviço, os novos registros continuarão sendo anexados ao arquivo já existente. Com o tempo, esse arquivo pode crescer bastante e ocupar muito espaço em disco.

Size

Em size, definimos o tamanho máximo que cada arquivo de log pode atingir antes de ocorrer a rotação. Para indicar a unidade de medida, podemos usar as letras k, m ou g, representando kilobytes, megabytes e gigabytes. Essas letras podem ser escritas em maiúsculas ou minúsculas.

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	servidor lame/mal delegado. 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 - Não cai na LPIC-2

Em sistemas que utilizam AppArmor (como o Ubuntu), pode ser necessário ajustar o perfil de segurança do BIND para permitir a escrita em arquivos dentro de /var/log/bind/. Caso essa permissão não esteja prevista nas regras do AppArmor, o named pode não conseguir criar ou escrever nos arquivos de log, mesmo que as permissões tradicionais do sistema de arquivos estejam corretas.

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

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

/etc/apparmor.d/usr.sbin.named
  # /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:

/etc/apparmor.d/usr.sbin.named

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

Agora reinicie o serviço do AppArmor:

$ sudo systemctl restart apparmor

Agora reinicie o serviço 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

# sudo systemctl start named

RNDC Options

O RNDC é a ferramenta de controle remoto do BIND. O comando é o próprio nome (rndc) e é usado para administrar o processo named sem precisar parar e iniciar o serviço manualmente. Com ele, nós podemos executar operações como recarregar zonas, recarregar a configuração, limpar cache, consultar o status do servidor, habilitar ou desabilitar logs de consulta, congelar ou descongelar zonas dinâmicas e parar o serviço de forma controlada.

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 - Não cai na LPIC-2​

RNDC Options​

Fontes importantes​