Akamai es la empresa de ciberseguridad y cloud computing que potencia y protege los negocios online. Nuestras soluciones de seguridad líderes en el mercado, nuestra inteligencia ante amenazas consolidada y nuestro equipo de operaciones globales proporcionan una defensa en profundidad para proteger los datos y las aplicaciones empresariales. Las soluciones integrales de cloud computing de Akamai garantizan el rendimiento y una buena relación calidad-precio en la plataforma más distribuida del mundo. Las grandes empresas confían en Akamai, ya que les ofrece una fiabilidad, una escalabilidad y una experiencia inigualables en el sector, idóneas para crecer con seguridad.
El DNS inverso (rDNS) es el proceso de descubrir un nombre a partir de una entrada de dirección IP, mientras que las búsquedas de DNS "tradicionales" hacen lo opuesto, ya que traducen un nombre de host a una IP.
dig -x 24.117.59.59
Ejemplo de búsqueda de DNS inverso en un Mac (mediante Terminal)
nslookup 24.117.59.59
Ejemplo de búsqueda de DNS inverso para Windows y Linux
En concreto, el rDNS supone resolver el valor de IP de forma inversa con "in-addr.arpa" anexado al final.1 Por lo tanto, el comando del ejemplo anterior en realidad buscará "59.59.117.24.in-addr.arpa". Si el propietario de la IP configuró correctamente el rDNS, esta consulta devolverá un registro de "puntero" (PTR), que asocia la IP con un dominio:
59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.
¿Por qué es importante el DNS inverso?
Aunque el rDNS no se ha adoptado de forma universal para el tráfico web tradicional, los registros PTR son especialmente importantes para los servidores de correo electrónico, que a menudo realizan búsquedas de rDNS para bloquear o filtrar el spam. Para garantizar que los mensajes se reciben sin indicadores de alerta, los proveedores de correo electrónico legítimos deben implementar correctamente rDNS para las direcciones IP y DNS directo para los nombres de host resultantes. Se fijó esta expectativa para evitar que los spammers enviaran correos electrónicos desde equipos comprometidos, ya que estas IP a menudo no tienen registros rDNS y, cuando lo hacen, la respuesta suele ser una salida genérica y dinámica que sugiere que el cliente no es un servicio de correo electrónico válido.
Como se mostraba anteriormente, la IP residencial 24.117.59.59 apunta a un registro PTR 24-117-59-59.cpe.sparklight.net, que es una salida dinámica, ya que se trata simplemente de la dirección IP con el dominio sparklight anexado. Por lo tanto, si un spammer hackeara el equipo y enviara un correo electrónico desde la IP residencial, el receptor probablemente bloquearía o filtraría el mensaje, ya que las respuestas dinámicas son un claro indicador de spam (como referencia, una respuesta hipotética aceptable sería email.sparklight.net). En resumen, un spammer tendría que ser propietario de un espacio IP para organizar la configuración de DNS necesaria para que el mensaje se aceptara universalmente, lo que supondría un coste prohibitivo para la mayoría de los atacantes.
Por último, algunos servidores de correo electrónico dependen de ajustes de rDNS más matizados con la ayuda de SMTP (protocolo simple de transferencia de correo), un protocolo de comunicaciones estandarizado para la transmisión de correo electrónico. Por ejemplo, los servidores de correo electrónico se pueden configurar para que rechacen correos electrónicos cuando la consulta rDNS no coincida con el comando HELO, un mensaje que inicia la sesión SMTP. Por lo tanto, si una botnet pudiera enviar miles de correos electrónicos de cientos o miles de equipos secuestrados pertenecientes a diferentes redes, al agente malicioso le resultaría complicado anunciar el dominio correcto en cada mensaje HELO, incluso si el rDNS estuviera configurado correctamente para la IP.
Cliente: HELO mail.example.com
Servidor: 250 mail.example.com Hello
¿Cómo se configura el DNS inverso?
Para que una búsqueda de rDNS devuelva una respuesta válida, deberá crearse un archivo de zona rDNS in-addr.arpa que refleje el rango de red fijo asignado al propietario de la IP. En concreto, el administrador de zona debe eliminar el último cuarteto con puntos que contiene los valores explícitamente bajo su control, invertir el orden del octeto de puntos restante y anexar .in-add.arpa.
Dado que Sparklight posee una dirección de clase B, el nombre de su archivo de zona rDNS es 117.24.in-addr.arpa. Si observamos el proceso de resolución completo, ARPA posee las direcciones2 de clase A 24.0.0.0/8, pero delega las consultas de 117.24 consultas a Sparklight:
Zona |
Comentarios |
|
|---|---|---|
Servidores raíz |
j.root-servers.net. |
Al igual que todas las solicitudes de DNS, la consulta comienza en el servidor raíz |
Delegación a ICANN |
in-addr.arpa. |
Los servidores raíz delegan a un conjunto de servidores ICANN responsables de gestionar la zona ARPA |
Otra delegación a ICANN/ARPA |
24.in-addr.arpa. |
ICANN delega a ARPA, propietario de la clase A 24.0.0.0/8 |
Delegación a Sparklight |
117.24.in-addr.arpa. |
A continuación, la consulta se delega a Sparklight, que es el propietario de este rango |
Respuesta |
59.59.117.24.in-addr.arpa. |
Se devuelve el registro PTR |
Al igual que con el DNS directo, cada "punto" en un nombre de host de rDNS es un posible punto de delegación. ICANN gestiona la zona in-addr.arpa y delega las subzonas a los propietarios de un espacio IP.
Dentro del archivo de zona, se deben anunciar los registros PTR pertinentes y, al igual que con cualquier otra zona, también se deben definir los registros de servidor de nombres (NS).
59.59.117.24.in-addr.arpa. 43200 IN PTR 24-117-59-59.cpe.sparklight.net.
117.24.in-addr.arpa. 43200 IN NS ns2.cableone.net.
117.24.in-addr.arpa. 43200 IN. NS ns4.cableone.net.
117.24.in-addr.arpa. 43200 IN NS ns3.cableone.net.
117.24.in-addr.arpa. 43200 IN NS ns1.cableone.net.
Conclusión
Aunque el rDNS puede no ser necesario para que una aplicación web o nativa típica funcione en el Internet abierto, resulta un requisito importante para cualquier servicio de correo electrónico funcional. Una búsqueda inversa también puede ser una herramienta útil para el análisis y la resolución de problemas, ya que los propietarios de las aplicaciones pueden determinar si una IP pertenece a un ISP comercial, un proveedor de nube u otra organización o entidad empresarial. Esta información suele servir para llevar un seguimiento de clientes potenciales, especialmente para las empresas B2B que desean conocer mejor quién navega por su sitio web. Del mismo modo, saber quién es el propietario de una IP puede ayudar a que las herramientas de seguridad determinen si la solicitud pertenece a un atacante o a una fuente legítima.
Aunque no es tan frecuente ni tan conocido como el DNS directo, el rDNS desempeña un papel importante en el ecosistema de Internet actual, y entender este matiz del protocolo es imprescindible para los administradores de correo electrónico, los analistas de marketing B2B y los expertos en ciberseguridad.
1 ip6.arpa es la zona para las direcciones IPv6.
2 Las direcciones de clase A son para redes con un gran número total de hosts. La clase A admite 126 redes al usar el primer octeto para el ID de red. Las direcciones de clase B son para redes medianas y grandes. La clase B admite 16 384 redes al usar los dos primeros octetos para el ID de red.