¿Qué es el DNS inverso? Los registros PTR explicados

El DNS ordinario responde a "¿qué dirección corresponde a este nombre?". El DNS inverso responde a la pregunta contraria: "¿qué nombre corresponde a esta dirección?". El registro que guarda la respuesta es el registro PTR. Es una pieza pequeña que importa en unos pocos lugares (la entrega de correo, sobre todo), y confunde a la gente porque no vive en la zona de su dominio y normalmente no se puede definir desde el panel de DNS.

Cómo funciona el DNS inverso

El DNS solo puede consultar nombres, así que una dirección IP tiene que convertirse primero en un nombre. En IPv4 se invierten los cuatro octetos y se añade .in-addr.arpa:

192.0.2.25   →   25.2.0.192.in-addr.arpa.

La inversión coloca la parte más significativa a la derecha, como en cualquier nombre de dominio, y eso es lo que hace posible la delegación: quien es responsable de 192.0.2.0/24 opera la zona 2.0.192.in-addr.arpa y puede publicar un registro para cada dirección de ese bloque:

25.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

En IPv6 la dirección se escribe completa, invertida dígito hexadecimal a dígito hexadecimal (nibble a nibble), bajo ip6.arpa:

2001:db8::25   →
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Nunca se escribe esto a mano; dig -x construye el nombre por usted:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short -x 2001:db8::25
mail.example.com.

host 192.0.2.25 y nslookup 192.0.2.25 hacen lo mismo.

Quién controla el registro PTR

El árbol inverso sigue la asignación de direcciones, no la titularidad de los dominios. Los registros regionales de Internet (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) delegan las zonas inversas a las organizaciones que poseen bloques de direcciones (operadores, proveedores de hosting y de nube), y estas deciden cómo pueden sus clientes definir registros PTR.

Consecuencias:

• Añadir un registro PTR a la zona de example.com no hace nada. Nadie lo consultará nunca ahí.
• VPS o servidor dedicado: la mayoría de los proveedores tiene un campo "DNS inverso" para cada IP en su panel de control. Muchos exigen que exista antes el registro directo.
• Plataformas de nube: normalmente se admite para direcciones estáticas o reservadas, a veces solo mediante una llamada a la API o una solicitud a soporte, y a veces no para el correo saliente en absoluto.
• Conexión doméstica o de oficina: lo define el operador. Las líneas de empresa con IP estática pueden obtener a menudo un PTR personalizado a petición; las líneas residenciales, por lo general, no.
• Hosting compartido: la dirección la comparten muchos sitios y el PTR nombra al servidor de la empresa de hosting. Es normal y no hay nada que arreglar.
• Su propio bloque de direcciones: usted opera la zona inversa, o la tiene delegada. Para bloques menores que un /24, donde una zona in-addr.arpa completa no puede delegarse por límites de octeto, los proveedores usan la técnica basada en CNAME del RFC 2317.

Para saber a quién preguntar, averigüe quién posee la dirección; consulte cómo saber dónde está alojada una web.

DNS inverso confirmado hacia delante

Un registro PTR por sí solo demuestra poco, porque quien controla la zona inversa puede escribir en ella cualquier nombre, incluido mail.yourbank.example. Lo que los receptores comprueban en realidad es si las dos direcciones concuerdan:

1. IP → PTR → un nombre
2. ese nombre → A/AAAA → la misma IP

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com A
192.0.2.25

Si el bucle se cierra, se habla de DNS inverso confirmado hacia delante (FCrDNS, forward-confirmed reverse DNS). Muestra que quien controla la dirección y quien controla el nombre cooperan, lo que es una señal modesta pero real.

Por qué importa para el correo

Los receptores de correo llevan décadas usando el DNS inverso como entrada de sus filtros de spam, porque una máquina sin PTR, o con uno genérico como host-192-0-2-25.dynamic.isp.example, tiene muchas más probabilidades de ser un ordenador doméstico infectado que un servidor de correo. Los grandes proveedores de buzones indican en sus directrices para remitentes que las IP de envío deben tener DNS directo e inverso válidos; sin ello, espere rechazos o aplazamientos con mensajes que mencionan "PTR record" o "reverse DNS".

Para un servidor de correo, alinee tres nombres:

