Registro PTR (IP para Nome)

O Registro PTR (Pointer Record) é a contraparte técnica do registro A no ecossistema DNS. Enquanto o registro A mapeia nomes para IPs (forward lookup), o registro PTR realiza o Mapeamento Reverso (reverse lookup), apontando um endereço IP numérico de volta para um Nome de Domínio Totalmente Qualificado (FQDN). Padronizado na RFC 1035 (1987), o PTR é uma ferramenta crítica para a verificação de identidade em rede, combate ao spam em correio eletrônico, análise forense de incidentes de segurança e operação de muitos protocolos de internet que dependem de rDNS (reverse DNS) para validação de confiança.

1. Estrutura Técnica e a Zona in-addr.arpa

Para que o DNS consiga realizar uma busca por um número (IP) — o que contradiz a estrutura original do DNS, projetada para buscar nomes — foi necessária a criação de uma sub-árvore hierárquica especial.

Atributos do Registro PTR

• TYPE (Tipo): Identificado pelo valor decimal 12 no campo TYPE do cabeçalho DNS (RFC 1035 seção 3.4.1).
• CLASS: IN (Internet), valor 1.
• TTL: Tipicamente entre 1 hora (3600s) e 1 dia (86400s), variando conforme a estabilidade do bloco de IPs.
• RDATA: Nome de domínio FQDN apontado (ex: mx01.empresa.com.).

Sintaxe IPv4: in-addr.arpa

Os octetos do IP são invertidos e acrescentados ao domínio .in-addr.arpa.. Para o IP 1.2.3.4, o registro PTR reside em 4.3.2.1.in-addr.arpa.. A inversão é necessária porque o DNS é hierárquico da esquerda para a direita (do específico ao genérico), enquanto os IPs IPv4 são genéricos à esquerda e específicos à direita.

Sintaxe IPv6: ip6.arpa

Utiliza a zona .ip6.arpa. (substituindo o antigo ip6.int.). Devido ao tamanho do IPv6, cada nibble (4 bits) do endereço hexadecimal é invertido e separado por pontos, gerando nomes de domínio reverso extremamente longos. Por exemplo, o IPv6 2001:db8::1 resulta em 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.2.0.ip6.arpa..

Exemplo de Arquivo de Zona Reversa

; /etc/bind/zones/db.10.0.0 — zona reversa para 10.0.0.0/24
$TTL 86400
@   IN  SOA  ns1.empresa.com. admin.empresa.com. (
            2024011501 ; Serial
            3600       ; Refresh
            1800       ; Retry
            604800     ; Expire
            86400 )    ; Minimum TTL

@       IN  NS   ns1.empresa.com.
@       IN  NS   ns2.empresa.com.

10      IN  PTR  gateway.empresa.com.
25      IN  PTR  mail.empresa.com.
53      IN  PTR  dns1.empresa.com.
80      IN  PTR  www.empresa.com.

2. A Função de Verificação de Identidade (rDNS)

O uso mais difundido e tecnicamente crítico do registro PTR ocorre na camada de aplicação do correio eletrônico (SMTP), mas se estende a diversos outros protocolos.

Validação Anti-Spam em SMTP

Quando um servidor de e-mail (ex: Gmail, Outlook) recebe uma conexão de um servidor externo via SMTP na porta 25, ele realiza uma consulta rDNS (Reverse DNS) do IP do remetente:

1. Servidor recebe conexão TCP do IP 203.0.113.45.
2. Servidor consulta DNS pelo PTR de 45.113.0.203.in-addr.arpa.
3. Se o PTR retornar mail.empresa.com., servidor faz consulta A para mail.empresa.com..
4. Se a consulta A retornar 203.0.113.45, a cadeia está fechada (Forward-Confirmed Reverse DNS, FCrDNS).
5. Servidor é considerado legítimo e a conexão prossegue.

Bloqueio Padrão Anti-Spam

Servidores SMTP sem registro PTR configurado, ou que apontam para nomes genéricos de provedores domésticos (dhcp-203-0-113-45.isp.com.), são sumariamente rejeitados por quase todos os MTAs modernos. Esta é a primeira linha de defesa anti-spam, aplicada por Gmail, Outlook, Yahoo, ProtonMail e praticamente todos os provedores corporativos.

Tabela: Protocolos que Usam PTR

3. Uso em Auditoria e Perícia Forense (Forensics)

Para um analista de Cyber Security, o registro PTR é a principal ferramenta de "humanização" dos dados de rede.

Tradução de Logs

Em vez de analisar uma lista bruta de IPs em um arquivo de log de firewall (/var/log/syslog, /var/log/iptables.log), a resolução PTR permite ver de quais organizações ou países o tráfego está partindo (ex: host.amazon.com, proxy.russia.su, cable.comcast.com). Ferramentas como logwatch, fail2ban e SIEMs (Splunk, ELK) fazem esta tradução automaticamente.

Rastreamento de Invasão

Durante um incidente ativo, a consulta PTR revela rapidamente se o IP do atacante pertence a:

