Pesquisa DNS reversa
Introduz um endereço IPv4 ou IPv6 e vê de imediato a quem pertence o IP: registo PTR, verificação FCrDNS, ASN e organização de origem. A verificação mais importante antes de colocar qualquer IP na internet, sobretudo para correio. Pesquisa executada a partir de Frankfurt FRA01, sem logging.
O que é o DNS reverso?
O DNS reverso (rDNS) é a direção inversa do DNS normal. Enquanto o DNS direto mapeia um nome (kernelhost.com) para um endereço IP, o DNS reverso mapeia o IP de volta para um nome. O tipo de registo correspondente é o PTR (Pointer). Os nomes reversos vivem em dois namespaces dedicados: in-addr.arpa para IPv4 e ip6.arpa para IPv6, cada um construído a partir do IP com os octetos ou nibbles em ordem inversa.
Exemplo: o IP 8.8.8.8 torna-se 8.8.8.8.in-addr.arpa. Uma consulta PTR a este nome devolve o hostname (neste caso, dns.google). Para IPv6 o endereço 2001:db8::1 torna-se 1.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.0.2.ip6.arpa, com cada nibble hexadecimal do endereço apresentado separadamente e em ordem inversa.
Quem controla um registo PTR? O proprietário do bloco de IPs, que normalmente é o provedor upstream, a empresa de hosting ou o ISP. Os donos de domínios não podem definir registos PTR por si próprios, a menos que tenham o bloco de IPs delegado (raro, possível para blocos /24 ou maiores). Para um único VPS o PTR é definido no painel de gestão do hosting ou via ticket de suporte.
FCrDNS: DNS reverso confirmado pelo direto
FCrDNS é a razão mais importante para te preocupares com registos PTR. A ideia é simples: o registo PTR dá-te um hostname, depois resolves esse hostname no sentido direto via A ou AAAA, e o IP devolvido tem de coincidir com o IP original. Se coincidir, o PTR é considerado de confiança. Caso contrário, o PTR é tratado como falsificado e ignorado pela maioria das verificações modernas.
Servidores de correio (Postfix, Exim, OpenSMTPD) e filtros antispam (SpamAssassin, rspamd, Postscreen) verificam o FCrDNS em cada ligação recebida. Uma falha de FCrDNS adiciona normalmente entre 1,0 e 3,5 pontos ao score de spam (muitas vezes o suficiente para cair no lixo), e muitos grandes fornecedores (Gmail, Outlook, Yahoo) rejeitam de imediato a ligação com um erro 550. Sem um FCrDNS válido, o teu servidor de correio efetivamente não existe.
Verificação de FCrDNS feita por esta ferramenta: lemos o registo PTR, resolvemos cada hostname devolvido no sentido direto via A (IPv4) ou AAAA (IPv6) e comparamos os IPs obtidos com o IP original. O selo indica de imediato: verde se verificado, amarelo se não existir nenhum registo forward, vermelho em caso de incompatibilidade, juntamente com a lista de IPs para onde realmente aponta.
Casos de uso comuns
Para que precisas mesmo desta ferramenta na operação diária:
- Comissionamento de servidores de correio: Antes de enviares o primeiro e-mail a partir de um IP novo, o PTR tem de estar definido e o FCrDNS tem de estar verde. Caso contrário, Gmail, Outlook e outros vão rejeitar ou marcar como spam tudo o que enviares. Verifica aqui, corrige no painel do teu provedor, e verifica de novo.
- Análise de spam: Quando recebes spam, consulta o PTR do IP de origem. Um PTR em falta ou quebrado é um indicador forte de spam. Um PTR que aponta para um nome genérico de pool do ISP (dsl-broadband-pool-... etc.) é outro indicador clássico.
- Análise de logs e forense: Um IP aparece nos teus logs. De quem é? O rDNS dá-te o hostname (muitas vezes algo do tipo ec2-..., crawler-..., cdn-...) e, combinado com o ASN, indica o provedor cloud, o país e a organização. Decides em segundos se é um bot legítimo, um cliente de cloud conhecido ou algo a bloquear.
- Operações de rede: Ao depurar um traceroute, os saltos intermédios são apresentados pelo PTR. Os routers ao longo do caminho têm normalmente PTRs descritivos (frankfurt-edge1.isp.net, lhr-core2.example.com etc.) que revelam o trajeto geográfico e topológico do teu pacote.
- Relatórios de abuso: Precisas de submeter um relatório de abuso? O PTR mais o ASN indicam qual o provedor a contactar (abuse@<org>). Sem rDNS terias de procurar o IP nas bases whois do RIPE/ARIN, o que é mais lento.
Como definir um registo PTR
Os registos PTR não se definem no teu nameserver autoritativo da zona direta. São definidos na zona reversa, que é delegada pelo proprietário do bloco de IPs (ARIN, RIPE, APNIC, LACNIC, AfriNIC) até à empresa que detém o bloco. Para um único VPS ou servidor dedicado isto significa: pede ao provedor de hosting para definir o PTR, não tentes fazê-lo no teu próprio painel de DNS.
A maioria dos provedores de hosting oferece gestão self-service de PTR no portal do cliente. Para VPS e servidores dedicados da KernelHost, o campo de rDNS está disponível diretamente no painel de gestão do servidor e as alterações de PTR ficam ativas em 5 a 10 minutos. Para IPs em colocation, o processo padrão é um ticket de suporte com o hostname pretendido por IP.
Boa prática para correio: PTR e HELO têm de coincidir. Se o teu servidor de correio se anuncia como mail.example.com (HELO mail.example.com), então o PTR do IP tem de ser mail.example.com e mail.example.com tem de resolver via A de volta para o mesmo IP. Os três alinhados = FCrDNS verde = reputação limpa.
rDNS na KernelHost
Todos os VPS, servidores dedicados, servidores de mail e servidores Minecraft da KernelHost vêm com gestão self-service de PTR tanto para IPv4 como para IPv6. Defines o hostname por IP no painel de controlo e a alteração fica ativa em minutos, sem necessidade de ticket de suporte. Para blocos de IPs (/29 ou maiores) toda a zona reversa pode ser delegada para os teus próprios nameservers.
A nossa infraestrutura de DNS funciona em Anycast assinado com DNSSEC em Frankfurt e Viena, pelo que as consultas PTR de qualquer ponto do mundo são resolvidas em dezenas de milissegundos. Se estás prestes a comissionar um servidor de correio num IP novo e queres a reputação mais limpa possível desde o primeiro dia, a combinação de rDNS da KernelHost + DKIM/SPF/DMARC no mesmo painel poupa-te o típico ciclo de depuração do primeiro dia.
Perguntas frequentes
Qual a diferença entre pesquisa DNS e pesquisa DNS reversa?
A pesquisa de DNS direto recebe um hostname (kernelhost.com) e devolve um IP através de registos A ou AAAA. A pesquisa de DNS reversa recebe um IP e devolve um hostname através de registos PTR. Os dois são independentes: alguém pode alterar um sem alterar o outro. O FCrDNS é a verificação cruzada que confirma se concordam.
Porque é que o meu IP não tem registo PTR?
Porque ninguém o definiu. Os registos PTR não têm valor por omissão, o detentor do bloco de IPs (o teu provedor) tem de os definir IP a IP. Em ligações domésticas, o ISP costuma definir automaticamente um nome genérico de pool (algo como dsl-host-...-isp.net). Para clientes de hosting, a gestão de PTR está no painel do provedor ou disponível via suporte.
Porque é que o FCrDNS aparece incompatível mesmo com o PTR definido?
Porque o hostname do PTR não resolve em sentido direto para o mesmo IP. Ou falta o A ou o AAAA para esse hostname, ou aponta para um IP diferente. Para corrigir: garante que o PTR é exatamente o hostname para o qual o teu A/AAAA aponta, ex.: PTR = mail.example.com e A mail.example.com = o mesmo IP.
A pesquisa é registada?
Não. Não registamos o IP consultado, não definimos cookies de tracking e não chamamos qualquer API de terceiros, com exceção do serviço DNS-Whois da Team-Cymru, que é uma simples consulta DNS-TXT a origin.asn.cymru.com (sem HTTP, sem chave de API). A Cymru vê o IP do nosso resolver e o IP a ser consultado, não o teu IP.
A ferramenta suporta IPv6?
Sim, totalmente. Introduz um endereço IPv6 em qualquer notação padrão (comprimida como 2001:db8::1 ou expandida), a ferramenta constrói automaticamente o nome ip6.arpa correto (com nibbles invertidos) e consulta o AAAA forward para o FCrDNS.
Posso consultar o DNS reverso para IPs privados (10.x.x.x, 192.168.x.x)?
Não. As gamas de endereços privados e reservados (10/8, 172.16/12, 192.168/16, 127/8, link-local, multicast) não podem ser consultadas via DNS público, porque as suas zonas reversas não estão delegadas à raiz pública. O PTR de IPs privados só é resolvível dentro da rede que os detém, no resolver local.
Porque é que há vários registos PTR para um único IP?
É tecnicamente válido ter vários registos PTR por IP (um IP a servir vários hostnames) e era comum nos tempos do shared hosting. Hoje é desaconselhado para servidores de correio (apenas um dos PTRs irá passar o FCrDNS para um dado HELO), tolerado em servidores web e raro no geral. Se o teu IP tem mais do que um PTR, decide qual é o canónico e remove os restantes.
O rDNS / PTR é obrigatório?
Para servidores de correio: sim, na prática é obrigatório. Sem um PTR limpo em FCrDNS, o teu correio vai para spam ou é rejeitado. Para servidores web: não é obrigatório, mas é recomendado (logs mais limpos, relatórios de abuso mais fáceis). Para serviços internos ou workloads cloud de curta duração: opcional.
Todos os produtos KernelHost
Precisa de mais do que ferramentas? Confira nossa linha de hospedagem comercial.