DNS Reverso: um olhar conceitual e mais aprofundado – parte 1

Pensei bastante se deveria escolher este tema para tratar em um artigo. Afinal, tanto já se falou sobre dns reverso: para que serve, como funciona, como se configura, etc. De qualquer forma, este texto busca uma visão alternativa e mais conceitual.

Inicialmente, a ideia era criar um texto para postagem única. Entretanto, conforme fui escrevendo o rascunho, percebi que ele seria muito extenso dada a quantidade de detalhes que eu gostaria de abordar. Por isso, optei por dividi-lo em duas partes.

Esta é a primeira parte, a segunda você confere clicando neste link.

Por uma questão de didática vou iniciar com elementos mais básicos e, posteriormente, apresentar uma visão mais aprofundada.

Caso tenha alguma dúvida, não deixe de consultar outros artigos que podem ser úteis no entendimento deste tema: Root-Servers, Dig parte 1 e Dig parte 2.

 

Resolução reversa

Chamamos de resolução direta quando temos um nome e queremos encontrar qual o endereço IP associado.

$ host google.com
google.com has address 172.217.30.78

Na prática, o que ocorre é uma query do tipo ‘A‘. Usando o ‘dig‘, temos:

$ dig +short a google.com
172.217.30.110

Já a resolução reversa, ocorre quando queremos o contrário, ou seja, quando queremos encontrar o nome associado a um endereço:

$ host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com.

 

Proteção Antispam usando dns reverso

Grande parte da publicidade do dns reverso vem da sua escolha como uma barreira inicial antispam. A RFC 1912 (Common DNS Operational and Configuration Errors), recomenda:

Every Internet-reachable host should have a name...Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. Also, PTR records must point back to a valid A record..."

Na prática, um servidor de email que tem essa proteção ativada, ao receber uma conexão, realiza o seguinte processo:

  • Executa uma query ‘PTR’ com o IP que iniciou a conexão
  • A partir do nome obtido, faz uma nova query do tipo ‘A’, obtendo o endereço IP associado
  • Faz a comparação entre o endereço obtido anteriormente e o que iniciou a conexão e eles devem ser idênticos
$ host 200.160.2.3
3.2.160.200.in-addr.arpa domain name pointer registro.br.

$ host registro.br
registro.br has address 200.160.2.3

 

Todas as grandes corporações possuem seus reversos configurados e executam este tipo de checagem como uma forma de coibir spammers, algumas não realizam o bloqueio diretamente, mas usam essa informação como um indicador para compor o score de seus sistemas de reputação.

 

UOL Postmaster

Os servidores de e-mail do UOL podem rejeitar conexões de endereços IPs que não estejam de acordo com as recomendações da RFC 1912 (em inglês), em relação às configurações de DNS-reverso (exigência de uma entrada PTR válida e autoritativa)

TERRA Postmaster

O Servidor de Origem deve possuir configuração de DNS. Isto implica na configuração de DNS reverso (um registro de PTR) para o endereço IP do Servidor de Origem, bem como seu DNS direto correspondente. Conforme mencionado na RFC 1912, seção 2.1

 

Traceroute

Outro exemplo no uso do dns reverso é com o traceroute. Todas as vezes em que um IP tem um reverso associado, ele é mostrado por padrão na saída do comando.

Veja no quadro abaixo um exemplo de uso do comando.

$ traceroute uol.com.br
traceroute to uol.com.br (200.147.67.142), 30 hops max, 60 byte packets
...
6 52.93.44.56 (52.93.44.56) 12.180 ms 52.93.44.8 (52.93.44.8) 12.717 ms 52.93.44.120 (52.93.44.120) 6.797 ms
7 52.93.44.33 (52.93.44.33) 4.131 ms 52.93.44.17 (52.93.44.17) 4.010 ms 52.93.44.51 (52.93.44.51) 4.040 ms
8 as7162.saopaulo.sp.ix.br (187.16.216.12) 4.599 ms 4.632 ms 4.604 ms
9 200-147-29-145.static.uol.com.br (200.147.29.145) 5.219 ms 5.185 ms 5.189 ms
10 186.234.26.49 (186.234.26.49) 13.489 ms 200-147-26-132.static.uol.com.br (200.147.26.132) 5.212 ms 5.175 ms
11 186.234.26.65 (186.234.26.65) 6.200 ms 186.234.26.49 (186.234.26.49) 9.910 ms 186.234.26.65 (186.234.26.65) 6.337 ms
12 200-147-26-186.static.uol.com.br (200.147.26.186) 5.358 ms 5.306 ms *

 

