Muchos de nosotros trabajamos a diario con registros inversos de direcciones IP, también conocidos como PTRs. Sin embargo, en ocasiones hay conceptos que se nos pueden escapar, o de los que no conocemos exactamente su funcionamiento o para qué sirven. Con esta entrada vamos a intentar explicar, de forma sencilla, el funcionamiento y la utilidad de las inversas asociadas a las direcciones IP.

Como sabemos, a una IP se le puede asignar gracias a los servidores DNS, diferentes nombres como si de una guía telefónica se tratase. También sabemos que las máquinas se comunican entre si mediante direcciones IP. Para las personas estos números son complicados de memorizar y por eso existe el DNS, que se encarga de asociar un nombre con una dirección IP, haciendo más sencillo el uso actual de Internet. Es más fácil recordar «www.mi.com.co» que 125.83.56.38, por ejemplo.

Ahora bien, si hablamos de los registros PTR, su funcionalidad es distinta. Así como el DNS asocia uno o varios nombres a una única dirección IP, el PTR asocia una única IP a un solo nombre.

¿Qué finalidad o usos puede tener esto? Los usos de la inversa son muy variados, pero aquí vamos a hablar del más común en un servidor, que su uso para verificar el remitente de los correos electrónicos. Como ejemplo usaremos el dominio mi.com.co.

Supongamos que tenemos configurado en nuestro DNS un registro de tipo A llamado «servidor.mi.com.co» que apunta a la IP 125.83.56.38. Con esto conseguimos que al usar el nombre «servidor.mi.com.co» el DNS nos redirija a 125.83.56.38.

¿Pero, qué pasa cuando mandamos un correo electrónico desde «servidor.mi.com.co»? Aquí es donde la inversa cobra protagonismo.

Al enviar un correo desde «servidor.mi.com.co» la cabecera del email contiene, por defecto, el nombre «servidor.mi.com.co» (la cabecera es la documentación que usan los servidores para saber los remitentes y otros datos adicionales del correo origen).

El servidor de destino del correo puede hacer dos cosas:

1. Aceptar el correo sin más, lo que puede ser peligroso por que puede tratarse de Spam.

2. Comprobar si el dominio existe en el servidor origen y no es un servidor que está mandando Spam debido a una infección. Esta última comprobación es la que hacen hoy en día todos los servidores.

Tomando como punto de partida el segundo comportamiento, que es el correcto, el servidor recibe el correo y en su cabecera tiene dos datos importantes: el dominio desde el que se envía y el nombre del servidor que está realizando el envío.

Con estos datos el servidor de destino hace, entre otras, estas comprobaciones:

Averigua la IP del dominio del correo recibido. Para ello utiliza el dominio de la dirección de correo. Por ejemplo, si la dirección de correo es ptr@mi.com.co, se quedaría con mi.com.co.
Una vez tiene la IP del correo de origen, comprueba si esa IP tiene un nombre asociado en Internet. En este caso, si la inversa está configurada correctamente, el nombre asociado es «servidor.mi.com.co».
Comprueba que «servidor.mi.com.co» responde a la misma IP que «mi.com.co».
Si todo esto es correcto dejará entrar el email. En caso contrario devolverá un error indicando que el «reverse record» no es correcto.

Ahora vamos a poner un ejemplo donde un sitio web del servidor «servidor.mi.com.co» ha sido infectado y está mandando correos en nombre de un dominio que no tiene configurado:

El destino averigua la IP del dominio de la cuenta del correo recibido, por ejemplo fghywk@phishingtotal.com, y ve que su IP es 22.33.23.23 . Recordemos que por la cabecera del email el destino conoce quién es el servidor real que ha enviado el correo.
El servidor destino hace una consulta en Internet y averigua que la IP de «phishingtotal.com» es 22.33.23.23 . Hace la misma consulta para el nombre real del servidor origen que tiene en las cabeceras («servidor.mi.com.co») y tiene como resultado la IP 125.83.56.38.
Al tener ambas IPs, el destino ve que no coinciden y de esta forma sabe que el email no se está mandando desde el origen real del dominio. Por tanto, el destino rechazará la recepción del correo por no coincidir la inversa de la IP 22.33.23.23 con el servidor que lo está mandando.
Para ver más claro este comportamiento vamos a hacer una analogía con la vida real.

Supongamos que recibimos una llamada telefónica de un cliente solicitando información confidencial de los servicios que tiene contratados. Además, nos indica que no recuerda usuarios o contraseñas, ni tiene acceso a su email para que le enviemos dicha información. ¿Cómo podríamos saber que la persona que llama es realmente el cliente? Con una simple llamada no hay forma de certificar su identidad.

Podríamos realizar una comprobación inversa. El supuesto cliente ha llamado, pero eso no nos asegura que sea quien dice ser. Sin embargo, en nuestra ficha de cliente disponemos de su nombre y número de teléfono. Le decimos que colgamos la llamada y procedemos a llamar al número de teléfono de su ficha. Si se trataba de un impostor, la persona que responda no sabrá nada de la llamada anterior, pero si resulta ser el cliente real se podrá continuar con la conversación y ratificaría su identidad.

Es decir, se ha asegurado la identidad del cliente con una comprobación inversa.

Nota: Los registros PTR los debes configurar con tu proveedor ISP