DNS inverso y registros PTR: la identidad de retorno que necesita su VPS

Una búsqueda de DNS normal comienza con un nombre y solicita una dirección.

su escribes:

mail.example.com

DNS responde:

203.0.113.25

El DNS inverso recorre el camino en la dirección opuesta.

Comienza con:

203.0.113.25

y pregunta:

¿Qué nombre de host dice que pertenece aquí?

Esa respuesta normalmente se almacena en un registro PTR.

Al principio, el DNS inverso suena como un truco técnico de espejo. En muchos sitios web, puede ignorarlo durante años y no darte cuenta. Luego instala un servidor de correo en un VPS, envía su primer mensaje y descubre que el lado receptor se preocupa mucho por la identidad de la dirección IP que llama a su puerta.

Aquí es donde los registros PTR dejan de ser trivialidades.

Un registro DNS inverso configurado correctamente ayuda a conectar una dirección IP a un nombre de host significativo. Los sistemas de correo utilizan esa información como señal para decidir si un servidor de envío parece legítimo. Las plataformas de monitoreo, los equipos de seguridad, los analistas de registros y los administradores de red también utilizan búsquedas inversas para convertir direcciones IP desnudas en nombres que los humanos puedan entender.

Lo inusual es que a menudo no puede crear este registro en el mismo panel DNS donde administra su sitio web.

Para entender por qué, necesitamos darle la vuelta al mapa.

Capítulo 1: DNS directo es el mapa que la mayoría de la gente conoce

Cuando creas un registro DNS normal, normalmente estás asignando un nombre de host a otra cosa.

Por ejemplo:

mail.example.com.    A    203.0.113.25

Eso significa:

Si alguien pregunta por la dirección IPv4 de mail.example.com, responda con 203.0.113.25.

El propietario de example.com controla la zona DNS autorizada para ese dominio, ya sea directamente o a través de un proveedor de DNS.

Es por eso que puede crear registros como A, AAAA, MX, TXT, CNAME, CAA y otros tipos comunes desde el panel de control DNS de su dominio.

Nuestra guía Registros DNS explicados: A, AAAA, CNAME, MX, TXT, NS y más cubre esos registros frontales en detalle.

Una búsqueda inversa plantea una pregunta diferente.

En lugar de:

¿Dónde está mail.example.com?

pregunta:

¿Qué nombre está asociado con 203.0.113.25?

La respuesta se encuentra en una parte diferente del DNS.

Capítulo 2: Conoce el registro PTR

PTR significa puntero.

RFC 1035 define el registro PTR como un nombre de dominio que apunta a otra ubicación en el espacio de nombres DNS. En DNS inverso, se utiliza para asociar una dirección IP con un nombre de host.

Para una dirección IPv4 como:

203.0.113.25

el sistema DNS inverso representa la dirección bajo el dominio especial in-addr.arpa.

Los octetos están invertidos, por lo que la búsqueda se realiza conceptualmente contra:

25.113.0.203.in-addr.arpa

Un registro PTR allí podría devolver:

mail.example.com

Esa inversión parece extraña la primera vez que la ve, pero permite que DNS delegue el espacio de direcciones inverso en una jerarquía organizada.

IPv6 utiliza una estructura inversa relacionada en ip6.arpa.

Normalmente no es necesario crear esos nombres a mano. Herramientas como dig -x generan la consulta inversa correcta para usted.

Utilice nuestra consulta DNS para revisar registros A, AAAA, MX y TXT. El PTR debe configurarse con la organización que controla su IP de envío; compruebe el mapeo inverso mediante dig -x. Si considera nuestros VPS o servidores dedicados para correo, confirme con nosotros la disponibilidad de PTR y la política de SMTP saliente antes de poner el servicio en producción.

Capítulo 3: Por qué es posible que el panel DNS de su dominio no controle el PTR

Esta es la parte que sorprende a muchos propietarios de VPS.

Eres propietario de example.com, por lo que controlas la zona delantera.

Pero, ¿es usted propietario del bloque de IP que contiene 203.0.113.25?

Generalmente no.

El VPS o proveedor de la nube controla el espacio de direcciones o lo recibe a través de su red ascendente. El DNS inverso sigue la propiedad y delegación del espacio IP, no la propiedad de su dominio.

Eso significa que el proveedor normalmente controla la zona inversa.

Entonces esto:

mail.example.com.    A    203.0.113.25

se crea en su DNS normal.

Pero la entrada inversa correspondiente:

203.0.113.25 -> mail.example.com

generalmente se configura en su VPS, servidor dedicado o panel de redes de su proveedor de nube.

Algunos proveedores llaman a la función:

• DNS inverso
• DNSr
• PTR
• registro PTR
• nombre de host IP
• Nombre de host inverso

Si no lo ve, es posible que el soporte técnico deba crearlo por usted.

Esta división del control no es un error. Refleja el hecho de que el propietario de un dominio controla el espacio de nombres del dominio mientras que el proveedor de direcciones controla la asignación inversa para su rango de IP.

Capítulo 4: Por qué son importantes los servidores de correo electrónico

Cuando su servidor de correo se conecta a otro proveedor, el sistema receptor puede ver su dirección IP de envío pública.

Puede preguntar DNS:

¿Esta IP tiene un nombre inverso?

Entonces puede hacer una segunda pregunta:

¿Ese nombre apunta a la misma IP?

Las pautas para remitentes publicadas por Google requieren que las direcciones IP de envío tengan registros DNS directos e inversos válidos. Google explica que la IP de envío pública debe tener un registro PTR que se resuelva en un nombre de host y que el mismo nombre de host debe tener un registro A o AAAA que se resuelva en la IP de envío.

Esa coherencia bidireccional a menudo se denomina DNS inverso confirmado hacia adelante o FCrDNS.

El patrón simple se ve así:

203.0.113.25
    PTR -> mail.example.com

mail.example.com
    A   -> 203.0.113.25

El camino funciona en ambos sentidos.

Esto no garantiza la entrega por bandeja de entrada. La reputación del correo es mucho más amplia que un registro DNS. SPF, DKIM, DMARC, TLS, tasas de quejas, calidad de mensajes, higiene de listas, comportamiento de envío, reputación de IP, reputación de dominio y otras señales son importantes.

Pero el DNS inverso faltante o roto da a los sistemas receptores una razón más para desconfiar de un servidor.

Si opera su propio correo saliente desde un VPS, PTR debe ser parte de la compilación inicial, no una ocurrencia tardía después de que los mensajes comiencen a llegar al spam.

Consulte nuestra guía de SPF, DKIM y DMARC para configurar la autenticación del dominio. Nuestro servicio de seguridad de correo atiende necesidades de protección del correo; no sustituye la configuración PTR ni los requisitos del proveedor receptor.

Capítulo 5: PTR no es SPF, DKIM ni DMARC

Estas tecnologías a menudo se analizan juntas porque todas afectan las operaciones de correo electrónico, pero realizan trabajos diferentes.

PTR y DNS inverso

Vuelva a conectar una dirección IP a un nombre de host.

FPS

Publica qué sistemas pueden enviar correo para un dominio.

DKIM

Agrega una firma criptográfica a un mensaje para que los receptores puedan verificar que el contenido firmado no haya sido modificado y que la firma esté asociada con el dominio de firma.

DMARC

Agrega políticas y reglas de alineación en torno a SPF y DKIM y puede proporcionar informes sobre la actividad de autenticación.

Un servidor de correo puede tener un registro PTR perfecto y aún así fallar DMARC.

También puede tener SPF, DKIM y DMARC correctos, mientras que su IP de envío tiene un DNS inverso deficiente.

Trate la autenticación de correo electrónico como una pila de controles relacionados, no como un único registro mágico.

Capítulo 6: Elegir el nombre de host PTR correcto

Supongamos que su servidor envía correo para example.com.

Un nombre de host PTR sensato podría ser:

mail.example.com

o:

smtp.example.com

La etiqueta exacta es menos importante que la coherencia y la claridad operativa.

Evite configurar el PTR en algo que no se resuelva en adelante.

Evite utilizar un nombre de host que apunte a una IP diferente.

Evite nombres genéricos o que parezcan desechables cuando pueda utilizar un nombre de host estable que represente claramente el servidor.

Si el mismo VPS aloja varios sitios web, normalmente aún elige un nombre de host de servidor principal para el registro PTR de la IP.

Una única IP normalmente tiene una identidad inversa operativa incluso si el servidor maneja muchos dominios.

Esto sorprende a las personas que esperan crear un PTR separado para cada sitio web o dominio de correo. El DNS inverso no funciona como una colección de registros MX por dominio.

Capítulo 7: Una configuración limpia para un servidor de correo VPS

Supongamos que el VPS tiene esta dirección IPv4 pública:

203.0.113.25

y quieres usar:

mail.example.com

Paso 1: crear el registro A directo

En el DNS autorizado para example.com:

mail.example.com.    A    203.0.113.25

Si el servidor usa IPv6, cree también el registro AAAA correcto.

Paso 2: configure el PTR en el proveedor de IP

En el panel de control de VPS o nube, configure DNS inverso para:

203.0.113.25

a:

mail.example.com

Paso 3: Verifique ambas direcciones

Comprobar DNS directo:

dig A mail.example.com +short

Resultado esperado:

203.0.113.25

Verifique el DNS inverso:

dig -x 203.0.113.25 +short

Resultado esperado:

mail.example.com.

Paso 4: verifique la identidad del servidor

Su software de correo debe utilizar un nombre de servidor coherente.

Dependiendo del software, esto podrá configurarse en Postfix, Exim, cPanel, Plesk u otra plataforma de correo.

La configuración exacta varía, pero el objetivo operativo es simple: el servidor debe presentarse utilizando un nombre de host que tenga sentido para la configuración de IP y DNS.

Paso 5: agregue el resto de la autenticación de correo electrónico

Configure SPF, DKIM y DMARC para los dominios que envían correo.

El PTR por sí solo no es suficiente.

Capítulo 8: El clásico desajuste

Aquí hay una configuración común:

mail.example.com -> 203.0.113.25

Pero el DNS inverso regresa:

203.0.113.25 -> vps-48372.hosting-company.example

Técnicamente, el servidor aún puede enviar correos electrónicos.

Operativamente, tiene menos control sobre la identidad presentada por la IP de envío.

Otro desajuste es peor:

203.0.113.25 -> mail.example.com

pero:

mail.example.com -> 198.51.100.44

Ahora el DNS inverso apunta a un nombre de host cuyo registro directo conduce a otro lugar.

Esa inconsistencia es fácil de detectar e innecesaria de mantener.

Fije los lados delantero y trasero para que coincidan.

Si su empresa prefiere una plataforma de correo alojado a operar su propio servidor SMTP, compare Google Workspace con ayuda de nuestra comparación de correo profesional. El dominio da identidad a las direcciones de correo; SPF, DKIM, DMARC y la infraestructura del proveedor deben configurarse correctamente.

Capítulo 9: Por qué cambiar su registro A no cambia el PTR

Supongamos que migra el servidor de correo.

IP antigua:

203.0.113.25

Nueva IP:

198.51.100.40

su actualizas:

mail.example.com.    A    198.51.100.40

El cambio de DNS estilo sitio web está completo.

Pero el PTR para las direcciones IP antiguas y nuevas pertenece a los proveedores de IP correspondientes.

Es posible que necesites:

1. Configure el PTR de la nueva IP en mail.example.com.
2. Verifique el nuevo registro A de reenvío.
3. Mantenga el servidor antiguo disponible durante la transición planificada si el correo aún fluye.
4. Actualice SPF si la lista de IP de envío cambió.
5. Confirme que DKIM y DMARC sigan siendo correctos.
6. Verifique el comportamiento y la reputación del correo saliente después de la migración.

Una migración de DNS no se trata sólo de señalar nombres a la nueva máquina. La identidad del servidor se mueve con el servicio.

Capítulo 10: Las direcciones IP compartidas cambian la imagen

Muchas plataformas de alojamiento y correo electrónico utilizan direcciones IP públicas compartidas.

Si no controlas una IP de envío dedicada, tampoco podrás controlar el registro PTR.

Eso es normal.

En un entorno compartido, el proveedor gestiona la identidad inversa de la infraestructura compartida.

Esta es una razón por la que no debe asumir que trasladar un sitio web a un VPS mejora automáticamente la capacidad de entrega del correo electrónico. Un servidor autoadministrado le brinda más control, pero también le otorga más responsabilidades.

Si está decidiendo si necesita alojamiento compartido, VPS, infraestructura dedicada o servicios en la nube, consulte Comparación de alojamiento compartido, VPS, dedicado y nube.

Capítulo 11: Los registros PTR son útiles más allá del correo electrónico

El DNS inverso aparece en muchas tareas operativas.

Análisis de registros

Un registro web o de seguridad puede contener únicamente direcciones IP. Las búsquedas inversas pueden proporcionar nombres de host útiles, aunque los nombres nunca deben tratarse como prueba de identidad por sí solos.

Solución de problemas de red

Los administradores suelen utilizar DNS inverso para reconocer la infraestructura mientras rastrean rutas o revisan conexiones.

Monitoreo

Un nombre de host de servidor significativo hace que los paneles y las alertas sean más fáciles de interpretar que un muro de direcciones numéricas.

Respuesta a incidentes

Durante una investigación, el DNS inverso puede agregar contexto a una dirección IP. Ese contexto es una pista, no un veredicto.

Un atacante puede controlar el DNS de la infraestructura de su propiedad, por lo que un valor de PTR no debe tratarse como evidencia confiable por sí solo.

Capítulo 12: Cómo solucionar problemas de un PTR faltante

Comience con:

dig -x 203.0.113.25

Si no hay respuesta de PTR, confirme que la IP es realmente suya para usar e identifique qué proveedor controla la dirección.

Luego consulte el panel de proveedores.

Si existe un PTR pero devuelve un nombre de host incorrecto, actualícelo en el proveedor de IP.

Si el PTR es correcto pero la búsqueda directa falla:

dig A mail.example.com

repare el registro A o AAAA en su zona DNS normal.

Si ambos son correctos localmente pero un sistema remoto aún informa una discrepancia, considere almacenar en caché y verificar con más de un solucionador.

Las Herramientas de dominio de SoxDomains pueden ayudar con las comprobaciones normales de DNS público, mientras que las herramientas de línea de comandos siguen siendo útiles para consultas inversas directas y resolución de problemas.

Capítulo 13: Una lista de verificación previa al vuelo antes de enviar correo

Antes de poner en producción un nuevo servidor de correo VPS, verifique:

• El servidor tiene una IP pública estable.
• mail.example.com resuelve esa IP.
• El PTR de la IP se resuelve en mail.example.com.
• El nombre de host se resuelve en la misma IP.
• El nombre de host de correo del servidor está configurado de forma coherente.
• SPF incluye la infraestructura de envío correcta.
• La firma DKIM está activa.
• DMARC se publica y supervisa.
• TLS está habilitado para el transporte de correo.
• La IP no aparece inesperadamente en las listas de bloqueo comunes.
• Los mensajes de prueba pasan controles de autenticación.
• Estás enviando sólo correo deseado a destinatarios legítimos.

La entrega de correo electrónico es reputación más configuración. DNS le da a esa reputación una base técnica limpia.