Publicado:
Última actualización:
Un registro PTR, o registro Pointer, es un registro DNS que asigna una dirección IP a un nombre de host o nombre de dominio.
Realiza la función opuesta al registro DNS A, que es más conocido.
Un registro A responde:
“¿Qué dirección IP pertenece a este dominio?”
Un registro PTR responde:
“¿Qué nombre de host está asociado con esta dirección IP?”
Este proceso se denomina DNS inverso, o rDNS.
Los registros PTR son especialmente importantes para la infraestructura de correo electrónico, la identificación de servidores, la resolución de problemas de red, las comprobaciones de seguridad, el registro de eventos y las operaciones IPv4 en producción. Un registro PTR incorrecto o inexistente puede generar problemas operativos, especialmente cuando una dirección IP se utiliza para un servidor de correo u otro servicio donde la identidad y la reputación son importantes.
Esta guía explica cómo funcionan los registros PTR, por qué es importante el DNS inverso, cómo comprobar un registro PTR y qué deberían tener en cuenta las organizaciones que utilizan direcciones IPv4 arrendadas o adquiridas.
PTR significa Pointer.
Un registro DNS PTR asocia una dirección IP con un nombre de host.
Según la RFC 1035 del Internet Engineering Task Force, los registros de recursos PTR forman parte del Domain Name System y se utilizan para apuntar a otra ubicación dentro del espacio de nombres de dominio.
Por ejemplo, supongamos que un servidor de correo utiliza:
203.0.113.25
Su registro PTR podría devolver:
mail.example.com
Por lo tanto, una búsqueda DNS inversa funciona así:
203.0.113.25 → mail.example.com
Una búsqueda DNS directa normal funciona en la dirección opuesta:
mail.example.com → 203.0.113.25
La documentación DNS de Cloudflare también explica que los registros PTR se utilizan para búsquedas DNS inversas con el fin de identificar el nombre de host asociado con una dirección IP.
Una de las formas más sencillas de entender un registro PTR es compararlo con un registro A.
| Registro DNS | Dirección | Ejemplo |
|---|---|---|
| Registro A | Dominio → dirección IPv4 | mail.example.com → 203.0.113.25 |
| Registro PTR | Dirección IPv4 → Dominio | 203.0.113.25 → mail.example.com |
Un registro A forma parte del DNS directo, mientras que un registro PTR forma parte del DNS inverso.
Idealmente, en los sistemas donde importa el DNS inverso confirmado mediante resolución directa, los registros deberían ser coherentes.
mail.example.com → 203.0.113.25 203.0.113.25 → mail.example.com
Esto crea una relación clara entre el nombre de host y la dirección IP.
La búsqueda DNS inversa, normalmente abreviada como rDNS, es el proceso de comenzar con una dirección IP y consultar DNS para determinar el nombre de host asociado con ella.
El DNS normal generalmente comienza con un nombre de host:
www.example.com
y devuelve una dirección IP.
El DNS inverso comienza con la IP:
203.0.113.25
y busca un registro PTR correspondiente.
Cloudflare ofrece una descripción útil de cómo funciona el DNS inverso.
Los registros PTR normalmente no se almacenan dentro de la misma zona DNS que los registros A, AAAA, MX o CNAME de un sitio web.
En su lugar, el DNS inverso utiliza espacios de nombres dedicados.
Tomemos la dirección IPv4:
192.0.2.25
Para realizar una búsqueda DNS inversa, los octetos IPv4 se invierten:
25.2.0.192
Después se añade in-addr.arpa:
25.2.0.192.in-addr.arpa
Un resolutor DNS consulta este espacio de nombres inverso en busca de un registro PTR.
Si está configurado, la respuesta podría ser:
mail.example.com
Esta es una de las diferencias más importantes entre el DNS normal y el DNS inverso.
Si posee un dominio como example.com, normalmente puede gestionar sus registros A, MX, TXT y CNAME a través de su proveedor DNS.
Los registros PTR funcionan de manera diferente.
El control del DNS inverso generalmente sigue el control o la delegación del espacio de direcciones IP, en lugar de la propiedad del nombre de dominio.
Dependiendo de cómo esté estructurado el bloque IPv4, la autoridad del DNS inverso puede ser:
Para bloques IPv4 que no coinciden claramente con los límites tradicionales de delegación de DNS inverso, la RFC 2317 del IETF describe la delegación classless de IN-ADDR.ARPA.
Por eso, simplemente añadir un registro PTR al panel DNS donde está alojado su dominio normalmente no crea DNS inverso para su dirección IP.
El correo electrónico es una de las razones más comunes por las que los administradores se encuentran con registros PTR.
Los sistemas receptores de correo y las plataformas anti-spam pueden realizar comprobaciones de DNS inverso sobre la dirección IP que se conecta a sus servidores.
Por ejemplo, un servidor podría identificarse como:
mail.company.com
mientras utiliza:
203.0.113.20
Una configuración coherente podría incluir:
Registro A:
mail.company.com → 203.0.113.20
Registro PTR:
203.0.113.20 → mail.company.com
Un registro PTR por sí solo no es suficiente para autenticar el correo electrónico. Las organizaciones que operan infraestructura de correo también deberían configurar correctamente:
Una dirección IP pública desarrolla un historial operativo.
Las plataformas de seguridad, los sistemas de correo, las bases de datos de reputación y los sistemas de gestión de abusos pueden evaluar señales asociadas con una dirección IP al decidir cómo tratar su tráfico.
El DNS inverso puede contribuir a esa identidad.
Un registro PTR inexistente, un nombre de host genérico, un nombre de host desactualizado o un nombre asociado con la infraestructura incorrecta puede crear una ambigüedad innecesaria.
Esto se vuelve especialmente importante cuando las empresas compran o arriendan espacio de direcciones IPv4.
Antes de implementar un bloque, los operadores deberían revisar el estado de registro, la reputación, el historial de enrutamiento, la capacidad de DNS inverso, el historial de abusos y la geolocalización.
Consulte la guía de LARUS sobre cómo comprobar la reputación IP antes de comprar direcciones IPv4 para obtener consideraciones adicionales de debida diligencia.
El DNS inverso puede facilitar la comprensión de los registros de red.
En lugar de ver únicamente:
203.0.113.25
un administrador puede identificar:
mail.example.com
Por lo tanto, las búsquedas PTR pueden ayudar durante:
Los registros PTR pueden ayudar a identificar el nombre de host previsto para infraestructuras como:
La gestión de PTR es especialmente relevante cuando una organización arrienda direcciones IPv4.
El arrendatario puede operar la carga de trabajo, pero el control del espacio de nombres de DNS inverso puede permanecer con el proveedor IPv4, a menos que se hayan establecido mecanismos adecuados de delegación o gestión.
Antes de arrendar direcciones IPv4, las empresas deberían preguntar:
Obtenga más información sobre el arrendamiento IPv4 directo de LARUS y Continuity Assurance.
Una configuración de la que se habla habitualmente es Forward-Confirmed Reverse DNS, normalmente abreviada como FCrDNS.
El principio básico es sencillo.
Primero:
203.0.113.25 → mail.example.com
A continuación, el nombre de host devuelto se resuelve hacia adelante:
mail.example.com → 203.0.113.25
Cuando ambas direcciones coinciden correctamente, la relación es más coherente que tener un registro PTR que apunte a un nombre de host que se resuelve hacia otra dirección.
Puede comprobar un registro PTR utilizando herramientas DNS comunes de línea de comandos.
dig -x 8.8.8.8
La opción -x realiza una consulta DNS inversa.
nslookup 8.8.8.8
host 8.8.8.8
Estos métodos pueden utilizarse antes y después de cambiar un registro PTR para comprobar si el nombre de host esperado es visible públicamente.
Los cambios de DNS pueden no aparecer inmediatamente en todas partes, porque las cachés de los resolutores pueden conservar información anterior hasta que expire el TTL correspondiente.
Determine qué dirección IPv4 necesita DNS inverso.
203.0.113.25
Decida a qué nombre de host debe resolverse la dirección.
mail.example.com
Cree el registro A correspondiente:
mail.example.com → 203.0.113.25
Utilice su ISP, proveedor de hosting, proveedor IPv4, sistema de gestión de IP o infraestructura DNS delegada para configurar:
203.0.113.25 → mail.example.com
Ejecute:
dig -x 203.0.113.25
A continuación, verifique la búsqueda directa:
dig mail.example.com A
La dirección IP no devuelve ningún nombre de host durante una búsqueda DNS inversa.
Para algunas cargas de trabajo esto puede no ser importante, pero puede convertirse en un problema para infraestructuras donde se espera una identificación inversa.
Por ejemplo:
203.0.113.25 → old-server.example.com
Esto puede ocurrir cuando el espacio de direcciones se reasigna o cambia de uso y los registros históricos de DNS inverso no se actualizan.
Por ejemplo:
203.0.113.25 → mail.example.com
pero:
mail.example.com → 198.51.100.10
Las rutas directa e inversa son ahora incoherentes.
Algunas infraestructuras pueden utilizar inicialmente un DNS inverso como:
203-0-113-25.provider.example
Esto puede ser aceptable para algunas cargas de trabajo, pero las organizaciones que operan correo dedicado o infraestructura orientada a clientes pueden preferir un nombre de host asociado con sus propios servicios.
Cuando el espacio de direcciones IPv4 cambia de control administrativo, los operadores deberían revisar el DNS inverso junto con el registro, el enrutamiento y otra información operativa relacionada.
LARUS analiza estas consideraciones en su guía de mejores prácticas para transferencias de direcciones IPv4.
Desde una perspectiva operativa, una transferencia IPv4 no se completa simplemente porque el registro refleje al nuevo titular del recurso.
Después de que un bloque de direcciones cambie de titular, los equipos deberían revisar:
Si los registros PTR del operador anterior permanecen activos, pueden identificar incorrectamente la nueva infraestructura.
Las direcciones IPv4 arrendadas introducen un modelo operativo diferente.
El titular de la dirección y la red que utiliza la dirección pueden ser organizaciones diferentes.
Por lo tanto, la pregunta importante pasa a ser:
¿Quién tiene autoridad operativa para gestionar el DNS inverso?
Antes de implementar espacio IPv4 arrendado para cargas de trabajo de producción, especialmente correo electrónico, hosting u otros servicios sensibles a la identidad, confirme cómo se gestionan las solicitudes PTR y la delegación de DNS inverso.
LARUS opera un modelo de arrendamiento IPv4 directo diseñado para apoyar la continuidad operativa, incluyendo áreas como coordinación de rDNS, validez del enrutamiento, supervisión de reputación, gestión de procesos de abuso, soporte de geolocalización y gestión del ciclo de vida.
Obtenga más información sobre el arrendamiento directo de IPv4 de LARUS.
Evite nombres aleatorios o engañosos para infraestructuras de producción importantes.
Asegúrese de que el nombre de host devuelto por el registro PTR se resuelva correctamente.
El DNS inverso debería formar parte de la lista de comprobación de la implementación.
Elimine registros obsoletos después de migraciones, transferencias o sustituciones de servidores.
No dé por hecho que los registros PTR históricos ya han sido eliminados.
Documente si la autoridad pertenece a su equipo, ISP, proveedor de hosting o proveedor IPv4.
Asegúrese de que la gestión de PTR siga disponible durante todo el ciclo de vida del bloque IPv4.
No necesariamente.
Un registro PTR no es obligatorio para todos los posibles usos de una dirección IP.
Su importancia depende de lo que esté haciendo la dirección IP.
Para un servidor de correo público, el DNS inverso puede ser muy importante. Para algunas infraestructuras web normales, aplicaciones o sistemas internos, la configuración de PTR puede ser menos crítica.
La mejor pregunta es:
¿El servicio que se ejecuta en esta IP depende de una identidad inversa fiable?
Si la respuesta es sí, la configuración de PTR debería formar parte del plan de implementación.
Un registro PTR contiene una asignación sencilla:
Dirección IP → nombre de host
Pero esta pequeña parte de la infraestructura DNS conecta varias cuestiones operativas más amplias: identidad, entrega de correo electrónico, reputación, resolución de problemas, gestión de red y gestión del ciclo de vida de IPv4.
Para las empresas que implementan infraestructura IPv4 pública, el DNS inverso debería revisarse junto con el enrutamiento, RPKI, la reputación, la gestión de abusos y la geolocalización, no después de que el servicio ya haya entrado en producción.
Esto es especialmente importante con espacio IPv4 arrendado, donde la responsabilidad de la carga de trabajo de red y la responsabilidad del DNS inverso pueden recaer en organizaciones diferentes.
Explore las soluciones IPv4 de LARUS o conozca más sobre el arrendamiento directo de IPv4.
Un registro PTR, o registro Pointer, es un registro DNS que asigna una dirección IP a un nombre de host. Se utiliza principalmente para búsquedas DNS inversas y realiza la función opuesta de un registro A. Los registros de recursos PTR están definidos en la RFC 1035 del IETF.
Un registro A asigna un nombre de host a una dirección IPv4, mientras que un registro PTR asigna una dirección IPv4 de vuelta a un nombre de host. Por ejemplo, un registro A podría asignar mail.example.com a 203.0.113.25, mientras que el registro PTR asigna 203.0.113.25 de vuelta a mail.example.com.
El DNS inverso es utilizado habitualmente por los sistemas de correo y anti-spam cuando evalúan la infraestructura de envío. Un registro PTR configurado correctamente ayuda a asociar la dirección IP de envío con un nombre de host reconocible, aunque PTR debería utilizarse junto con SPF, DKIM, DMARC y una buena reputación IP.
Puede realizar una búsqueda DNS inversa utilizando comandos como:
dig -x IP_ADDRESS nslookup IP_ADDRESS host IP_ADDRESS
Si existe un registro PTR públicamente resoluble, el resultado debería devolver el nombre de host asociado.
Sí, siempre que el proveedor IPv4 admita la configuración de DNS inverso o delegue el control de la zona DNS inversa correspondiente. Como la autoridad PTR normalmente sigue la infraestructura de la dirección IP en lugar del registrador del dominio, es posible que deba solicitar el cambio a la organización que proporciona la dirección IPv4.
Obtenga más información sobre el arrendamiento IPv4 de LARUS y la coordinación de rDNS.
2022-01-27 09:22:30
ipv4Si quiere poseer una dirección IPv4, tendrá que comprársela al propietario existente. Sin embargo, comprar una dirección IPv4 tiene sus ventajas y sus riesgos.
2021-03-16 05:04:47
ipv4Las direcciones IP virtuales son direcciones IP que no están conectadas a una computadora específica. Por lo tanto, pueden rotar entre los nodos del clúster de Content Gateway.
2022-05-06 09:19:48
IPv4Las direcciones del Protocolo de Internet (IP) se hicieron para distinguir un gadget en una organización IP excepcionalmente, por ejemplo, la web pública.
2021-02-25 12:03:02
ipaddressLas diferencias se pueden dividir en tres puntos principales, que son la dirección, la configuración y el protocolo de mensajes de control de Internet.
Envíe el tamaño de su bloque, perfil de despliegue, contexto ASN, plazos o consulta de vendedor. LARUS responderá con una ruta comercial directa, no con lenguaje genérico de broker.
