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

Os servidores de nomes autorizados (authoritative) que atendem à zona raiz do DNS, são conhecidos como servidores raiz ou Root Servers em inglês, eles são uma rede de centenas de servidores em muitos países ao redor do mundo. Eles são configurados na zona raiz do DNS como 13 autoridades nomeadas.

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)

O NameServer é um programa que roda no servidor de nomes responsável por informar o endereço IP de um Host, além disso, temos alguns tipos de Name Servers, são eles:

Tipo	Descrição
Master	Possui autoridade sobre o domínio (ou zona), é conhecido como Authoritative.
Slave	Segundo servidor a ter autoridade sobre domínio (ou zona), ele recebe essa autoridade do servidor Master.
Caching	Padrão ao instalar o BIND. Faz consultas em outros servidores DNS (Master e Slave) e armazena localmente por um determinado tempo. Esse tipo não tem autoridade sobre o domínio (ou zona).
Forward	Encaminha a consulta para outro servidor, normalmente um de Cache.

DNS Resolver

É um software ou biblioteca que faz a consulta em servidores DNS, é usado no sistema local (DNS cliente) e também é parte do DNS server. Normalmente ele também guarda em cache as consultas que faz.

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 noso exemplo, o servidor DNS recursivo também não conhece o endereço que estamos consultando, então o servidor recursivo nos fornece os nomes de todos os Root Servers para que possamos perguntar para cada um deles se eles conhecem. Podemos ver uma consulta aos Root Servers abaixo:

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

Naturalmente nenhum Root Server vai conhecer, mas olhando a estrutura do nome ele vai nos responder com o ccTLD (nesse caso é o .br) ou com o gTLD para endereços que não tenham um ccTLD. 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, perguntamos aos DNS do Nic.br 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 escolhemos um dos servidores DNS do Google 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

Como um dos principais objetivos do projeto do Sistema de Nomes de Domínio é descentralizar a administração é possível delegar a responsabilidade de gerenciamento do Domínio.

Um domínio pode ter vários subdomínios delegados e conter hosts que não pertencem aos subdomínios. Isso significa que um domínio pode ser dividido em vários subdomínios, e a responsabilidade por cada subdomínios pode ser transferida a diferentes organizações.

Tomemos como exemplo domínios do Governo Brasileiro, o domínio gov.br possui um subdomínio que é o sp.gov.br e esse mesmo subdomínio pode ser dividido em mais subdomínios e ter a responsabilidade transferida. Veja alguns exemplos: prefeitura.sp.gov.br, saopaulo.sp.gov.br e educacao.sp.gov.br, além de muitos outros.

Para delegar ou passar a autoridade de uma zona é bem simples, imagine que somos responsável pela zona sp.gov.br que já é um subdomínio de gov.br e queremos criar mais um subdomínio e delegar a autoridade para outra pessoa. Para isso basta declarar na nossa zona ou no SOA o seguinte:

# 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

Viu como é fácil? Basicamente criamos um apontamento para outro servidor DNS que ficará responsável por esse novo subdomínio que não está sob nossa responsabilidade.

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

Os domínios de primeiro nível são os domínios de mais alto nível, ou seja, ficam logo abaixo do . (Root Servers). Os TLD são divididos em alguns domínios para organização de conteúdo que cada um deveria entregar, veja alguns dos domínios:

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 primeiro nível chamado arpa foi originalmente usado durante a transição da ARPAnet das tabelas de host para o DNS. Todos os hosts da ARPAnet originalmente tinham nomes de host sob arpa, então eles eram fáceis de encontrar. Mais tarde, eles se mudaram para vários subdomínios do domínios de nível superior organizacionais.

Com o passar dos anos novos domínios de topo foram criados para representar os países individualmente e foram chamados de ccTLD (country-code Top Level Domains), e com isso os tão chamados TLD passaram a serem reconhecidos como gTLD.

O gTLD significa Domínios genéricos de primeiro nível ou gTLDs (generic top-level domains). O "genérico" contrasta com os domínios de topo de código de país, que são específico para um determinado país, isso foi necessário já que os ccTLD ficariam no mesmo nível dos TLD e não teria motivo para ter outro nome.

Vale mencionar que com essa mudança organizações nacionais/regionais foram criadas e por meio da delegação de autoridade cada um cuidaria do seu próprio ccTLD.

Pesquisa recursiva e iterativa

A pesquisa Recursiva e Iterativa acontece durante o processo de resolução de nomes. A pesquisa Rescursiva ja foi explicada aqui, é o processo que o servidor DNS faz para obter o endereço do Host consultando quando o servidor consultado não é o autoritativo da zona DNS. Enquanto que a pesquisa Iterativa informa ao servidor que o cliente deseja a melhor resposta, sem que o servidor DNS tenha que entrar em contato com outros servidores DNS.