Elemento	Debería ser
PTR de la IP de envío	mail.example.com
A/AAAA de mail.example.com	la IP de envío
Nombre en el saludo SMTP (HELO/EHLO)	mail.example.com

El PTR no tiene que coincidir con el dominio de la dirección From. Un servidor mail.hosting.example puede enviar para cientos de dominios de clientes; alinear esos dominios es tarea de SPF, DKIM y DMARC, explicados en MX, SPF, DKIM y DMARC.

Si envía a través de un proveedor de servicios de correo o de un servicio de buzones alojado, las IP de envío son suyas, y el PTR también. No hay nada que usted tenga que configurar.

IPv6 merece una advertencia específica: si su servidor tiene una dirección IPv6, a menudo la preferirá para el correo saliente, y los receptores tienden a ser más estrictos con el PTR en IPv6. O define también el PTR y el AAAA para esa dirección, o hace que el servidor de correo envíe solo por IPv4.

Otros lugares donde aparecen los registros PTR

• traceroute y mtr muestran los nombres de los routers a partir de registros PTR, que a menudo revelan la red y la ciudad de cada salto.
• Los registros de actividad y las herramientas de seguridad resuelven las direcciones de los clientes a nombres. Trate esos nombres como pistas; los controla la otra parte.
• Las reglas de acceso basadas en DNS inverso (por ejemplo, "permitir *.crawler.example") solo son seguras si el software confirma el nombre hacia delante. Así es como los buscadores recomiendan verificar sus rastreadores.
• Algunos servidores SSH y FTP hacen una consulta inversa en cada conexión; una zona inversa rota se manifiesta como un retraso de varios segundos al iniciar sesión (UseDNS en OpenSSH).

Lo que un registro PTR no le dice

• No qué sitios web se ejecutan ahí. Una IP puede alojar miles de sitios; el PTR es un único nombre elegido por el titular de la dirección. Los servicios de "IP inversa" que enumeran dominios en una dirección usan datos recopilados por ellos mismos, no registros PTR.
• No quién es el dueño del servidor. server42.hosting.example le dice la empresa de hosting. Los datos de registro del bloque de direcciones le dicen lo mismo, con más fiabilidad.
• No dónde está. Los códigos de aeropuerto en los nombres de los routers son, como mucho, pistas.
• Nada, con bastante frecuencia. Muchas direcciones no tienen PTR en absoluto. Para un servidor web es inofensivo.

Configurarlo: lista de comprobación

1. Elija un nombre de host en un dominio que controle: mail.example.com. Evite el dominio sin subdominio y los nombres que ya cumplen otra función.
2. Cree primero el registro directo: mail.example.com A 192.0.2.25 (y AAAA si procede).
3. Defina el PTR en el panel del proveedor, o pida al proveedor o al operador que lo defina, exactamente con ese nombre de host.
4. Configure el servidor de correo para que se presente con el mismo nombre (myhostname en Postfix, por ejemplo).
5. Verifique ambas direcciones con dig, para IPv4 e IPv6.
6. Deje pasar el TTL del PTR antiguo antes de juzgar el resultado. Cómo funciona la caché se describe en qué es el TTL en DNS.

Errores frecuentes

• Crear un registro PTR en la zona directa y preguntarse por qué no cambia nada.
• Un PTR que apunta a un nombre que no resuelve, o que resuelve a otra IP.
• Varios registros PTR en una misma dirección. Es válido, pero muchas comprobaciones toman solo uno de ellos, de forma impredecible. Use exactamente uno.
• Dejar el PTR genérico por defecto del proveedor en una dirección que envía correo.
• Configurar IPv4 con cuidado y olvidar que el servidor también envía por IPv6.
• Cambiar la IP del servidor y actualizar solo el registro directo.
• Leer un PTR como prueba de identidad. Sin confirmación hacia delante no demuestra nada.

Compruébelo con OrbitProbe

La consulta de IP de OrbitProbe resuelve un nombre de host a sus direcciones IPv4 e IPv6 y muestra, para cada dirección, el nombre de DNS inverso junto con el sistema autónomo y el propietario de la red. Introduzca el nombre de host de su servidor de correo: si el nombre inverso que aparece para cada dirección es el nombre de host que introdujo, el bucle está cerrado. Si el nombre inverso falta o es genérico, el propietario de la red que aparece al lado es la organización que puede cambiarlo.