Búsqueda DNS inverso
Introduce una dirección IPv4 o IPv6 y descubre al instante a quién pertenece la IP: registro PTR, verificación FCrDNS, ASN y la organización de origen. La comprobación más importante antes de poner cualquier IP en internet, sobre todo para correo. La búsqueda se ejecuta desde Frankfurt FRA01, sin logs.
¿Qué es el DNS inverso?
El DNS inverso (rDNS) es la dirección opuesta al DNS normal. Mientras que el DNS directo asigna un nombre (kernelhost.com) a una dirección IP, el DNS inverso asigna la IP de vuelta a un nombre. El tipo de registro empleado es PTR (Pointer). Los nombres inversos viven en dos espacios de nombres dedicados: in-addr.arpa para IPv4 e ip6.arpa para IPv6, construidos a partir de la IP en orden inverso de octeto o nibble.
Ejemplo: la IP 8.8.8.8 se convierte en 8.8.8.8.in-addr.arpa. Una consulta PTR sobre este nombre devuelve el hostname (dns.google en este caso). Para IPv6 la dirección 2001:db8::1 se convierte en 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, con cada nibble hexadecimal de la dirección mostrado por separado y en orden inverso.
¿Quién controla un registro PTR? El propietario del rango de IP, que normalmente es el proveedor de tránsito, la empresa de hosting o el ISP. Los propietarios de dominios no pueden configurar registros PTR por su cuenta a menos que les deleguen el rango de IP (poco frecuente, posible para bloques /24 o mayores). Para un VPS individual, el PTR se configura en el panel de control del hosting o mediante ticket de soporte.
FCrDNS: DNS inverso confirmado en directo
FCrDNS es la razón más importante para preocuparse por los registros PTR. La idea es simple: el registro PTR te da un hostname, luego resuelves ese hostname en directo vía A o AAAA y la IP devuelta debe coincidir con la IP original. Si coincide, el PTR es de confianza. Si no, el PTR se considera falsificado y la mayoría de las comprobaciones modernas lo ignoran.
Los servidores de correo (Postfix, Exim, OpenSMTPD) y los filtros antispam (SpamAssassin, rspamd, Postscreen) verifican FCrDNS en cada conexión entrante. Un FCrDNS fail suele añadir entre 1,0 y 3,5 puntos a la puntuación de spam (con frecuencia suficiente para acabar en la carpeta de no deseados), y muchos grandes proveedores (Gmail, Outlook, Yahoo) rechazan la conexión directamente con un error 550. Sin un FCrDNS válido tu servidor de correo prácticamente no existe.
Verificación FCrDNS de esta herramienta: leemos el registro PTR, después resolvemos cada hostname devuelto en directo vía A (IPv4) o AAAA (IPv6) y comparamos las IPs obtenidas con la IP original. La etiqueta te lo indica al instante: verde para verificado, amarillo si no existe registro directo y rojo en caso de discrepancia con la lista de a dónde apunta realmente.
Casos de uso habituales
Para qué necesitas realmente esta herramienta en el día a día:
- Puesta en marcha de un servidor de correo: Antes de enviar el primer correo desde una IP nueva, el PTR debe estar configurado y FCrDNS debe aparecer en verde. De lo contrario Gmail, Outlook y otros rechazarán o enviarán a spam cada correo que mandes. Verifica aquí, corrige en el panel de tu proveedor y vuelve a verificar.
- Análisis de spam: Cuando recibes spam, consulta el PTR de la IP origen. Un PTR ausente o roto es una señal clara de spam. Un PTR que apunta a un nombre genérico de pool de ISP (dsl-broadband-pool-... etc.) es otro indicador clásico.
- Análisis de logs y forense: Una IP aparece en tus logs. ¿Quién es? El rDNS te da el hostname (a menudo algo como ec2-..., crawler-..., cdn-...) y combinado con el ASN te indica proveedor cloud, país y organización. Decides en segundos si es un bot legítimo, un cliente cloud conocido o algo que conviene bloquear.
- Operaciones de red: Cuando depuras un traceroute, los saltos intermedios se muestran mediante PTR. Los routers a lo largo del camino suelen tener PTRs descriptivos (frankfurt-edge1.isp.net, lhr-core2.example.com, etc.) que te indican la ruta geográfica y topológica que sigue tu paquete.
- Reportes de abuso: ¿Necesitas presentar un reporte de abuso? El PTR junto con el ASN te indican a qué proveedor contactar (abuse@<org>). Sin rDNS tendrías que buscar la IP en las bases de datos whois de RIPE/ARIN, lo cual es más lento.
Cómo configurar un registro PTR
Los registros PTR no se configuran en tu servidor de nombres autoritativo de la zona directa. Se configuran en la zona inversa, que el propietario de la IP (ARIN, RIPE, APNIC, LACNIC, AfriNIC) delega hacia abajo a la empresa que posee el bloque de IPs. Para un VPS o servidor dedicado individual, esto significa: pide al proveedor de hosting que configure el PTR, no intentes hacerlo en tu propio panel DNS.
La mayoría de los proveedores de hosting ofrecen gestión autoservicio del PTR en el portal del cliente. Para los VPS y servidores dedicados de KernelHost, el campo rDNS está disponible directamente en el panel de gestión del servidor y los cambios de PTR se activan en 5 a 10 minutos. Para IPs en colocación el proceso estándar es un ticket de soporte con el hostname deseado por cada IP.
Buena práctica para correo: PTR y HELO deben coincidir. Si tu servidor de correo se anuncia como mail.example.com (HELO mail.example.com), entonces el PTR de la IP debe ser mail.example.com, y mail.example.com debe resolver mediante A de vuelta a esa IP. Los tres alineados = FCrDNS verde = reputación limpia.
rDNS en KernelHost
Cada VPS de KernelHost, servidor dedicado, servidor de correo y servidor Minecraft incluye gestión autoservicio del PTR tanto para IPv4 como para IPv6. Configuras el hostname por IP en el panel de control y el cambio se activa en minutos, sin necesidad de ticket de soporte. Para bloques de IP (/29 o mayores) toda la zona inversa puede delegarse a tus propios servidores de nombres.
Nuestro plano DNS funciona como Anycast firmado con DNSSEC en Frankfurt y Viena, de modo que las consultas PTR desde cualquier parte del mundo resuelven en decenas de milisegundos. Si vas a poner en marcha un servidor de correo en una IP nueva y quieres la mejor reputación posible desde el primer día, la combinación de rDNS de KernelHost + DKIM/SPF/DMARC en el mismo panel te ahorra el ciclo típico de depuración del primer día.
Preguntas frecuentes
¿Cuál es la diferencia entre una búsqueda DNS y una búsqueda DNS inversa?
La búsqueda DNS directa toma un hostname (kernelhost.com) y devuelve una IP mediante registros A o AAAA. La búsqueda DNS inversa toma una IP y devuelve un hostname mediante registros PTR. Ambas son independientes: alguien puede cambiar una sin tocar la otra. FCrDNS es la verificación cruzada que comprueba que coinciden.
¿Por qué mi IP no tiene registro PTR?
Porque nadie lo configuró. Los registros PTR no tienen valor por defecto, el titular del bloque de IPs (tu proveedor) debe configurarlos por cada IP. Para conexiones domésticas el ISP suele asignar automáticamente un nombre genérico de pool (algo como dsl-host-...-isp.net). Para clientes de hosting, la gestión del PTR está en el panel de control del proveedor o disponible vía soporte.
¿Por qué FCrDNS aparece como mismatch aunque el PTR esté configurado?
Porque el hostname del PTR no resuelve en directo de vuelta a la misma IP. O falta el A o AAAA de ese hostname, o apunta a una IP distinta. Para arreglarlo: asegúrate de que el PTR sea exactamente el hostname al que apuntan tus registros A/AAAA, p. ej. PTR = mail.example.com y A mail.example.com = la misma IP.
¿Se registra la consulta?
No. No registramos la IP consultada, no usamos cookies de seguimiento ni llamamos a ninguna API de terceros excepto el servicio Team-Cymru DNS-Whois, que es una consulta DNS-TXT estándar contra origin.asn.cymru.com (sin HTTP, sin clave API). Cymru ve la IP de nuestro resolver y la IP que se consulta, no tu IP.
¿La herramienta soporta IPv6?
Sí, completamente. Introduce una dirección IPv6 en cualquier notación estándar (comprimida como 2001:db8::1 o expandida), la herramienta construye automáticamente el nombre ip6.arpa correcto (con los nibbles invertidos) y consulta el registro AAAA directo para FCrDNS.
¿Puedo consultar DNS inverso para IPs privadas (10.x.x.x, 192.168.x.x)?
No. Los rangos de direcciones privadas y reservadas (10/8, 172.16/12, 192.168/16, 127/8, link-local, multicast) no pueden consultarse mediante DNS público porque sus zonas inversas no están delegadas a la raíz pública. El PTR de IPs privadas solo es resoluble dentro de la red propietaria, en el resolver local.
¿Por qué hay varios registros PTR para una sola IP?
Técnicamente es válido tener varios registros PTR por IP (una IP que sirve varios hostnames) y era habitual en la época del hosting compartido. Hoy se desaconseja para servidores de correo (solo uno de los PTRs pasará FCrDNS para un HELO determinado), se tolera para servidores web y es poco común en general. Si tu IP tiene más de un PTR, decide cuál es el canónico y elimina los demás.
¿Es obligatorio el rDNS / PTR?
Para servidores de correo: sí, en la práctica es obligatorio. Sin un PTR limpio en FCrDNS tu correo va a spam o se rechaza. Para servidores web: no es obligatorio pero sí recomendado (logs más limpios, reportes de abuso más fáciles). Para servicios internos o cargas cloud efímeras: opcional.
Todos los productos KernelHost
¿Necesitas más que herramientas? Descubre nuestra oferta de hosting comercial.