{"id":3866,"date":"2015-12-17T12:50:09","date_gmt":"2015-12-17T11:50:09","guid":{"rendered":"http:\/\/blog.unelink.es\/?p=3866"},"modified":"2017-05-11T10:49:39","modified_gmt":"2017-05-11T08:49:39","slug":"que-es-un-ptr-o-inversa-y-para-que-sirve","status":"publish","type":"post","link":"https:\/\/hosting.airetech.es\/blog\/wiki\/que-es-un-ptr-o-inversa-y-para-que-sirve\/","title":{"rendered":"\u00bfQu\u00e9 es un PTR, o inversa, y para qu\u00e9 sirve?"},"content":{"rendered":"

\"BusinessmanMuchos de nosotros trabajamos a diario con registros inversos de direcciones IP, tambi\u00e9n conocidos como\u00a0PTRs.\u00a0Sin embargo, en ocasiones hay conceptos que se nos pueden escapar, o de los que no conocemos\u00a0exactamente su funcionamiento o para qu\u00e9 sirven.\u00a0Con esta entrada vamos a intentar explicar, de forma sencilla, el funcionamiento y la utilidad de\u00a0las inversas asociadas a las direcciones IP.<\/p>\n

Como sabemos, a una IP se le puede asignar gracias a los servidores DNS, diferentes nombres como si de una gu\u00eda telef\u00f3nica se tratase. Tambi\u00e9n sabemos que\u00a0las m\u00e1quinas se comunican entre si mediante\u00a0direcciones IP. Para las personas estos n\u00fameros son complicados de memorizar y por\u00a0eso existe el DNS, que se encarga de asociar un nombre con una direcci\u00f3n IP, haciendo m\u00e1s sencillo el uso actual de\u00a0Internet. Es m\u00e1s f\u00e1cil\u00a0recordar \"www.unelink.es\" que 34.33.154.21, por ejemplo.<\/p>\n

Ahora bien, si hablamos de los registros PTR, su funcionalidad es distinta. As\u00ed como el DNS asocia uno o varios nombres a una \u00fanica direcci\u00f3n IP, el PTR asocia una \u00fanica IP a un solo\u00a0nombre<\/strong>.<\/p>\n

\u00bfQu\u00e9 finalidad o usos puede tener\u00a0esto? Los usos de la inversa\u00a0son muy variados, pero aqu\u00ed vamos a hablar del m\u00e1s com\u00fan\u00a0en un servidor, que su uso\u00a0para verificar el remitente de los\u00a0correos electr\u00f3nicos. Como ejemplo usaremos\u00a0el dominio unelink.es.<\/p>\n

Supongamos que tenemos configurado en nuestro DNS un registro de tipo A llamado \"servidor.unelink.es\" que\u00a0apunta a la IP 34.33.154.21. Con esto conseguimos\u00a0que al usar el\u00a0nombre \"servidor.unelink.es\" el DNS nos redirija a 34.33.154.21.<\/p>\n

\u00bfPero, qu\u00e9 pasa cuando mandamos un correo electr\u00f3nico desde \"servidor.unelink.es\"?\u00a0Aqu\u00ed es donde la inversa cobra\u00a0protagonismo.<\/p>\n

Al enviar un correo desde \"servidor.unelink.es\" la cabecera del email contiene,\u00a0por defecto,\u00a0el nombre \"servidor.unelink.es\" (la cabecera es la documentaci\u00f3n que usan los servidores para saber los remitentes y otros datos adicionales del correo origen).<\/p>\n

El servidor de destino del correo puede hacer dos cosas:<\/p>\n

1. Aceptar el correo sin m\u00e1s, lo que puede ser peligroso por que\u00a0puede tratarse de Spam.<\/p>\n

2.\u00a0Comprobar si\u00a0el\u00a0dominio existe en el\u00a0servidor origen y no es un servidor que est\u00e1 mandando Spam debido a\u00a0una infecci\u00f3n. Esta \u00faltima comprobaci\u00f3n\u00a0es\u00a0la que hacen hoy en d\u00eda todos los servidores.<\/p>\n

Tomando como punto de partida el segundo comportamiento, que es el correcto, el servidor recibe el correo y\u00a0en su cabecera tiene dos\u00a0datos importantes:\u00a0el dominio desde el\u00a0que se\u00a0env\u00eda y el nombre del servidor que est\u00e1 realizando\u00a0el env\u00edo.<\/p>\n

Con estos datos el servidor de destino hace, entre otras,\u00a0estas\u00a0comprobaciones:<\/p>\n

    \n
  1. Averigua la IP del dominio del correo recibido.\u00a0Para ello\u00a0utiliza el dominio de la direcci\u00f3n de correo. Por ejemplo, si la direcci\u00f3n de correo es\u00a0jose@unelink.es, se quedar\u00eda con unelink.es.<\/li>\n
  2. Una vez tiene la IP del correo de origen, comprueba si esa IP\u00a0tiene un nombre asociado en Internet.\u00a0En este caso, si la inversa est\u00e1 configurada correctamente, el nombre asociado es \"servidor.unelink.es\".<\/li>\n
  3. Comprueba\u00a0que \"servidor.unelink.es\" responde a la misma IP que \"unelink.es\".<\/li>\n<\/ol>\n

    Si todo esto es correcto dejar\u00e1 entrar el email. En caso contrario devolver\u00e1 un error indicando que el \"reverse record\" no es correcto.<\/p>\n

    Ahora vamos a poner\u00a0un ejemplo donde un sitio web del servidor \"servidor.unelink.es\" ha sido infectado y est\u00e1 mandando correos en nombre de un dominio que no tiene\u00a0configurado:<\/p>\n

      \n
    1. El destino averigua la IP del dominio de la cuenta del correo recibido, por ejemplo fghywk@spytest278u.com,\u00a0y ve\u00a0que su IP\u00a0es 22.33.23.23. Recordemos\u00a0que por la\u00a0cabecera del email el destino\u00a0conoce qui\u00e9n es el servidor real que ha enviado el correo.<\/li>\n
    2. El servidor destino\u00a0hace una consulta en Internet y averigua que la IP de \"spytest278u.com\" es 22.33.23.23.\u00a0Hace la misma consulta para el nombre real del servidor origen que tiene\u00a0en las cabeceras (\"servidor.unelink.es\") y tiene\u00a0como resultado la IP 34.33.154.21.<\/li>\n
    3. Al tener ambas\u00a0IPs, el destino ve que no coinciden y de esta forma\u00a0sabe que\u00a0el email no se est\u00e1 mandando desde el origen real del dominio. Por tanto,\u00a0el destino rechazar\u00e1 la recepci\u00f3n del correo\u00a0por no coincidir la inversa de la IP\u00a022.33.23.23 con el servidor que lo est\u00e1 mandando.<\/li>\n<\/ol>\n

      Para ver m\u00e1s claro este comportamiento vamos a hacer una analog\u00eda con la vida real.<\/p>\n

      Supongamos que recibimos una llamada telef\u00f3nica de un cliente solicitando informaci\u00f3n confidencial de los servicios que tiene contratados. Adem\u00e1s,\u00a0nos indica que no recuerda usuarios o\u00a0contrase\u00f1as, ni tiene acceso a su email para que le enviemos\u00a0dicha informaci\u00f3n. \u00bfC\u00f3mo podr\u00edamos saber\u00a0que la persona que llama es realmente el cliente? Con una simple llamada no hay\u00a0forma de certificar su identidad.<\/p>\n

      Podr\u00edamos realizar una\u00a0comprobaci\u00f3n inversa. El supuesto cliente ha llamado, pero eso\u00a0no nos asegura que sea quien dice ser. Sin embargo,\u00a0en nuestra ficha de cliente disponemos de su nombre y n\u00famero de tel\u00e9fono.\u00a0Le decimos\u00a0que colgamos la llamada y procedemos\u00a0a llamar al n\u00famero de tel\u00e9fono de su ficha. Si se trataba de un impostor, la persona que responda no sabr\u00e1 nada de la llamada anterior, pero si resulta ser el cliente real\u00a0se podr\u00e1 continuar con la conversaci\u00f3n y ratificar\u00eda su identidad.<\/p>\n

      Es decir, se ha asegurado\u00a0la identidad del cliente\u00a0con una comprobaci\u00f3n inversa.<\/p>\n

      Esperamos que esta informaci\u00f3n pueda aclarar algunas dudas sobre las inversas y su funci\u00f3n en el mundo de los servidores , tanto dedicados<\/a> como virtuales<\/a>.<\/p>\n

       <\/p>\n","protected":false},"excerpt":{"rendered":"Muchos de nosotros trabajamos a diario con registros inversos de direcciones IP, tambi\u00e9n conocidos como\u00a0PTRs.\u00a0Sin embargo, en ocasiones hay conceptos que se nos pueden escapar, o de los que no conocemos\u00a0exactamente su funcionamiento o para qu\u00e9 sirven.\u00a0Con esta entrada vamos a intentar explicar, de forma sencilla, el funcionamiento y la utilidad de\u00a0las inversas asociadas a las direcciones IP. Como sabemos, Seguir leyendo<\/a>","protected":false},"author":1,"featured_media":3867,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[101,7,8,6],"tags":[226,220,227,213,214],"class_list":["post-3866","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ip","category-servidores-dedicados","category-servidores-virtuales-vps","category-wiki","tag-inversas","tag-ip","tag-ptr","tag-servidores-dedicados","tag-servidores-virtuales-vps","cat-101-id","cat-7-id","cat-8-id","cat-6-id"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/posts\/3866","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/comments?post=3866"}],"version-history":[{"count":30,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/posts\/3866\/revisions"}],"predecessor-version":[{"id":5520,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/posts\/3866\/revisions\/5520"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/media\/3867"}],"wp:attachment":[{"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/media?parent=3866"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/categories?post=3866"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hosting.airetech.es\/blog\/wp-json\/wp\/v2\/tags?post=3866"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}