Já a pesquisa Iterativa é mais simples e não exige tanto trabalho por parte do servidor de nomes que foi consultado. Antes de entendermos o processo é importante entender quando acontece uma consulta Iterativa.

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

A consulta Iterativa acontece quando o cliente solicita uma consulta no servidor DNS mas o servidor está desabilitado para fazer uma pesquisa recursiva ou quando o cliente explicitamente solicita uma consulta Iterativa.

Como foi dito, um servidor de nomes simplesmente fornece a melhor resposta que já conhece ao cliente durante a pesquisa Iterativa. O servidor de nomes consultado vai consultar seus dados locais (incluindo seu cache) procurando os dados solicitados. Se não encontrar a resposta, ele encontrará os nomes e endereços dos DNS que estão mais próximos ao nome de domínio que o cliente quer consultar e então retornará esses dados como referência para ajudar o cliente a continuar o processo de resolução sozinho, sem a ajuda do servidor DNS inicial.

FQDN

FQDN (Fully Qualified Domain Name, ou em Português, Nome de Domínio Completamente Qualificado), algumas vezes denominado 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 especifica todos os níveis de domínio, incluindo, pelo menos, um domínio de segundo nível e um domínio de nível superior. Um FQDN é distinguido pela sua falta de ambiguidade: ele pode ser interpretado apenas de uma maneira.

Nome do Computador: "foo"
Nome do domínio: "bar.com"

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

Outros exemplos de FQDN:

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

PDQN

Um PQDN (Partially Qualified Domain Name) não inclui subdivisões até a raiz do DNS. Tais nomes são também conhecidos como Relative Domain Name ou Hostname, são apenas os nomes das máquinas pertencentes aos domínios.

Tipo de Registros DNS

A maioria das entradas nos arquivos de dados da zona é chamada de registros de recursos DNS. Os tipos de registro DNS são registros que fornecem informações importantes sobre um nome de host ou domínio. Esses registros incluem o endereço IP atual de um domínio.

Além disso, os registros DNS são armazenados em arquivos de texto (arquivos de zona) no servidor DNS autoritativo. O conteúdo de um arquivo de registro DNS é uma string com comandos especiais que o servidor DNS entende.

Registro	Descroção
SOA	Start of Authority - Indica onde começa a autoridade da zona.
NS	Name Server - Indica um servidor de nome para a zona.
A	Endereço IPv4.
AAAA	Endereço IPv6.
MX	Servidor de E-mail.
CNAME	Canonical Name - Mapeia um nome alternativo.
PTR	Pointer Record - É o reverso (tradução de nome para IP).
TXT	Permite incluir uma entrada de texto curto, mais usado para SPF.
SRV	Abreviação de SeRVice, permite definir localização de serviços disponíveis em um domínio, inclusive seus protocolos e portas (não é muito usado).

O que é o SPF?
O SPF (Sender Policy Framework), é um sistema que evita que outros domínios enviem e-mails não autorizados em nome de um outro domínio.

O domínio pode ou não autorizar que outros IP fora desta relação enviem e-mails em seu nome. O administrador configura esta relação na entrada TXT da zona de DNS seguindo as regras da RFC 4408. A entrada SPF pode ter 4 atributos diferentes que alteram o modo como o servidor de destino tratará mensagens enviadas de servidores que não estejam presentes na mesma.

Tipos de Atributos
+ Pass
Significa que o IP está autorizado a enviar mensagens em nome do domínio, sendo que o domínio consultado pode então ser considerado responsável pelo envio da mensagem.
– Fail
Significa explicitamente que o IP não está autorizado a enviar mensagens em nome do domínio consultado. Este resultado pode ser utilizado para rejeitar a mensagem.
~ SoftFail
Deve ser tratado como um resultado intermediário entre os níveis fail e neutral. Neste caso, o domínio consultado informa que acha que o IP não está autorizado, mas que não pode fazer uma afirmação exata. A mensagem não deve ser rejeitada apenas com base neste resultado, mas é recomendável submetê-la a outros testes.
? Neutral
O dono do domínio não tem como ou não quer definir se um determinado endereço IP está ou não autorizado a enviar mensagens em nome do domínio. Este resultado deve ser tratado exatamente como se não existisse um registro SPF.

Protocolo AXFR

O AXFR é um protocolo para "transferências de zona", para a replicação de dados de DNS em vários servidores DNS, ele faz a replicação por meio do comando dig.

As consultas DNS normais exigem que o usuário tenha alguma informação do servidor DNS, mas as consultas AXFR revelam nomes de subdomínio sem que o consultante tenha informações do servidor DNS (precisa só saber o IP ou nome). O problema disso é que pode ser usado por um atacante para obter de forma eficiente os dados do servidor DNS.

# Ex de comando:
$ dig @SERVIDOR AXFR DOMINIO

Um método para impedir que isso aconteça é implantar TSIG para transferência de zonas.

BIND - Berkeley Internet Name Domain

O BIND é um software que implementa o Protocolo de Resolução de Nomes (DNS). A LPIC-2 cobra apenas o Bind 9.X.

Mesmo o Bind sendo o mais usado ainda temos outras alternativas:

DJBDNS
Criado por Daniel J. Bernstein.
DnsMasq
Combinação entre DNS Cache e DHCP de fácil uso.
Power DNS
Uma implementação de grande porte para aplicação de DNS, compete com o BIND.
NSD
O NSD é um servidor de Sistema de Nomes de Domínio de código aberto. Ele foi desenvolvido pelo NLnet Labs de Amsterdã em cooperação com o RIPE NCC, o NSD foi desenvolvido do zero como um servidor de nomes oficial e hoje é outro que compete fortemente com o BIND.
O NSD não implementou cache recursivo por design. Se você precisar de um resolvedor (Resolver DNS) de cache validador e recursivo, o NLnet Labs tem o Unbound disponível.

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

Vamos começar instalando o Bind:

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

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

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

# bind-utils ou bindutils é um pacote que traz comandos como: dig, host etc.

O CentOS coloca boa parte da configuração em apenas um arquivo, sendo ele o arquivo padrão, enquanto que o Debian divide toda a configuração em vários arquivos.

Descrição	CentOS	Debian
Arquivo principal (lembrando que no Debian é dividido entre vários arquivos)	`/etc/named.conf`	`/etc/bind/named.conf`
Onde ficam as zonas DNS	`/var/named/`	`/etc/bind/`
Arquivo que contém os Root Servers	`/var/named/named.ca`	`/etc/bind/db.root` ou `/usr/share/dns/root.hints`
Arquivo que contém a configuração das zonas DNS, aqui fica as zonas de pesquisa direta, reversa e secundária	`/etc/named.conf`	`/etc/bind/named.conf.default-zones`
É usado para algumas configurações extras como: DNSSEC, IP dos encaminhadores, ajustes de segurança entre outro	`/etc/named.conf`	`/etc/bind/named.conf.options`
Usado para configuração de zonas local compatíveis com a RFC1918. Isso é para resolução de IP privado pelo Bind, veja aqui.	`/etc/named.conf`	`/etc/bind/named.conf.local`

Como já foi dito, a configuração padrão já é Cache only, podemos ver isso através da saída abaixo:

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

options {

        # Qual porta e IP o DNS vai escutar:
        listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        
        # Diretório padrão do servidor DNS:
        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";
        recursing-file  "/var/named/data/named.recursing";
        secroots-file   "/var/named/data/named.secroots";
        
        # Quem pode fazer consultas no servidor DNS:
        allow-query     { localhost; };

        # Faz pesquisa recursiva:
        recursion yes;
        
        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.root.key";

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

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

# Configuração que torna o servidor de cache:
zone "." IN {
        type hint;
        file "named.ca";
};

Por padrão o DNS cliente faz consultas na porta 53 sendo ela UDP, é possível fazer consultas usando TCP, mas você deve específicar que quer consultas TCP no cliente DNS.
Por padrão, conexão na porta 53 sendo TCP só acontece em transferência de zonas.

Tomei a liberdade de comentar algumas linhas acima que não existem no arquivo padrão, facilitando o entendimento do mesmo. Note que o servidor por padrão só vai atender a consultas localmente { 127.0.0.1; } e { ::1; }, ou seja, para ele mesmo.

Tanto no listen-on/listen-on-v6 quanto no allow-query nós podemos específicar o/os IP ou podemos usar any para determinar qualquer um.

Para a opção recursion significa que se o servidor não conhecer o destino ele vai consultar em outros servidores como mostrado em DNS Resolver.

Para a configuração em modo Cache o importante é lembrar de hint, essa opção determina que o servidor seja um DNS de cache. Além do hint ainda temos: master, slave, stub e forward.

Os operadores que gerenciam um resolvedor recursivo de DNS geralmente precisam configurar um “root hints file” (Arquivo de dicas de root).
Este arquivo contém os nomes e endereços IP dos Root Servers, para que o software possa inicializar o processo de resolução de DNS. Para muitos softwares, essa lista vem incorporada ao software.

Veja em 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 Cache​

Tipos de zonas​

Logging​

Severidade​

Versions​

Size​

Category​

AppArmor​

RNDC Options​

Fontes importantes​