Skip to main content

207.2 Criar e Manter Zonas de DNS


Servidor DNS Primário​

Aqui vamos entender como criar e manter uma zona no servidor DNS Primário. Como eu estou testando em dois servidores (Debian e CentOS), eu vou criar duas zonas distintas (uma para cada servidor), assim fica mais fácil só torná-los secundário um do outro para suas zonas primárias.


Antes de começarmos, vamos ver a estrutura de uma zona e entender seus campos. Abaixo segue um exemplo do ínicio da configuração de uma zona DNS:

$TTL 3h
exemplo.br. IN SOA ns1.exemplo.br. admin.exemplo.br. (
    01    ; Serial
    3h    ; Refresh after 3 hours
    1h    ; Retry after 1 hour
    1w    ; Expire after 1 week
    1h )    ; Negative caching TTL of 1 hour

A tabela abaixo contém o descritivo de cada opção da zona acima:

OpçãoDescrição
$TTL 3hDefine o TTL padrão da zona. Os registros que não possuem um TTL próprio poderão permanecer no cache dos resolvedores DNS por até 3 horas antes de serem consultados novamente.
exemplo.br.Domínio dessa zona, poderíamos substituir por @, já que é declarado no arquivo principal do Bind.
INClasse da zona, nesse caso é Internet. Pode ser CH (Chaos), HS (Hesiod), IN (Internet) ou CS (CSNET - Obsoleto).
SOAÉ o tipo do registro da zona. Como estamos declarando uma zona temos que declarar como SOA, pois ele vai declarar a informação da Autoridade da zona. Existem mais de 30 tipos de registro, dentre os quais veremos SOA, NS, MX, A, CNAME, TXT e PTR.
ns1.exemplo.br.Define o servidor DNS primário de referência da zona, indicado no campo MNAME do registro SOA. Neste exemplo, o servidor é ns1.exemplo.br..

Como o nome termina com ponto (.), ele é interpretado como um nome de domínio completo, ou FQDN. Também seria possível informar apenas ns1, sem o ponto final; nesse caso, o nome seria considerado relativo e o domínio atual da zona seria acrescentado automaticamente, resultando em ns1.exemplo.br..
admin.exemplo.br.Define o endereço de e-mail do responsável pela zona, indicado no campo RNAME do registro SOA. Nesse campo, o caractere @ não é utilizado: o primeiro ponto não escapado separa o nome da caixa postal do domínio. Assim, admin.exemplo.br. representa o endereço admin@exemplo.br.

Caso o nome da caixa postal contenha um ponto, ele deve ser escapado com uma barra invertida. Por exemplo, nome\.sobrenome.exemplo.br. representa nome.sobrenome@exemplo.br.
01É o número de série da zona, utilizado principalmente pelos servidores DNS secundários para verificar se a cópia da zona está desatualizada. Sempre que algum registro da zona for alterado, o serial deve ser incrementado.

Uma convenção comum é usar o formato AAAAMMDDNN. Por exemplo, 2018042001 representa a primeira alteração realizada em 20 de abril de 2018. O campo NN pode ser incrementado quando houver mais de uma alteração no mesmo dia. Essa estrutura é apenas uma convenção; o requisito técnico é que o novo serial seja considerado mais recente conforme a aritmética de seriais do DNS.
3hTempo que o servidor secundário vai aguardar até verificar novamente se há atualizações no servidor primário.
1hCaso tenha falha no "refresh" (campo acima), o tempo esperado até a próxima verificação.
1wO tempo que o Slave aguardará o Master voltar, se esgotar o tempo, o Slave para de responder por essa zona (expira).
1hSe a zona expirar, esse será o tempo pelo qual um servidor cache armazenará a informação NXDOMAIN, antes de iniciar uma nova busca recursiva. O máximo são 3 horas.

Como reduzir o SOA serial de zonas? -- Não cai na LPIC-2

Para reduzir o valor do SOA serial, não basta simplesmente trocar o número por um valor menor, pois os servidores secundários comparam o serial usando um algoritmo próprio do DNS. Se o novo valor for interpretado como "mais antigo", os secundários não irão atualizar a zona.


Para isso, devemos somar 2147483647 ao valor atual do SOA serial e publicar novamente a zona. Por exemplo, se o serial atual for 2022111602, o valor intermediário será 4169595249. Abaixo seguem outros valores possíveis para se configurar:

2022111602+2147483647=4169595249
2026052501+2147483647=4173536148
2026052502+2147483647=4173536149

Cada um desses valores pode ser usado como valor intermediário correto, mas depende do SOA atual do seu servidor. Esse valor não é fixo para todos os casos e também não é o maior valor possível do SOA.


Ele depende do serial atual da zona (sempre tenha isso em mente). Se o serial atual for diferente, o valor intermediário também será diferente. Depois que os servidores secundários atualizarem para esse valor intermediário, altere o SOA serial para 0, publique novamente a zona e aguarde a propagação.


Por fim, ajuste o SOA serial para o valor correto desejado e publique a zona mais uma vez.


Em zonas assinadas com DNSSEC, cada alteração no arquivo de zona precisa estar refletida na versão assinada da zona. Portanto, se a assinatura não for automática, será necessário assinar novamente a zona antes de publicá-la em cada etapa.



Configurando o servidor DNS Primário​


O processo é ligeiramente diferente no Debian por causa da estrutura de arquivos:

# Edite o arquivo abaixo para criar o PTR:
$ sudo vim /etc/bind/named.conf.local

## Add a zona abaixo ao final do arquivo!

zone "ubuntu.te" {
    type master;
    file "/etc/bind/db.ubuntu.te";
};

Agora vamos criar a nossa zona:

# Crie o arquivo abaixo:
$ sudo vim /etc/bind/db.ubuntu.te

## Add a conf abaixo ao arquivo!
$TTL 1h
@       IN      SOA     dns.ubuntu.te. admin.ubuntu.te. (
        01      ; Serial
        3h      ; Refresh after 3 hours
        1h      ; Retry after 1 hour
        1w      ; Expire after 1 week
        1h )    ; Negative caching TTL of 1 hour

    IN  NS  dns.ubuntu.te.
@   IN  NS  ns2.ubuntu.te.
        MX  5   dns

dns.ubuntu.te.  A   192.168.121.135 ; glue record
ns2     A   192.168.121.154
ftp     A   192.168.121.200

Um glue record é um registro A ou AAAA publicado na zona pai para informar o endereço IP de um servidor DNS que pertence à própria zona delegada.

Ele é necessário para evitar uma dependência circular durante a resolução DNS.

Considere que a zona pai deseja delegar centos.te. para o servidor:

centos.te.  IN  NS  dns.centos.te.

Para consultar a zona centos.te., o resolvedor precisa entrar em contato com dns.centos.te.. Porém, para descobrir o endereço IP de dns.centos.te., ele precisaria consultar justamente a zona centos.te., que ainda não conseguiu alcançar.

O problema seria este:

Para resolver centos.te.
→ preciso consultar dns.centos.te.

Para encontrar o IP de dns.centos.te.
→ preciso consultar a zona centos.te.

Para quebrar esse ciclo, a zona pai fornece também o endereço IP do servidor DNS:

centos.te.      IN  NS  dns.centos.te.
dns.centos.te.  IN  A   192.0.2.10

Nesse exemplo, o registro A de dns.centos.te. presente na zona pai é o glue record. Com esse endereço, o resolvedor consegue localizar o servidor autoritativo e continuar a resolução.

O glue é necessário principalmente quando o servidor DNS está dentro da própria zona delegada, situação chamada de servidor in-bailiwick.

Caso o servidor esteja em outro domínio, por exemplo:

centos.te.  IN  NS  dns.exemplo.net.

normalmente não é necessário publicar glue na zona pai de centos.te., pois o endereço de dns.exemplo.net. pode ser resolvido por meio da hierarquia DNS de exemplo.net..


Agora verifique se existem erros na configuração:

$ sudo named-checkzone ubuntu.te /etc/bind/db.ubuntu.te
zone ubuntu.te/IN: loaded serial 1
OK

# Agora reinicie usando 'reload' ou 'reconfig':
$ sudo rndc reload
server reload successful

Configure o resolv.conf para ficar assim:

$ cat /etc/resolv.conf
search ubuntu.te
nameserver 127.0.0.1

Depois execute para fazer um teste:

$ host ftp
ftp.ubuntu.te has address 192.168.121.200

# Verifique o servidor de email dessa zona:
$ dig -t mx ubuntu.te +short
5 dns.ubuntu.te.

# Verifique os servidores DNS dessa zona:
$ dig -t ns ubuntu.te +short
dns.ubuntu.te.
ns2.ubuntu.te.

### Após ter mudado as configurações para responder para qualquer IP eu fiz:

$ dig -t ns ubuntu.te @192.168.121.135 +short
ns2.ubuntu.te.
dns.ubuntu.te.

$ dig -t mx ubuntu.te @192.168.121.135 +short
5 dns.ubuntu.te.


Zona DNS Secundária​