• Serviço de terminal (VPN) como nordvpn.com, mullvad.net.
• Serviço de nuvem (AWS, Azure, GCP) — frequentemente usados para scanning e C2.
• Conexão de banda larga residencial sequestrada (botnets IoT).
• Provedor de hosting legítimo comprometido (linode.com, digitalocean.com).
• TOR exit node (lista pública de IPs).

Geolocalização por PTR

Embora geolocalização por IP use bases como MaxMind GeoIP, o PTR frequentemente contém dicas geográficas (br.telecom.net, uk-bb.isp.com) que auxiliam análise rápida em forense sem acesso à internet.

4. Desafios de Delegação em Blocos Pequenos (RFC 2317)

Delegar a autoridade de registros PTR é tecnicamente complexo para redes menores que uma Classe C (/24, 256 IPs).

O Problema

Como o DNS reverso é segmentado em octetos (<ultimo-octeto>.<rede>.in-addr.arpa), não é possível delegar nativamente apenas uma parte (ex: um bloco /26 com 64 IPs) de um octeto para outro servidor DNS. A zona /24 inteira pertence ao provedor que detém o bloco.

A Solução: RFC 2317 (Classless IN-ADDR)

Utiliza-se redirecionamentos via registros CNAME dentro da zona reversa do provedor, apontando os IPs individuais para uma nova zona de autoridade mantida pelo cliente:

; Zona reversa do provedor ISP (200.0.0/24)
$ORIGIN 0.0.200.in-addr.arpa.
1   IN  CNAME  1.0-26.0.0.200.in-addr.arpa.
2   IN  CNAME  2.0-26.0.0.200.in-addr.arpa.
63  IN  CNAME  63.0-26.0.0.200.in-addr.arpa.

; Zona reversa do cliente (delegada)
$ORIGIN 0-26.0.0.200.in-addr.arpa.
@   IN  NS   ns1.cliente.com.
1   IN  PTR  gw.cliente.com.
2   IN  PTR  mail.cliente.com.

Esta técnica é fundamental para empresas que possuem um pequeno bloco de IPs públicos (comum com /28, /29, /30) e precisam gerenciar seu próprio DNS reverso.

5. Perspectiva de Cyber Security: O DNS Reverso Falso

Atacantes e administradores mal-intencionados podem configurar registros PTR enganosos para mascarar a origem de tráfego.

DNS Spoofing via PTR

O atacante tenta fraudar a resposta PTR para fazer o defensor acreditar que o tráfego vem de uma fonte confiável (ex: microsoft.com, google.com). Como o atacante geralmente controla a zona reversa de seu próprio IP, pode configurar o PTR para apontar para qualquer nome — incluindo nomes de domínio que não possui.

Verificação FCrDNS (Forward-Confirmed Reverse DNS)

Defensores robustos nunca confiam apenas no PTR. Eles realizam:

1. Consulta reversa (IP → Nome): Retorna mail.microsoft.com.
2. Consulta direta (Nome → IP): Retorna 13.107.3.8
3. Comparação: Se os IPs não baterem, a identidade é considerada falsa.

Esta dupla verificação é implementada por SpamAssassin, Postfix (reject_unknown_client_hostname), e praticamente todos os filtros anti-spam modernos. Estima-se que mais de 80% do spam seja bloqueado apenas pela verificação FCrDNS.

6. Diagnóstico e Verificação do Registro PTR

Dominar o diagnóstico de rDNS é essencial para garantir a entrega de e-mails corporativos e a visibilidade da rede:

# Consulta reversa de um IP IPv4 usando dig
dig -x 8.8.8.8 +short
# Saída: dns.google.

# Consulta simples via host (retorna o PTR se existir)
host 142.251.33.68
# Saída: 68.33.251.142.in-addr.arpa domain name pointer rio06s01-in-f4.1e100.net.

# Verificando reverso em ambientes Windows
nslookup -type=ptr 1.2.3.4

# Verificação FCrDNS completa (script bash)
IP=8.8.8.8
PTR=$(dig +short -x $IP | sed 's/\.$//')
A=$(dig +short $PTR)
echo "IP: $IP | PTR: $PTR | A: $A"
if [ "$IP" = "$A" ]; then echo "FCrDNS: VALIDO"; else echo "FCrDNS: INVALIDO"; fi

7. Resumo Técnico

8. Conclusão: O Selo de Autenticidade da Rede

O registro PTR é o "RG" técnico de um endereço IP na Internet. Embora frequentemente negligenciado por administradores iniciantes, sua ausência ou má configuração é a principal causa de falhas de entrega de e-mails corporativos (e-mails marcados como spam ou rejeitados), de invisibilidade em monitoramento de segurança de rede, e de bloqueios em serviços que dependem de FCrDNS. Dominar a estrutura da zona in-addr.arpa., compreender as técnicas de delegação classless da RFC 2317, implementar FCrDNS em servidores de correio e auditar regularmente os PTRs de blocos próprios são requisitos obrigatórios para qualquer profissional de infraestrutura e segurança cibernética de nível pleno em ambientes corporativos modernos.