Alguns comandos que fazem a resolução reversa

O dns reverso pode ser pesquisado através de alguns comandos bem conhecidos…

$ host 200.160.2.3
3.2.160.200.in-addr.arpa domain name pointer registro.br.
dig -x 200.160.2.3

;; ANSWER SECTION:
3.2.160.200.in-addr.arpa. 14060 IN PTR registro.br.
nslookup 200.160.2.3

Non-authoritative answer:
3.2.160.200.in-addr.arpa name = registro.br.

 

O registro PTR

O tipo de registro para o dns reverso é o ‘PTR’, mas realizar uma pesquisa com ele não é tão elementar quanto é com os outros tipos (cname, a, mx, etc). Exige uma sintaxe específica.

Perceba, nos exemplos acima, que há um padrão nas linhas destacadas em negrito: é o IP com seus octetos invertidos (200.160.2.3 torna-se 3.2.160.200) e acrescido da string “in-addr.arpa”. Ficamos com: 3.2.160.200.in-addr.arpa

A RFC 1034 (DOMAIN NAMES – CONCEPTS AND FACILITIES), tem uma seção nomeada: “Host address to host name translation” e diz o seguinte:

This function will often follow the form of previous functions. Given a 32 bit IP address, the caller wants a character string. The octets of the IP address are reversed, used as name components, and suffixed with “IN-ADDR.ARPA“. A type PTR query is used  to get the RR with the primary name of the host. For example, a request for the host name corresponding to IP address 1.2.3.4 looks for PTR RRs for domain name “4.3.2.1.IN-ADDR.ARPA”.

Os dois comandos abaixo retornam o mesmo resultado, pois na prática executam a mesma operação. Veja:

$ dig -x 200.160.2.3

;; ANSWER SECTION:
3.2.160.200.in-addr.arpa. 15733 IN PTR registro.br.
$ dig ptr 3.2.160.200.in-addr.arpa

;; ANSWER SECTION:
3.2.160.200.in-addr.arpa. 15778 IN PTR registro.br.

 

A título de curiosidade, veja o pedaço do código-fonte no comando ‘dig‘ que é usado  na opção ‘-x‘:

isc_result_t
get_reverse(char *reverse, size_t len, char *value, isc_boolean_t ip6_int,
isc_boolean_t strict)
{
     int r;
     isc_result_t result;
     isc_netaddr_t addr;
     ...
     result = reverse_octets(value, &p, end);
     if (result != ISC_R_SUCCESS)
          return (result);
     /* Append .in-addr.arpa. and a terminating NUL. */
     result = append(".in-addr.arpa.", 15, &p, end);

 

O domínio “arpa”

A particularidade que surge com o tema do dns reverso é por conta de sua sintaxe. Uma coisa que me intrigava era porque deveria inverter o IP e adicionar o “in-addr.arpa“. Na dúvida, ligava o piloto automático, fazia conforme a regra e pronto. Funcionava. 🙂

Entretanto, repare no formato:

3 . 2 . 160 . 200 . in-addr . arpa .

No final das contas, a explicação de porquê isso se faz necessário é simples e muito inteligente. Se você ler da esquerda para a direita, realmente não faz muito sentido. Mas, ao ler da direita para a esquerda, você deve se lembrar sobre como funciona a  estrutura hierárquica de nomes da Internet. Caso tenha dúvidas, sugiro a leitura de um outro artigo que explica como funcionam os Root-Servers.

Dito de outra forma, a operação de resolução de nomes associada ao dns reverso não difere em nada da operação de um domínio tradicional, por exemplo o “ipok.com.br”. Do mesmo jeito que a busca por um host inicia com pesquisas nos Root-Servers e depois vai sendo direcionado para outros conforme a delegação encontrada, assim também ocorre com o reverso. A diferença é que ao invés de usar um ‘.com’, ‘.net, ‘.org’, isso ocorre através de um domínio especial, o ‘.arpa’.

Dns Reverso com domínio ARPA

 

Anatomia da pesquisa de dns reverso

No exemplo abaixo você poderá ver qual é o caminho percorrido desde a requisição original até o servidor responsável pelo registro.

$ dig +trace ptr 3.2.160.200.in-addr.arpa.

.			242641	IN	NS	a.root-servers.net.
.			242641	IN	NS	b.root-servers.net.
.			242641	IN	NS	c.root-servers.net.
.			242641	IN	NS	d.root-servers.net.
.			242641	IN	NS	e.root-servers.net.
.			242641	IN	NS	f.root-servers.net.
.			242641	IN	NS	g.root-servers.net.
.			242641	IN	NS	h.root-servers.net.
.			242641	IN	NS	i.root-servers.net.
.			242641	IN	NS	j.root-servers.net.
.			242641	IN	NS	k.root-servers.net.
.			242641	IN	NS	l.root-servers.net.
.			242641	IN	NS	m.root-servers.net.
;; Received 525 bytes from 127.0.1.1#53(127.0.1.1) in 17 ms

in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	b.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	c.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	d.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	f.in-addr-servers.arpa.
;; Received 737 bytes from 192.58.128.30#53(j.root-servers.net) in 40 ms

200.in-addr.arpa.	86400	IN	NS	lacnic.authdns.ripe.net.
200.in-addr.arpa.	86400	IN	NS	a.arpa.dns.br.
200.in-addr.arpa.	86400	IN	NS	ns.lacnic.net.
200.in-addr.arpa.	86400	IN	NS	sec3.apnic.net.
200.in-addr.arpa.	86400	IN	NS	ns3.afrinic.net.
200.in-addr.arpa.	86400	IN	NS	ns2.lacnic.net.
200.in-addr.arpa.	86400	IN	NS	tinnie.arin.net.
200.in-addr.arpa.	86400	IN	NS	ns-lacnic.nic.mx.
;; Received 522 bytes from 199.180.182.53#53(a.in-addr-servers.arpa) in 134 ms

2.160.200.in-addr.arpa.	86400	IN	NS	A.DNS.BR.
2.160.200.in-addr.arpa.	86400	IN	NS	E.DNS.BR.
2.160.200.in-addr.arpa.	86400	IN	NS	B.DNS.BR.
2.160.200.in-addr.arpa.	86400	IN	NS	C.DNS.BR.
2.160.200.in-addr.arpa.	86400	IN	NS	D.DNS.BR.
;; Received 488 bytes from 202.12.28.140#53(sec3.apnic.net) in 299 ms

3.2.160.200.in-addr.arpa. 86400	IN	PTR	registro.br.
;; Received 78 bytes from 200.192.233.10#53(C.DNS.BR) in 28 ms

Perceba que logo de inicio a requisição é envia aos Root-Servers, que possui a autoridade sobre o domínio “.arpa“. Em seguida, são indicados os servidores responsáveis pelo sub-domínio “in-addr“. Mais uma delegação é encontrada, agora indicando os servidores responsáveis pelo bloco de IPs “200/8” (a saber LACNIC). E assim segue o processo até chegar no servidor responsável pelo registro PTR e este fornecer a resposta final para a pesquisa.

Na parte 2 do artigo irei tratar sobre mais detalhes do domínio arpa, além de informações sobre a organização do sistema de numeração da internet.

 

Fernando Bertasso Figaro

Criador do Site IP-OK

3 comentários em “DNS Reverso: um olhar conceitual e mais aprofundado – parte 1

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *