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

Na primeira parte deste artigo fizemos uma introdução ao Dns Reverso, alguns exemplos práticos, onde e como pode ser usado. Cobrimos também um pouco sobre o registro PTR, associado a resolução reversa de nomes. Já na parte final do texto, foi possível entender sobre o TLD que ainda não havíamos falado antes, o ARPA.

Antes de prosseguir, se ainda não leu, confira a parte 1 deste tema.

Originalmente, o termo ARPA era o acrônimo de Advanced Research Projects Army, uma agência de pesquisas militares dos EUA e uma das entidades por trás da ARPANET, a precursora da Internet. Independentemente do nome estar ligado a uma agência militar, o nome “arpa” acabou se tornando o que chamamos de domínio de topo ou TLD . Entretanto, nos anos 2000, a sigla acabou desvinculada de sua origem militar e passou a significar “Address and Routing Parameter Area“.

Atualmente, o IAB (Internet Architecture Board) em parceria com o ICANN (Internet Corporation for Assigned Names and Numbers), através do IANA (Internet Assigned Numbers Authority) são os responsáveis por gerenciar o TLD “arpa”.

 

ARPA e IANA

Conforme já citado, a IANA é a entidade responsável por manter o TLD “.arpa”. A página: https://www.iana.org/domains/arpa, é dedicada a este domínio, de onde é possível extrair mais uma série de informações interessantes.

The .arpa domain is the “Address and Routing Parameter Area” domain and is designated to be used exclusively for Internet-infrastructure purposes. We administer the domain in cooperation with the Internet technical community through the guidance of the Internet Architecture Board“.

Lembre-se que no artigo anterior falamos tanto sobre o domínio principal “arpa”, quanto seu subdomínio mais utilizado, o “in-addr.arpa”.

  • ARPA: Reserved exclusively to support operationally-critical infrastructural identifier spaces as advised by the Internet Architecture Board
  • IN-ADDR.ARPA: For mapping IPv4 addresses to Internet domain names.

Na lista abaixo, você pode perceber que há mais uma série de subdomínios e seus respectivos propósitos.

IANA Reverso

 

Resolução Reversa…novamente

Já pudemos ver também uma resolução completa:

$ 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

A partir de agora, nosso trabalho será dissecar com mais detalhes estes passos.

Inicialmente, um software cliente de dns, ao realizar a resolução reversa, busca a delegação do TLD nos Root-Servers. O arquivo que é armazenado e sincronizado nestes servidores pode ser encontrado aqui: https://www.internic.net/domain/root.zone.

Olhando para este arquivo, podemos concluir que são os próprios Root-Servers os servidores com autoridade para o domínio.

arpa. 172800 IN NS a.root-servers.net.
arpa. 172800 IN NS b.root-servers.net.
arpa. 172800 IN NS c.root-servers.net.
arpa. 172800 IN NS d.root-servers.net.
arpa. 172800 IN NS e.root-servers.net.
arpa. 172800 IN NS f.root-servers.net.
arpa. 172800 IN NS g.root-servers.net.
arpa. 172800 IN NS h.root-servers.net.
arpa. 172800 IN NS i.root-servers.net.
arpa. 172800 IN NS k.root-servers.net.
arpa. 172800 IN NS l.root-servers.net.
arpa. 172800 IN NS m.root-servers.net.

 

Veja isso através de uma outra forma:

$ dig ns arpa @a.root-servers.net
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47505
;; flags: qr aa rd; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
arpa. 518400 IN NS a.root-servers.net.
arpa. 518400 IN NS m.root-servers.net.
arpa. 518400 IN NS c.root-servers.net.
...

Os detalhes do domínio ARPA, propriamente dito, pode ser encontrado aqui: https://www.internic.net/domain/arpa.zone, também armazenado diretamente nos servidores raiz. Como curiosidade, se você inspecionar este link, encontrará o próximo nível de delegação de cada um dos subdomínios da imagem mostrada anteriormente (in-addr, uri.arpa, ip6.arpa, etc).

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.

 

Delegação dos Blocos de IP

É a partir da análise da zona do subdomínio “in-addr”, disponível em https://www.internic.net/domain/in-addr.arpa, que você começa a compreender como um bloco de IPs é delegado.

Portanto, isso que explica porque os octetos dos IPs serem invertidos na pesquisa, uma vez que a delegação ocorre da direita para esquerda. Veja a delegação do bloco de IPs que inicia com “200.” ou “200/8“.

$ dig ns 200.in-addr.arpa
200.in-addr.arpa. 86400 IN NS a.arpa.dns.br.
200.in-addr.arpa. 86400 IN NS lacnic.authdns.ripe.net.
200.in-addr.arpa. 86400 IN NS ns2.lacnic.net.
200.in-addr.arpa. 86400 IN NS ns3.afrinic.net.
200.in-addr.arpa. 86400 IN NS ns.lacnic.net.
200.in-addr.arpa. 86400 IN NS ns-lacnic.nic.mx.
200.in-addr.arpa. 86400 IN NS sec3.apnic.net.
200.in-addr.arpa. 86400 IN NS tinnie.arin.net.

LACNIC, RIPE, APNIC, AFRINIC e ARIN são entidades regionais, responsáveis pela gestão dos recursos da Internet. Assim, a IANA tem uma responsabilidade global e estas, chamadas RIR (Regional Internet Registry), a gestão de uma região.

A região da América Latina e Caribe tem como responsável a LACNIC, que é sediada no Uruguai.

RIR Reverso

 

O NRO – Number Resource Oganization (https://www.nro.net/) mantém o registro de cada uma das delegações de bloco existentes (https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended). No caso do IP que estamos analisando, o bloco “200.160.0.0”, com 4096 IPs (ou /20), é alocado para a LACNIC:

lacnic|BR|ipv4|200.160.0.0|4096|20011016|assigned|114721|e-stats

Por sua vez, a LACNIC delega ao Registro.br a gestão destes recursos no Brasil. Quando o Registro.br delega a você um bloco de IPs, é necessário configurar um conjunto de servidores de DNS que responderão pelo reverso dos IPs deste bloco.

registro.br

 

Para entender um pouco mais sobre como funciona a configuração de Resolução Reversa no Registro.br, acesse o link: “https://registro.br/tecnologia/provedor-acesso.html?secao=numeracao” e leia a seção “Suporte“, seção 3.

Os blocos de endereços IPs distribuídos pelo NIC.BR devem ter a delegação DNS registrada em seu sistema, as quais são então repassadas ao servidores DNS do LACNIC.

Portanto, quando você configura a delegação de um bloco de IPs para seus servidores de DNS no sistema do Registro.br, essa informação é repassada aos servidores da LACNIC e replicado em todos os seus servidores espalhados globalmente.

Currently, there are 6 servers for this function. They are located not only in the Latin American and Caribbean region but also in Africa, North America, Asia and Europe.

 

Se você usa o Bind, você deve ter uma zona mais ou menos assim. Esse é o modelo para uma zona de dns reverso:

@             IN      SOA   ns1.example.com. hostmaster.example.com. (
                              2003080800 ; serial number
                              12h         ; refresh
                              15m        ; update retry
                              3w         ; expiry
                              3h         ; NXDOMAIN ttl
                              )
              IN      NS      ns1.example.com.
              IN      NS      ns2.example.com.
;
2             IN      PTR     www.example.com.
10            IN      PTR     ns1.example.com.
...

 

De volta ao Dns Reverso

Após apresentar cada uma das peças envolvidas neste processo, acho que é o momento de juntarmos todas essas informações e colocá-las na ordem em que são necessárias durante uma pesquisa de resolução reversa.

Assim, vamos olhar novamente para a questão: O que acontece quando queremos encontrar o registro PTR (ou dns reverso)  associado a um endereço IP ? Por exemplo, o IP 200.160.2.3 (ou 3.2.160.200.in-addr.arpa)

  • O cliente de DNS do seu computador ou de seu servidor vai direto nos Root-Servers
  • Nos servidores raiz, ele busca o próximo nível de delegação do domínio arpa
  • Daí, até o próximo nível para o subdomínio in-addr.arpa
  • O mesmo ocorre para o primeiro octeto do IP, o 200.in-addr.arpa
  • E assim, sucessivamente, até chegar aos servidores indicados por você nos sistemas do Registro.br, e que são os responsáveis por sua zona reversa.
  • Por último, a pesquisa é executada diretamente em seus servidores e daí obtendo a resposta final.

Para não ficarmos somente em exemplos com IPs brasileiros, veja abaixo como é esse fluxo para o IP 8.8.8.8 (Dns recursivo do Google). Este IP é de responsabilidade da ARIN.

dig +trace ptr 8.8.8.8.in-addr.arpa

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

in-addr.arpa.		172800	IN	NS	e.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	a.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	b.in-addr-servers.arpa.
in-addr.arpa.		172800	IN	NS	f.in-addr-servers.arpa.
;; Received 733 bytes from 192.33.4.12#53(c.root-servers.net) in 143 ms

8.in-addr.arpa.		86400	IN	NS	z.arin.net.
8.in-addr.arpa.		86400	IN	NS	r.arin.net.
8.in-addr.arpa.		86400	IN	NS	x.arin.net.
8.in-addr.arpa.		86400	IN	NS	y.arin.net.
8.in-addr.arpa.		86400	IN	NS	u.arin.net.
8.in-addr.arpa.		86400	IN	NS	arin.authdns.ripe.net.
;; Received 425 bytes from 203.119.86.101#53(e.in-addr-servers.arpa) in 290 ms

8.8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.
8.8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
;; Received 308 bytes from 192.82.134.30#53(y.arin.net) in 130 ms

8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
;; Received 131 bytes from 209.244.0.2#53(ns2.level3.net) in 125 ms

8.8.8.8.in-addr.arpa.	86400	IN	PTR	google-public-dns-a.google.com.
;; Received 82 bytes from 216.239.32.10#53(ns1.google.com) in 59 ms

 

Conclusão

Conforme citei na primeira parte, tive a preocupação em dar uma visão alternativa sobre um tema (dns reverso), acerca do qual tanto já se falou.

Muita coisa já foi publicada sobre como configurar registros, como realizar pesquisas, mas não encontrei muito material sobre como isso ocorre em termos de infraestrutura de dns.

Existem entidades globais e regionais formadas especificamente para a gestão destas políticas e recursos de numeração, como vimos a IANA, LACNIC, etc. Mas existem outras que, provavelmente, você nunca tenha ouvido falar: IAB, ISOC, NRO, entre outras.

 

Fernando Bertasso Figaro

Criador do Site IP-OK

Um comentário em “DNS Reverso: um olhar conceitual e mais aprofundado – parte 2

Deixe uma resposta

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