Um servidor DNS secundário é um servidor autoritativo que mantém uma cópia de uma determinada zona. Diferente do servidor primário, ele não é o servidor onde os dados da zona são editados, a função do secundário é obter uma cópia da zona a partir do servidor primário e responder autoritativamente pelas mesmas informações.


A autoridade sobre a zona não é "dada" pelo servidor primário no sentido estrito. O servidor secundário passa a ser autoritativo quando é configurado para servir aquela zona e, em um ambiente público, quando também é anunciado corretamente nos registros NS da própria zona. O servidor primário atua como a fonte principal dos dados, enquanto o secundário mantém uma cópia sincronizada.


Essa estrutura permite criar redundância para a zona. Assim, caso o servidor primário fique indisponível, os servidores secundários continuam respondendo pelas consultas DNS, desde que a zona ainda esteja válida de acordo com os parâmetros definidos no registro SOA.


O servidor secundário verifica periodicamente se a zona disponível no servidor primário possui um SOA serial mais recente do que o serial da cópia armazenada localmente. Essa verificação é feita com base nos temporizadores definidos no registro SOA, principalmente o valor de refresh.


Caso a tentativa de verificação falhe, o secundário usa o intervalo definido em retry para tentar novamente. Se não conseguir atualizar a zona dentro do período definido em expire, a zona é considerada expirada e o servidor secundário deixa de responder autoritativamente por ela.


Quando o secundário identifica que o serial da zona no servidor primário é mais novo, ele solicita uma transferência de zona. Essa transferência pode ser completa (usando AXFR) ou incremental (usando IXFR), quando suportado pelos servidores envolvidos.


Além da verificação periódica, o servidor primário também pode enviar uma notificação DNS NOTIFY para avisar os secundários de que a zona foi alterada. Com isso, os secundários podem verificar a nova versão mais rapidamente, sem precisar aguardar o próximo intervalo de refresh.



Configurando Servidor DNS Secundário​

Vamos configurar o servidor Debian para ser Secundário do CentOS.

/etc/bind/named.conf.local
## Add a conf abaixo ao final do arquivo:
zone "centos.te" IN {
        type slave;
        masters { 192.168.121.154; };
        file "db.centos.te";
};

Como não estamos específicando caminho algum, pela configuração principal, o arquivo db.centos.te ficará em /var/cache/bind/.


Agora vamos fazer o Bind ler as novas configurações:

$ sudo rndc reconfig

# Depois podemos olhar nos logs se funcionou:
$ sudo cat /var/log/bind/transfers 
30-Nov-2022 15:46:02.381 zone centos.te/IN: Transfer started.
30-Nov-2022 15:46:02.381 transfer of 'centos.te/IN' from 192.168.121.154#53: connected using 192.168.121.135#49617
30-Nov-2022 15:46:02.385 zone centos.te/IN: transferred serial 1
30-Nov-2022 15:46:02.385 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer status: success
30-Nov-2022 15:46:02.385 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer completed: 1 messages, 8 records, 209 bytes, 0.004 secs (52250 bytes/sec)

# Podemos ver a transferência no lado do CentOS:
cat /var/log/bind/transfers 
30-Nov-2022 15:46:02.385 client @0x7f11100b7690 192.168.121.135#49617 (centos.te): transfer of 'centos.te/IN': AXFR started (serial 1)
30-Nov-2022 15:46:02.386 client @0x7f11100b7690 192.168.121.135#49617 (centos.te): transfer of 'centos.te/IN': AXFR ended

Nós ainda podemos ler o conteúdo do arquivo criado automaticamente durante a transferência com o comando abaixo:

# Entre na pasta:
$ cd /var/cache/bind

# Gere um arquivo que possa ser lido por humanos:
$ sudo named-compilezone -f raw -F text -o centos.te.txt centos.te db.centos.te
centos.te db.centos.te
zone centos.te/IN: loaded serial 1
dump zone to centos.te.txt...done
OK

# -f raw = Formato do arquivo de input;
# -F text = Formato da saída do arquivo;
# -o centos.te.txt = Arquivo que vamos gerar;
# centos.te = Nome do domínio;
# db.centos.te = Arquivo original da zona;


# Agora leia o arquivo:
$ sudo cat centos.te.txt
centos.te.                    3600 IN SOA   dns.centos.te. admin.centos.te. 1 10800 3600 604800 3600
centos.te.                    3600 IN NS    dns.centos.te.
centos.te.                    3600 IN NS    ns2.centos.te.
centos.te.                    3600 IN MX    5 dns.centos.te.
dns.centos.te.                    3600 IN A     192.168.121.154
ftp.centos.te.                    3600 IN A     192.168.121.100
ns2.centos.te.                    3600 IN A     192.168.121.135

# Pode ainda fazer um teste interno:
$ host centos.te 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

centos.te mail is handled by 5 dns.centos.te.

Como teste, vamos fazer uma alteração para ver a transferência de zona usando o comando dig.

# Primeiro verifique quando foi a última transferência:
$ sudo grep -i 'success' /var/log/bind/transfers 
30-Nov-2022 15:55:23.713 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer status: success

# Agora veja informações da zona usando o 'dig':
$ dig @192.168.121.154 axfr centos.te

; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.121.154 axfr centos.te
; (1 server found)
;; global options: +cmd
centos.te.      3600    IN  SOA dns.centos.te. admin.centos.te. 1 10800 3600 604800 3600
centos.te.      3600    IN  NS  dns.centos.te.
centos.te.      3600    IN  NS  ns2.centos.te.
centos.te.      3600    IN  MX  5 dns.centos.te.
dns.centos.te.      3600    IN  A   192.168.121.154
ftp.centos.te.      3600    IN  A   192.168.121.100
ns2.centos.te.      3600    IN  A   192.168.121.135
centos.te.      3600    IN  SOA dns.centos.te. admin.centos.te. 1 10800 3600 604800 3600
;; Query time: 0 msec
;; SERVER: 192.168.121.154#53(192.168.121.154)
;; WHEN: Wed Nov 30 16:55:03 UTC 2022
;; XFR size: 8 records (messages 1, bytes 248)

Podemos ver o SOA de uma forma mais resumida, veja:

# Consulte o SOA do CentOS:
$ dig centos.te @192.168.121.154 SOA +short
dns.centos.te. admin.centos.te. 1 10800 3600 604800 3600

# Consulte o SOA do Debian:
$ dig centos.te @192.168.121.135 SOA +short
dns.centos.te. admin.centos.te. 1 10800 3600 604800 3600

Em ambos o SOA é 1.


Eu vou fazer uma alteração no servidor Master e depois tentarei novamente.

# Consulte o SOA do CentOS:
$ dig centos.te @192.168.121.154 SOA +short
dns.centos.te. admin.centos.te. 2 10800 3600 604800 3600

# Consulte o SOA do Debian:
$ dig centos.te @192.168.121.135 SOA +short
dns.centos.te. admin.centos.te. 2 10800 3600 604800 3600

# Agora verifique quando foi a última transferência:
$ sudo grep -i 'success' /var/log/bind/transfers 
30-Nov-2022 15:55:23.713 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer status: success
30-Nov-2022 16:58:52.625 transfer of 'centos.te/IN' from 192.168.121.154#53: Transfer status: success

A zona foi transferida assim que fiz rndc reload no servidor Master.



Forward​

Uma configuração do tipo forward é usada para encaminhar consultas DNS para outro servidor, chamado de forwarder. Nesse modelo, o servidor local não realiza toda a resolução recursiva por conta própria, ele repassa a consulta para outro resolver, que será responsável por continuar o processo de resolução e devolver a resposta.


Esse encaminhamento pode ser configurado de forma global, para todas as consultas recursivas, ou de forma seletiva, apenas para uma zona específica. Por exemplo, é comum usar forward para encaminhar consultas de uma zona interna, como empresa.local, para os servidores DNS responsáveis por essa rede, enquanto as demais consultas continuam seguindo o fluxo normal de resolução.


O fluxo é mais ou menos assim: o cliente consulta o seu DNS normalmente. Se a consulta bater em uma zona configurada como type forward, o BIND pega essa consulta e encaminha para o servidor definido em forwarders. Esse outro servidor resolve a consulta e devolve a resposta para o BIND. Depois disso, o BIND responde ao cliente como se ele mesmo tivesse obtido a resposta.



Vamos configurar no Debian para que nosso servidor DNS redirecione todas as consultas (menos aquelas em que ele é autoritativo).


/etc/bind/named.conf.options
# Mude a declaração abaixo:
        // forwarders {
        //      0.0.0.0;
        // };

# Para:
        forwarders {
                192.168.121.154;
        };

A diretiva forwarders dentro da cláusula options configura encaminhamento global para as consultas recursivas que o BIND não consegue responder localmente.


Com o BIND, podemos usar as diretiva forward e forwarders em nível global, ambas servem para redirecionar todas as consultas. Se elas forem configuradas como diretivas dentro de uma zone (cláusula de zona), apenas as consultas daquela zona serão redirecionadas. O forward e forwarders são sempre usados juntos.


A diretiva forward only faz com que o BIND use exclusivamente os servidores definidos em forwarders para resolver as consultas encaminhadas (a menos que ele seja autoritativo).


Sem essa opção, o comportamento padrão é forward first. Nesse caso, o BIND tentará encaminhar uma solicitação para outro servidor e, se não conseguir resposta, a solicitação voltará a ser resolvida usando o método padrão (começando nos servidores Root).


O exemplo abaixo demonstra a diretiva forward only:

/etc/bind/named.conf.options
        forwarders {
                192.168.121.154;
        };
        forward only;

Agora vamos fazer a verificação das configurações:

$ sudo named-checkconf /etc/bind/named.conf

# Agora reinicie o bind:
$ sudo rndc reload

Para fazer o teste vou deixar rodando um tcpdump no servidor Debian para vermos ele redirecionar a consulta:

# No Debian:
$ sudo tcpdump -n port 53 -vvvv

Agora usando minha máquina Host eu vou fazer uma consulta para o servidor Debian:

$ host nic.br 192.168.121.135
Using domain server:
Name: 192.168.121.135
Address: 192.168.121.135#53
Aliases: 

NIC.BR has address 200.160.4.6
NIC.BR has IPv6 address 2001:12ff:0:4::6
nic.br mail is handled by 1 mx.nic.br.
nic.br mail is handled by 5 enqueuer.nic.br.

E com isso podemos ver os logs do tcpdump abaixo:

20:30:11.928393 IP (tos 0x0, ttl 64, id 15514, offset 0, flags [none], proto UDP (17), length 52)
    192.168.121.1.55000 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0xefe9!] 58021+ A? nic.br. (24)
20:30:11.929047 IP (tos 0x0, ttl 64, id 60793, offset 0, flags [none], proto UDP (17), length 91)
    192.168.121.135.39515 > 192.168.121.154.53: [bad udp cksum 0x74cb -> 0x466f!] 65161+% [1au] A? nic.br. ar: . OPT UDPsize=4096 DO (63)
20:30:12.158697 IP (tos 0x0, ttl 64, id 30986, offset 0, flags [none], proto UDP (17), length 579)
    192.168.121.154.53 > 192.168.121.135.39515: [bad udp cksum 0x76b3 -> 0xfefa!] 65161 q: A? nic.br. 2/6/13 NIC.BR. [1d] A 200.160.4.6, NIC.BR. [1d] RRSIG ns: br. [2d] NS b.dns.br., br. [2d] NS c.dns.br., br. [2d] NS f.dns.br., br. [2d] NS d.dns.br., br. [2d] NS e.dns.br., br. [2d] NS a.dns.br. ar: a.dns.br. [2d] A 200.219.148.10, c.dns.br. [2d] A 200.192.233.10, b.dns.br. [2d] A 200.189.41.10, d.dns.br. [2d] A 200.219.154.10, e.dns.br. [2d] A 200.229.248.10, f.dns.br. [2d] A 200.219.159.10, a.dns.br. [2d] AAAA 2001:12f8:6::10, c.dns.br. [2d] AAAA 2001:12f8:a::10, b.dns.br. [2d] AAAA 2001:12f8:8::10, d.dns.br. [2d] AAAA 2001:12f8:4::10, e.dns.br. [2d] AAAA 2001:12f8:2::10, f.dns.br. [2d] AAAA 2001:12f8:c::10, . OPT UDPsize=4096 DO (551)
20:30:12.159245 IP (tos 0x0, ttl 64, id 52913, offset 0, flags [none], proto UDP (17), length 91)
    192.168.121.135.32918 > 192.168.121.154.53: [bad udp cksum 0x74cb -> 0x61c6!] 53544+% [1au] DNSKEY? nic.br. ar: . OPT UDPsize=4096 DO (63)
20:30:12.219654 IP (tos 0x0, ttl 64, id 31004, offset 0, flags [none], proto UDP (17), length 279)
    192.168.121.154.53 > 192.168.121.135.32918: [bad udp cksum 0x7587 -> 0x1fa1!] 53544 q: DNSKEY? nic.br. 2/0/1 NIC.BR. [1d] DNSKEY, NIC.BR. [1d] RRSIG ar: . OPT UDPsize=4096 DO (251)
20:30:12.221496 IP (tos 0x0, ttl 64, id 33959, offset 0, flags [none], proto UDP (17), length 91)
    192.168.121.135.40371 > 192.168.121.154.53: [bad udp cksum 0x74cb -> 0xe9ab!] 31871+% [1au] DS? NIC.BR. ar: . OPT UDPsize=4096 DO (63)
