Sobre esta herramienta
Introduce una dirección IPv4 o IPv6 para resolver su registro PTR — el nombre DNS inverso asignado a esa IP. Útil para auditar servidores de correo, rastrear abuso, identificar CDNs y entender qué hostname publica el propietario de la IP.
Cómo hacer un lookup DNS inverso
- Introduce una dirección IPv4 o IPv6.
- La herramienta consulta el registro PTR de esa IP y devuelve el hostname al que apunta.
- Revisa el resultado — los ISPs normalmente exponen nombres genéricos; servidores dedicados muestran su hostname real.
- Usa el hostname para identificar al operador de una IP al auditar tráfico o logs.
Casos de uso comunes
- Identificar si una IP sospechosa en tus logs pertenece a un cloud conocido o a un ISP doméstico.
- Verificar que un servidor de correo tiene DNS directo e inverso coincidentes, algo que muchos receptores exigen para aceptar correo.
- Detectar tráfico de abuso viendo que muchas IPs comparten el mismo patrón de reverse DNS.
- Depurar reglas de firewall basadas en hostname que dependen de un PTR válido.
Preguntas frecuentes
¿Qué es un registro PTR?
El registro DNS que mapea una IP a un hostname — la dirección opuesta a un registro A o AAAA. Los PTRs viven en las zonas in-addr.arpa (IPv4) o ip6.arpa (IPv6).
¿Por qué muchas IPs no tienen PTR?
Configurar PTRs requiere controlar la zona inversa, que delega el dueño del bloque IP (normalmente el ISP). No toda IP tiene uno, sobre todo en rangos de consumo.
¿Los servidores de correo exigen PTR?
La mayoría de receptores grandes (Gmail, Outlook, Yahoo) rechazan conexiones desde IPs sin PTR o donde PTR y HELO no casan. Si operas tu propio correo, configura PTR con tu hoster.
¿Se registra mi consulta?
No. Los lookups corren por el navegador y los resultados no se guardan.
Por qué importa el DNS inverso
Los registros PTR mapean una IP a un hostname. Los servidores de correo consultan PTR para filtrar spam — un PTR ausente o incoherente es una señal negativa fuerte para la entregabilidad. El DNS inverso también sirve para identificar qué hay detrás de una IP cuando auditas una red o investigas un incidente.
- Soporte IPv4 e IPv6
- Construcción completa y conforme al RFC de in-addr.arpa e ip6.arpa
- Potenciado por Cloudflare DoH
- Sin registro ni logs
- Estado "sin PTR" claro para IPs sin DNS inverso
Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.
Fuentes (2)
- Mockapetris, P. (1987). Domain Names — Implementation and Specification (in-addr.arpa zone). RFC 1035, IETF.
- Thomson, S., Huitema, C., Ksinant, V., & Souissi, M. (2003). DNS Extensions to Support IP Version 6 (ip6.arpa zone). RFC 3596, IETF.
Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.
Guías relacionadas
- Propagación DNS — Por qué "esperar 48 horas" es casi siempre incorrectoLos cambios DNS no se propagan — los cachés expiran. Cómo funcionan realmente TTL, negative caching y los resolvers públicos durante una migración.
- Autenticación de email — SPF, DKIM y DMARC explicados correctamenteCómo SPF, DKIM y DMARC funcionan juntos para autenticar email de verdad, con los gotchas que rompen la entregabilidad en producción.
Por Marco B. ·