Na Parte 1 vimos como uma consulta DNS caminha do seu computador até o servidor autoritativo, os registros que todo profissional de infra usa e por que “não propagou” quase sempre é cache. Agora vamos para três situações que aparecem toda semana em suporte:
o e-mail do servidor novo cai no spam ou é recusado;
o log, o traceroute e o monitoramento só mostram IPs, sem nenhum nome;
ping servidorfunciona no escritório e falha em casa, na VPN.
As três passam por assuntos que a Parte 1 deixou de fora: o DNS reverso (registro PTR), o DNS interno (com o split-horizon) e a forma como o próprio cliente monta o nome antes de perguntar. O DNSSEC, que prometemos para esta parte, vai ganhar um artigo só dele, porque merece.
DNS reverso: do IP para o nome
A resolução que vimos até aqui é a direta: nome para IP. O DNS reverso faz o caminho inverso: dado um IP, qual é o nome dele? A resposta fica num registro do tipo PTR (pointer).
O truque é que o DNS só sabe procurar nomes. Para consultar um IP, ele é transformado num nome dentro de uma zona especial, a in-addr.arpa (RFC 1035, seção 3.5). Os octetos são escritos de trás para frente, porque num nome DNS a parte mais geral fica à direita, e num IP a parte mais geral (a rede) fica à esquerda. O IP 203.0.113.10 vira:
10.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.No IPv6 a ideia é a mesma, na zona ip6.arpa, mas cada dígito hexadecimal (nibble) vira um rótulo, também invertido (RFC 3596). O 2001:db8::25 vira um nome de 32 rótulos:
5.2.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.0.2.ip6.arpa.Ninguém digita isso à mão: o dig -x faz a conversão para você, como veremos adiante.
Quem manda no reverso
Aqui está a origem de metade dos chamados sobre PTR: o reverso pertence ao dono do bloco de IP, não ao dono do domínio. A zona direta (example.com) você gerencia no seu provedor de DNS. A zona reversa segue a cadeia de distribuição dos endereços: a IANA delega aos registros regionais (no Brasil, o LACNIC e o NIC.br, pelo Registro.br), que delegam aos provedores, que podem delegar aos clientes.
Na prática, para criar o PTR de um IP fixo você pede ao provedor de internet ou usa o campo “DNS reverso” no painel da nuvem. Não adianta criar um registro PTR no painel do seu domínio: ninguém vai perguntar ali.
Veja o caso real do site da EDCA. O www.edca.com.br aponta para 104.21.11.52, um IP da Cloudflare. O dig +trace do reverso, feito em 31/10/2026, mostra a ARIN (o registro regional da América do Norte) delegando a zona 21.104.in-addr.arpa aos servidores da Cloudflare:
104.in-addr.arpa. 86400 IN NS u.arin.net.
21.104.in-addr.arpa. 86400 IN NS kevin.ns.cloudflare.com.
21.104.in-addr.arpa. 86400 IN NS cruz.ns.cloudflare.com.
21.104.in-addr.arpa. 3600 IN SOA cruz.ns.cloudflare.com. dns.cloudflare.com. ...O resultado final é NXDOMAIN: esse IP não tem PTR. E está tudo certo, porque um site atrás de CDN não precisa de reverso. Quem precisa é quem origina conexões que o outro lado vai avaliar, como um servidor de e-mail.
Um detalhe: se o seu bloco é menor que um /24 (um /28 com 16 IPs, por exemplo), a delegação por octeto não funciona. Os provedores resolvem com a técnica da RFC 2317, que usa CNAMEs para apontar cada IP para uma zona sua. É raro precisar mexer nisso, mas é bom saber que existe quando o provedor pedir.
Por que o PTR importa
E-mail: o reverso confirmado pelo direto
Servidores de e-mail que recebem uma conexão checam o IP de quem envia. O teste mais comum é o FCrDNS (forward-confirmed reverse DNS): o IP precisa ter PTR, e o nome do PTR precisa resolver de volta para o mesmo IP. Sem isso, a mensagem perde pontos no filtro de spam ou é recusada.
O Gmail torna isso obrigatório: as diretrizes de remetente do Google exigem que o IP de envio tenha PTR e que o nome do PTR aponte para o mesmo IP. Quando falta, a recusa costuma vir com o código 5.7.25.
Dois erros clássicos: o PTR genérico do provedor (algo como 77-100-51-198.cliente.provedor.example), que muitos filtros tratam como linha residencial, e o PTR que aponta para um nome sem registro A. O nome no PTR deve ser o mesmo que o servidor usa para se apresentar no SMTP.
Logs, traceroute e monitoramento
Traceroute, firewall, NMS e logs de servidor fazem consultas reversas para mostrar nomes no lugar de IPs. Um PTR bem escolhido (como core1.sp.example.com) transforma uma lista de números num mapa da rede. A RFC 1912 já recomendava manter o PTR coerente com o registro A, e isso continua valendo.
Diagnóstico do reverso com o dig
Os comandos abaixo foram executados em 31/10/2026, contra um resolvedor público:
# reverso de um IP
dig -x 8.8.8.8 +short
dns.google.
# volta do nome para o IP (FCrDNS)
dig dns.google A +short
8.8.8.8
8.8.4.4
# outro exemplo
dig -x 1.1.1.1 +short
one.one.one.one.
# IP sem PTR
dig -x 104.21.11.52 +noall +comments | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAINO 8.8.8.8 passa no teste: o PTR aponta para dns.google, e dns.google resolve de volta para 8.8.8.8. No Windows, nslookup 8.8.8.8 faz a consulta reversa. Para saber quem é o responsável pela zona reversa, use dig -x <IP> +trace e veja o último conjunto de NS.
DNS interno: nomes que só existem dentro da rede
Toda rede de empresa tem nomes que não fazem sentido na internet: servidores de arquivo, impressoras, o IP PBX e os telefones, controladores de domínio. O Active Directory, aliás, depende do DNS para funcionar: os computadores acham os controladores por registros SRV como _ldap._tcp.dc._msdcs.
Que nome usar
Um subdomínio de um domínio seu, como
corp.example.com. É a opção mais segura: o nome é seu, não colide com ninguém e permite certificados válidos. É também o que a Microsoft recomenda para o AD..internal, reservado pela ICANN em 29/07/2024 para uso privado. Ele nunca será delegado na raiz, então é seguro para redes que não querem usar um domínio registrado (resolução da ICANN).
home.arpa, para redes residenciais (RFC 8375).
Evite .local. Ele é do mDNS (RFC 6762): macOS, Linux e celulares mandam essas consultas por multicast na rede local, e não para o seu servidor DNS. O resultado são falhas e lentidão difíceis de explicar.
Evite inventar um TLD (.lan, .corp, .intra). Um nome que não é seu pode ser delegado no futuro e passar a colidir com nomes reais.
Split-horizon: o mesmo nome, duas respostas
Split-horizon (ou split-brain) é quando o mesmo nome recebe respostas diferentes dependendo de onde vem a consulta. O caso típico em VoIP: o IP PBX atende os telefones internos e os ramais remotos pelo mesmo nome.
; visão interna (DNS da empresa)
pbx.example.com. 300 IN A 10.0.20.5
; visão pública (DNS na internet)
pbx.example.com. 300 IN A 203.0.113.20Dentro da rede, o telefone fala direto com o IP privado, sem passar pelo firewall e sem depender de NAT. Fora dela, o ramal remoto recebe o IP público. Os mesmos telefones e o mesmo certificado servem nos dois casos.
O preço é manter as duas visões em sincronia. Os cuidados:
Não vaze nomes internos na zona pública: ela é consultável por qualquer pessoa.
Ao diagnosticar, pergunte primeiro de onde saiu a consulta. Compare
dig @<DNS interno> pbx.example.comcomdig @1.1.1.1 pbx.example.com.Registro criado em uma visão só é a causa clássica de “funciona dentro e não fora” (ou o contrário).
Dois recursos relacionados: o encaminhamento condicional, em que o DNS interno manda as consultas de um domínio específico (o AD de uma filial, por exemplo) para outro servidor, e o split DNS da VPN, em que só os nomes do domínio interno vão para o DNS da empresa e o resto segue pelo resolvedor normal.
O cliente também decide: search e ndots
Quando você digita ping fileserver, o nome não tem domínio. Quem completa é o próprio cliente, com a lista de pesquisa (search domains) que veio do DHCP, da VPN ou da configuração manual. No Linux, ela fica no /etc/resolv.conf:
nameserver 10.0.0.53
search corp.example.com
options ndots:1Com essa configuração, fileserver vira fileserver.corp.example.com. A opção ndots diz quantos pontos um nome precisa ter para ser tentado primeiro como está; com menos pontos, o cliente tenta antes os sufixos da lista. O padrão é 1. No Kubernetes, os pods usam ndots:5, e cada consulta a um nome externo gera várias consultas inúteis antes da certa. Terminar o nome com ponto (api.example.com.) diz ao cliente que o nome já está completo.
É isso que explica o “funciona no escritório e não em casa”: no escritório, o DHCP entrega o search domain; em casa, sem a VPN (ou com uma VPN que não o entrega), o nome curto não é completado. Para ver o que está valendo:
# Linux com systemd-resolved (o resolv.conf aponta para 127.0.0.53)
resolvectl status
# macOS
scutil --dns
# Windows: procure “Lista de pesquisa de sufixos DNS”
ipconfig /allChecklist rápido
PTR não aparece? Descubra quem é o dono do IP (
dig -x <IP> +trace) e peça a ele.E-mail recusado? Teste a ida e a volta: PTR do IP e registro A do nome do PTR.
Resposta diferente dentro e fora? Verifique se existe split-horizon e compare as duas visões.
Nome curto falha? Confira a lista de pesquisa e o ndots do cliente que falhou.
Resumindo
O PTR mapeia IP para nome, nas zonas in-addr.arpa (IPv4) e ip6.arpa (IPv6), com o endereço invertido.
O reverso é do dono do IP: peça ao provedor ou configure no painel da nuvem.
Servidor de e-mail precisa de FCrDNS: PTR e registro A apontando um para o outro.
No DNS interno, use um subdomínio seu ou .internal; evite .local e TLDs inventados.
Split-horizon resolve bem o caso do PBX interno e externo, mas exige manter as duas visões em dia.
Na Parte 3 vamos tratar de DNS e e-mail: MX, SPF, DKIM e DMARC. Se você quer reforçar a base de redes, conheça os nossos cursos.