20:30:12.259147 IP (tos 0x0, ttl 64, id 31006, offset 0, flags [none], proto UDP (17), length 237)
    192.168.121.154.53 > 192.168.121.135.40371: [bad udp cksum 0x755d -> 0x9483!] 31871 q: DS? NIC.BR. 2/0/1 NIC.BR. [1h] DS, NIC.BR. [1h] RRSIG ar: . OPT UDPsize=4096 DO (209)
20:30:12.263117 IP (tos 0x0, ttl 64, id 46210, offset 0, flags [none], proto UDP (17), length 87)
    192.168.121.135.37383 > 192.168.121.154.53: [bad udp cksum 0x74c7 -> 0x2857!] 34286+% [1au] DNSKEY? br. ar: . OPT UDPsize=4096 DO (59)
20:30:12.275282 IP (tos 0x0, ttl 64, id 31010, offset 0, flags [none], proto UDP (17), length 345)
    192.168.121.154.53 > 192.168.121.135.37383: [bad udp cksum 0x75c9 -> 0xec74!] 34286 q: DNSKEY? br. 3/0/1 br. [6h] DNSKEY, br. [6h] DNSKEY, br. [6h] RRSIG ar: . OPT UDPsize=4096 DO (317)
20:30:12.277847 IP (tos 0x0, ttl 64, id 56367, offset 0, flags [none], proto UDP (17), length 87)
    192.168.121.135.45537 > 192.168.121.154.53: [bad udp cksum 0x74c7 -> 0xbbd1!] 30225+% [1au] DS? br. ar: . OPT UDPsize=4096 DO (59)
20:30:12.288328 IP (tos 0x0, ttl 64, id 31018, offset 0, flags [none], proto UDP (17), length 422)
    192.168.121.154.53 > 192.168.121.135.45537: [bad udp cksum 0x7616 -> 0xfa8f!] 30225 q: DS? br. 2/0/1 br. [1d] DS, br. [1d] RRSIG ar: . OPT UDPsize=4096 DO (394)
20:30:12.301696 IP (tos 0x0, ttl 64, id 46024, offset 0, flags [DF], proto UDP (17), length 74)
    192.168.121.135.53 > 192.168.121.1.55000: [bad udp cksum 0x7421 -> 0xb03a!] 58021 q: A? nic.br. 1/0/0 NIC.BR. [1d] A 200.160.4.6 (46)
20:30:12.303169 IP (tos 0x0, ttl 64, id 15568, offset 0, flags [none], proto UDP (17), length 52)
    192.168.121.1.34687 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0xf19b!] 12338+ AAAA? nic.br. (24)
20:30:12.304917 IP (tos 0x0, ttl 64, id 60831, offset 0, flags [none], proto UDP (17), length 91)
    192.168.121.135.54149 > 192.168.121.154.53: [bad udp cksum 0x74cb -> 0xff24!] 4171+% [1au] AAAA? nic.br. ar: . OPT UDPsize=4096 DO (63)
20:30:12.512080 IP (tos 0x0, ttl 64, id 31155, offset 0, flags [none], proto UDP (17), length 1407)
    192.168.121.154.53 > 192.168.121.135.54149: [bad udp cksum 0x79ef -> 0x6388!] 4171 q: AAAA? nic.br. 2/6/21 NIC.BR. [1d] AAAA 2001:12ff:0:4::6, NIC.BR. [1d] RRSIG ns: br. [2d] NS a.dns.br., br. [2d] NS b.dns.br., br. [2d] NS c.dns.br., br. [2d] NS e.dns.br., br. [2d] NS f.dns.br., br. [2d] NS d.dns.br. ar: a.dns.br. [2d] A 200.219.148.10, c.dns.br. [2d] A 200.192.233.10, b.dns.br. [2d] A 200.189.41.10, d.dns.br. [2d] A 200.219.154.10, e.dns.br. [2d] A 200.229.248.10, f.dns.br. [2d] A 200.219.159.10, a.dns.br. [2d] AAAA 2001:12f8:6::10, c.dns.br. [2d] AAAA 2001:12f8:a::10, b.dns.br. [2d] AAAA 2001:12f8:8::10, d.dns.br. [2d] AAAA 2001:12f8:4::10, e.dns.br. [2d] AAAA 2001:12f8:2::10, f.dns.br. [2d] AAAA 2001:12f8:c::10, a.dns.br. [2d] RRSIG, a.dns.br. [2d] RRSIG, c.dns.br. [2d] RRSIG, c.dns.br. [2d] RRSIG, b.dns.br. [2d] RRSIG, b.dns.br. [2d] RRSIG, d.dns.br. [2d] RRSIG, d.dns.br. [2d] RRSIG, . OPT UDPsize=4096 DO (1379)
20:30:12.525663 IP (tos 0x0, ttl 64, id 46050, offset 0, flags [DF], proto UDP (17), length 86)
    192.168.121.135.53 > 192.168.121.1.34687: [bad udp cksum 0x742d -> 0x4b4a!] 12338 q: AAAA? nic.br. 1/0/0 NIC.BR. [1d] AAAA 2001:12ff:0:4::6 (58)
20:30:12.527150 IP (tos 0x0, ttl 64, id 15583, offset 0, flags [none], proto UDP (17), length 52)
    192.168.121.1.46802 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0x7948!] 31039+ MX? nic.br. (24)
20:30:12.529551 IP (tos 0x0, ttl 64, id 43941, offset 0, flags [none], proto UDP (17), length 91)
    192.168.121.135.60439 > 192.168.121.154.53: [bad udp cksum 0x74cb -> 0xf69b!] 64374+% [1au] MX? nic.br. ar: . OPT UDPsize=4096 DO (63)
20:30:12.709437 IP (tos 0x0, ttl 64, id 31248, offset 0, flags [none], proto UDP (17), length 1417)
    192.168.121.154.53 > 192.168.121.135.60439: [bad udp cksum 0x79f9 -> 0xe297!] 64374 q: MX? nic.br. 3/6/21 nic.br. [5m] MX enqueuer.nic.br. 5, nic.br. [5m] MX mx.nic.br. 1, nic.br. [5m] RRSIG ns: br. [2d] NS a.dns.br., br. [2d] NS d.dns.br., br. [2d] NS e.dns.br., br. [2d] NS b.dns.br., br. [2d] NS c.dns.br., br. [2d] NS f.dns.br. ar: a.dns.br. [2d] A 200.219.148.10, c.dns.br. [2d] A 200.192.233.10, b.dns.br. [2d] A 200.189.41.10, d.dns.br. [2d] A 200.219.154.10, e.dns.br. [2d] A 200.229.248.10, f.dns.br. [2d] A 200.219.159.10, a.dns.br. [2d] AAAA 2001:12f8:6::10, c.dns.br. [2d] AAAA 2001:12f8:a::10, b.dns.br. [2d] AAAA 2001:12f8:8::10, d.dns.br. [2d] AAAA 2001:12f8:4::10, e.dns.br. [2d] AAAA 2001:12f8:2::10, f.dns.br. [2d] AAAA 2001:12f8:c::10, a.dns.br. [2d] RRSIG, a.dns.br. [2d] RRSIG, c.dns.br. [2d] RRSIG, c.dns.br. [2d] RRSIG, b.dns.br. [2d] RRSIG, b.dns.br. [2d] RRSIG, d.dns.br. [2d] RRSIG, d.dns.br. [2d] RRSIG, . OPT UDPsize=4096 DO (1389)
20:30:12.712894 IP (tos 0x0, ttl 64, id 46053, offset 0, flags [DF], proto UDP (17), length 96)
    192.168.121.135.53 > 192.168.121.1.46802: [bad udp cksum 0x7437 -> 0xf34d!] 31039 q: MX? nic.br. 2/0/0 nic.br. [5m] MX mx.nic.br. 1, nic.br. [5m] MX enqueuer.nic.br. 5 (68)

Podemos ver que o Host envia a solicitação para o DNS Debian solicitando o IPv4:

192.168.121.1.55000 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0xefe9!] 58021+ A? nic.br. (24)

Em seguida o Debian fica brincando de ping pong com o CentOS (ficam trocando informações):

192.168.121.135.39515 > 192.168.121.154.53
192.168.121.154.53 > 192.168.121.135.39515
192.168.121.135.32918 > 192.168.121.154.53
192.168.121.154.53 > 192.168.121.135.32918

E por fim, sempre que o Debian recebe alguma informação concreta de registro como: IPv4, IPv6, MX, NS entre outros, ele retorna o resultado para o Host:

# Retornando o IPv4:
192.168.121.135.53 > 192.168.121.1.55000: [bad udp cksum 0x7421 -> 0xb03a!] 58021 q: A? nic.br. 1/0/0 NIC.BR. [1d] A 200.160.4.6 (46)

# Logo após o Host receber o IPv4, ele solicita o IPv6:
192.168.121.1.34687 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0xf19b!] 12338+ AAAA? nic.br. (24)

# Host recebe o resultado para IPv6:
192.168.121.135.53 > 192.168.121.1.34687: [bad udp cksum 0x742d -> 0x4b4a!] 12338 q: AAAA? nic.br. 1/0/0 NIC.BR. [1d] AAAA 2001:12ff:0:4::6 (58)

# Host solicita o MX:
192.168.121.1.46802 > 192.168.121.135.53: [bad udp cksum 0x740b -> 0x7948!] 31039+ MX? nic.br. (24)

# Host recebe o resultado para MX:
192.168.121.135.53 > 192.168.121.1.46802: [bad udp cksum 0x7437 -> 0xf34d!] 31039 q: MX? nic.br. 2/0/0 nic.br. [5m] MX mx.nic.br. 1, nic.br. [5m] MX enqueuer.nic.br. 5 (68)


DNS Reverso​

O DNS reverso é o mecanismo usado para resolver um endereço IP em um nome de domínio. Enquanto uma consulta DNS comum busca registros como A ou AAAA para descobrir o endereço IP associado a um nome, a consulta reversa faz o caminho oposto, ela parte de um endereço IP e busca um registro PTR correspondente.


Esse recurso é bastante usado por servidores de e-mail e outros serviços para verificar se um endereço IP possui um nome associado de forma adequada. Em ambientes de e-mail, é comum que o servidor remoto consulte o DNS reverso do IP que está tentando entregar a mensagem. Se o IP não possuir um registro PTR, ou se o nome retornado não estiver coerente com os registros diretos do domínio, a mensagem pode ser recusada ou classificada como spam.


É importante observar que o DNS reverso não prova a autenticidade de um servidor. Ele apenas indica qual nome está associado a determinado endereço IP. Para uma configuração mais consistente, o ideal é que o registro PTR aponte para um nome válido e que esse nome, por sua vez, possua um registro A ou AAAA apontando de volta para o mesmo endereço IP. Esse alinhamento é conhecido como DNS reverso consistente ou forward-confirmed reverse DNS.


No DNS reverso para IPv4, a consulta não é feita diretamente pelo endereço IP no formato em que estamos acostumados a escrever. O DNS usa uma árvore própria para isso, chamada in-addr.arpa. Para montar o nome reverso, os octetos do endereço IP são invertidos e, depois, acrescenta-se o sufixo in-addr.arpa.


Por exemplo, o endereço 192.168.121.154 é transformado em 154.121.168.192.in-addr.arpa. É esse nome que será consultado no DNS em busca de um registro PTR. Se existir um PTR para esse nome, ele poderá retornar algo como servidor.exemplo.com..


Quando configuramos o reverso de uma rede, normalmente criamos uma zona baseada na parte da rede, também escrita de forma invertida. Para a rede 192.168.121.0/24, a zona reversa seria 121.168.192.in-addr.arpa. Dentro dessa zona, cada registro representa o último octeto do endereço IP. Assim, o IP 192.168.121.154 seria representado por um registro como:

154     IN      PTR     servidor.exemplo.com.

Na prática, isso significa que uma consulta pelo reverso de 192.168.121.154 procuraria o nome 154.121.168.192.in-addr.arpa e receberia como resposta o nome definido no registro PTR. Por isso, no DNS reverso, quem controla a zona não é necessariamente o dono do domínio do nome retornado, mas sim quem tem autoridade sobre o bloco de endereços IP.



Configurando o DNS Reverso no Debian​

Vamos ver como configurar um reverso no debian.

/etc/bind/named.conf.local
# Adicione a configuração abaixo ao final do arquivo:
zone "121.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.ubuntu.te";
};

/etc/bind/db.ubuntu.te
# Adicione a configuração abaixo ao final do arquivo:
135             PTR     dns.ubuntu.te.
154             PTR     ns2.ubuntu.te.
200             PTR     ftp.ubuntu.te.

# Não se esqueça de mudar o valor de 'SOA', vou deixar '20':
        20      ; Serial

Agora verifique se existem erros na configuração e depois reinicie o serviço do Bind:

# Agora vamos fazer a verificação das configurações
$ sudo named-checkconf /etc/bind/named.conf

# Agora reinicie o bind:
$ sudo rndc reload

Agora de outra máquina podemos testar:

$ dig -x 192.168.121.200 @192.168.121.135 +short
ftp.ubuntu.te.

$ dig -x 192.168.121.154 @192.168.121.135 +short
ns2.ubuntu.te.

# Fazendo consultas dentro do servidor:

$ host 192.168.121.200
200.121.168.192.in-addr.arpa domain name pointer ftp.ubuntu.te.

$ host 192.168.121.154
154.121.168.192.in-addr.arpa domain name pointer ns2.ubuntu.te.

Poderiamos criar outro arquivo para declarar os reversos, mas o que fiz foi manter no mesmo arquivo da zona que já temos e adicionei o PTR que é responsável por declarar o nome para um IP.



Fontes importantes​

https://dnsviz.net

https://en.wikipedia.org/wiki/List_of_DNS_record_types