¿Qué es un PTR, o inversa, y para qué sirve?

Businessman Hipster Holding a Paper With Green Flags, VectorMuchos 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.unelink.es" que 34.33.154.21, 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 unelink.es.

Supongamos que tenemos configurado en nuestro DNS un registro de tipo A llamado "servidor.unelink.es" que apunta a la IP 34.33.154.21. Con esto conseguimos que al usar el nombre "servidor.unelink.es" el DNS nos redirija a 34.33.154.21.

¿Pero, qué pasa cuando mandamos un correo electrónico desde "servidor.unelink.es"? Aquí es donde la inversa cobra protagonismo.

Al enviar un correo desde "servidor.unelink.es" la cabecera del email contiene, por defecto, el nombre "servidor.unelink.es" (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:

  1. 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 jose@unelink.es, se quedaría con unelink.es.
  2. 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.unelink.es".
  3. Comprueba que "servidor.unelink.es" responde a la misma IP que "unelink.es".

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.unelink.es" ha sido infectado y está mandando correos en nombre de un dominio que no tiene configurado:

  1. El destino averigua la IP del dominio de la cuenta del correo recibido, por ejemplo fghywk@spytest278u.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.
  2. El servidor destino hace una consulta en Internet y averigua que la IP de "spytest278u.com" es 22.33.23.23. Hace la misma consulta para el nombre real del servidor origen que tiene en las cabeceras ("servidor.unelink.es") y tiene como resultado la IP 34.33.154.21.
  3. 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.

Esperamos que esta información pueda aclarar algunas dudas sobre las inversas y su función en el mundo de los servidores , tanto dedicados como virtuales.

 

14 Respuestas

  1. Muy bien explicado, perfecto, feliciades.

  2. MrGruñon

    ¿Cómo habría que hacerlo por ejemplo en el siguiente escenario?

    1) Existe empresa.es (Contiene la web corporativa de la empresa en el dominio 200.200.200.4)

    2) Existe un servidor de correo por el que se envían los correos de dicha empresa, webmail.empresa.es (Contiene un servidor de correo en otro servidor 200.200.200.5).

    Al realizar la comprobación de un correo usuario@empresa.es ¿iría contra empresa.es y le daría 200.200.200.4 o por el contrario sabría dónde se encuentra el servidor de correo? (En la máquina 200.200.200.5)

    Creo que no resulta un escenario tan raro que página web y servidor de correo encuentren en distintas IPs o incluso proveedores.

    • Hola, no , no es un escenario extraño, la inversa en este caso debería de ser el hostname de la maquina de correo, y evidentemente sobre la IP de la salida de correo. En tu ejemplo con que pongas 200.200.200.5 inversa webmail.empresa.es sería suficiente y cumpliría la condición.

      Ejemplo: Servidor de correo, correo30.unelink.com registro de tipo A 31.200.249.20
      inversa : correo30.unelink.com

      En el escenario que indicas el servidor web va por su lado y no tiene nada que ver, si bien, si envías mails desde el servidor web te recomendamos que uses el envío a través de tu servidor de correo con autenticación de cuenta.

      Un saludo !

  3. José Luis Rosales

    Excelente !

    Muchas Gracias !

    Desde Ciudad de México !

    • Gracias José Luis, nos alegra saber que la entrada te ha sido de ayuda.

      Un saludo!

  4. Nilo Campos

    Al grano y muy explicado, gracias por este aporte

    • Hola Nilo,

      Muchas gracias, nos alegra que te haya sido útil.

      Un saludo.

  5. Fernando Milla

    Muy bien detallado la informando sobre el registros inverso, me ha servido de mucho compartire su pagina con mis conocidos.

    • Muchas gracias Fernando. Nos alegra saber que la información publicada le ha sido de ayuda.
      Un saludo!

  6. Carlos Barrios

    Excelente información.

  7. Muy bueno este artículo. No entiendo como es posible que no tenga más comentarios.

    • Muchas gracias, en ocasiones las personas no se interesan de el funcionamiento a fondo de las cosas, aunque es bueno saberlo o simplemente ya lo saben. 🙂 En cualquier caso aquí lo dejamos como referencia.

Agregar comentario