Consulta DNS inverso (PTR): confirma el hostname detrás de cualquier IP
El DNS inverso es la imagen espejo de una consulta DNS normal. Una consulta directa normal convierte `mail.ejemplo.com` en la IP `85.118.219.232`. Una consulta inversa va al revés: le entregas al DNS la IP y devuelve un registro PTR con el hostname.
Suena académico hasta que gestionas un servidor de correo. Gmail, Outlook y Yahoo todos comprueban el PTR de cada IP que intenta entregarles tráfico SMTP. Sin PTR, o un PTR que no coincida con el registro directo, equivale a rechazo silencioso o billete sin retorno a la carpeta de spam.
Esta herramienta consulta el PTR a través de `dns/promises` de Node (el mismo resolver que usa `dig`, sin proxy DoH en medio) y luego verifica FCrDNS resolviendo de vuelta los registros A y AAAA del target del PTR. Obtienes un check verde cuando ambas direcciones coinciden, una bandera roja cuando no, y un arreglo paso a paso cuando algo está roto.
Cómo usarla
- Introduce una IP: IPv4 plano (`8.8.8.8`) o IPv6 (`2606:4700:4700::1111`). Sin puerto, sin prefijo CIDR.
- Pulsa Comprobar. El resultado suele llegar en menos de un segundo, a veces 2-3 segundos para direcciones IPv6 con resolvers upstream lentos.
- Lee el registro PTR arriba: este es el hostname que la IP afirma ser (p. ej. `dns.google` para `8.8.8.8`).
- Debajo, ve los registros A y AAAA directos de ese hostname. Esta es la comprobación de ida y vuelta.
- Badge FCrDNS: Pass verde significa que la ida y vuelta coincide, Fail rojo significa que el PTR existe pero los registros directos no apuntan de vuelta a tu IP.
- Si FCrDNS falla, lee la Acción sugerida: te dice exactamente qué pedirle a tu proveedor de hosting que arregle.
- ¿Sin PTR en absoluto? Habitual en ISPs residenciales y planes VPS pequeños. La caja de acción explica cómo solicitar uno.
Cuándo es útil
Siete situaciones típicas en las que una comprobación de DNS inverso te salva la cordura:
- Configurar un nuevo servidor de correo antes de cambiar el DNS para producción. Verifica que el PTR coincide antes de enviar el primer mensaje, si no Gmail enrutará todo a spam desde el día uno.
- Depurar la entregabilidad: los clientes se quejan de que tus correos no llegan. Compruebas la IP que tu MTA usa para SMTP saliente, descubres que el PTR apunta al hostname genérico del hosting (`ec2-54-203-xxx.compute.amazonaws.com`) en lugar de `mail.tu-dominio.com`. El arreglo es un ticket.
- Auditar un relay SMTP de terceros: pagas a SendGrid / Mailgun / Postmark para que envíen por ti. Comprueba al azar la IP de envío. El PTR coincide con su dominio público de correo, todo bien.
- Investigar una queja de abuso: una línea de log dice "abuse desde 185.220.101.7". Le haces PTR. El hostname dice nodo de salida TOR en español claro, así que sabes con qué te las ves.
- Verificar el host de un certificado SSL: algunos certificados autofirmados solo codifican la IP del servidor. El PTR confirma qué hostname es el propietario canónico.
- Forense de red en tráfico entrante: una petición llega a tu servidor desde una IP desconocida. El PTR muestra `crawl-66-249-66-1.googlebot.com`. Ahora sabes que es Googlebot real y no alguien falsificando el user agent.
- Confirmar residencial vs datacenter: un TLS handshake desde un "navegador" viene de una IP con PTR `ejemplo.linode.com`. Eso no es un navegador, es un script en un VPS.
Relacionadas: consulta DNS, cuál es mi IP, consulta info IP / ASN, verificador DNS de email.